Intermittent Issue with writeWithoutResponse on Android

[gion-andri]

Hi everyone,

I’m encountering a perplexing issue with our app’s BLE functionality and would appreciate your insights.

Background:

• Our app connects to a BLE device, sets up notifications, and performs write operations using writeWithoutResponse.

• Under normal conditions, every call to writeWithoutResponse is logged twice: once for the plug-in invocation and once for the response.
  

The Issue:

• In very rare cases (it usually took me 4-6 hours playing with the connection), the expected response log is missing.
  

• Once this happens, all subsequent writeWithoutResponse calls seem to be ignored—there are no function call logs or response logs, even though a preceding console.log confirms the call is made.

• All other BLE operations (such as disconnecting, reconnecting, and other commands) continue to work as expected.

• So far, this behaviour has been observed on Android; however, I can’t completely rule out the possibility it might occur on iOS as well.

Discussion Points:

• Could there be an internal state issue within the BLE handling on Android that causes the plug-in to stop processing these write commands?

• Are there known edge cases or similar experiences where subsequent writeWithoutResponse calls are silently dropped after a failed instance?

• What debugging strategies or potential fixes could help isolate the root cause of this erratic behaviour?

I've spent several days troubleshooting this without finding a consistent reproduction path aside from prolonged testing. Any ideas or insights would be greatly appreciated.

Thanks in advance!

[peitschie]

Hi @gion-andri

That is an interesting screen-grab you have there.

Could there be an internal state issue within the BLE handling on Android that causes the plug-in to stop processing these write commands?

Yes. There is in fact a global queue of Bluetooth commands that could conceivably cause a single dead result to block every subsequent callback: https://github.com/capacitor-community/bluetooth-le/blob/main/src/bleClient.ts#L590-L616. (I suspect we can do better here, but haven't had the time to poke at how hard it would be to turn this into at least device-specific queues).

Are there known edge cases or similar experiences where subsequent writeWithoutResponse calls are silently dropped after a failed instance?

Things like #734 show the above queuing mechanism in play.

I believe these logs come out of Capacitor itself. It would be very interesting to get more from the nosier ADB logs for the device when the error occurs.

A few places in the plugin that are of interest (just brain-dumping these for future-us):

writeWithoutResponse relies on Android's own onCharacteristicWrite callbacks to behave correctly 1, 2, 3

Question: Does this characteristic only support a write without response?

Based on #104, it seems like if you try and do a no-response write, there are still some times when Android might actually send through a normal write that depends on a response. (You can use nrf Connect as an easy way to see exactly what modes are supported for a characteristic)

While doing some searching to see what might be causing your issue here though, I stumbled on this gem of information in a few places (I can't find the official source for this however): https://stackoverflow.com/a/43744888

The Bluetooth stack puts this packet in its internal buffer. If there is still more space in the buffer after enqueuing this packet, the onCharacteristicWrite callback is called, so you can immediately write another packet. When the buffer is full, it waits to call the onCharacteristicWrite callback until there is now 50% space (if I remember correctly) available in the buffer.

I wonder if the phone or BLE device is getting into a state where Bluetooth packets are no longer transmitting properly, thus the phone is never calling onCharacteristicWrite so we're never being allowed to queue up another packet.

Can you make the problem occur any more readily by increasing the frequency with which you're writing data?

[peitschie]

Just another point of interest:

There's supposed to be a timeout for each read/write call in effect (https://github.com/capacitor-community/bluetooth-le/tree/main?tab=readme-ov-file#timeoutoptions). In theory, the above condition (assuming it's a plugin problem) should clear up after that timeout if the queue is at fault.

If it remains permanently "dead", the chance is more likely that the phone or BLE device is getting into a failure mode.

[gion-andri]

@peitschie Thank you for your detailed reply. I tried to look at the things you pointed out. And I think, I found the issue.

I added quite some debugging output in the native android code to try to narrow down, where the issue occurs. I committed the logging code here, so you can see where the logoutput is coming from: main...gion-andri:bluetooth-le:debug-issue

A normal "write without response" command looks like that:

you can see the write method being called in the Device class, the callback coming in to the Device, the lookup for the timer and callback, and then the BluetoothLe class handling the data and returning to the capacitor JS bridge.

This happens as soon as the problem occurs:

In the screenshot, you can see two "write without response" commands. For the second, you can see the write method being called in the Device class, the callback coming in to the Device, but now the lookup for the callback key fails. The key is logged and is correct. But it is not found. Because you can see, the new command starts before the callback of the previous is cleaned up.

This also explains why the timeout does not work: The code is actually executed, but also here, the callback is not found by the key and thus can't be executed.

When looking at the code, I think this is the issue:

bluetooth-le/android/src/main/java/com/capacitorjs/community/plugins/bluetoothle/Device.kt

Lines 678 to 679 in ceb05ef

	callbackMap[key]?.invoke(CallbackResponse(true, value))
	callbackMap.remove(key)

I don't understand the timing inside the app, but it seems, that after invoking that success, a new write command is executed before the callback is removed from the list.

To fix this, we should probably copy the callback to a local variable, delete the callback from the map, and then call it:

  val callback = callbackMap[key]
  callbackMap.remove(key)
  callback?.invoke(CallbackResponse(true, value))

Can you follow my description? Should I open a pull request for this? Or does this require further investigation?

And I don't know, if the same could also happen on iOS. Maybe it would be safer to change the order of those two lines here too:

bluetooth-le/ios/Plugin/Device.swift

Lines 405 to 406 in ceb05ef

	callback!(false, value)
	self.callbackMap[key] = nil

[peitschie]

That certainly looks interesting @gion-andri

Have you had a chance to prove out that this fixes the issue locally for you?

I'd definitely welcome a pull request with this 🙂

[gion-andri]

Hi @peitschie,

Verifying the fix is challenging because the issue only surfaces under rare timing conditions—sometimes after 20 minutes, other times only after five hours. I’ve been running the tests continuously for several hours without seeing the failure, but given its intermittent nature, I can’t yet say with absolute confidence that it’s completely gone. I’ll keep the tests running to be sure.

In the meantime, I’ve opened PR #753 to swap the order of removing the callback from the map and invoking it, which should eliminate the race condition.