ble.startNotification not working with Android 9 or above

[SSGitAdmin]

I have the startNotification successfully working with 2 devices implementing BLE 4.1 and 4.2 on Android 8.1 platform. When I use the same code in Android platform 9 or above, the BLE 4.1 device does not return anything (success or error) - the BLE 4.2 device continues to work fine.

It is not the location permission etc. which are set, and both the BLE 4.1 and 4.2 devices scan, connect, disconnect, read, write works on all versions of the Android Platform.

This issue is only for the startNotification call. It does not give any return (sucess or error) on subscribe.

Not sure what might be different. Any guidance appreciated.

[SSGitAdmin]

BTW - I am using the BLE 5.28.0 version with Ionic 5.4.16.

[ASHBAW]

Might try looking at closed issue #805 - startNotification response empty [{},2] @android8.0.0.

You could also revert to 5.27.0

[SSGitAdmin]

Thanks ASHBAW. It is not related to the fix in #805. I have done that - I tried 5.27 version with same results (In 5.27 I used the resulting array directly, while in the 5.28 I use the first element of the resulting array).

As I mentioned this version 5.28.0 works in 8.1 and does not in 9 and 10 (using the result as the first element of the returned array).

[DCGoD]

@SSDevAdmin I agree, if you never see a response then I can't see how this is related to the array change. My first thoughts are how your service/characteristic is defined. I am dealing with similar (not exact) issues with Android 10/11 on some S10 and S20 phones. (Cypress PSOC 4, 4.1 devices here). The first thing I'd do is read out all the characteristics for the found device after connection / scan and see if they characteristic in question is showing the notify capability. Another thing to verify is to make sure you don't have an interrupt (or a delay) not being cleared on your module. I had a situation that was flooding the proc and causing whacky BLE behavior only for some specific Android devices. iOS never had an issue or even a glitch. Unfortunately it appears if the issue doesn't completely break this plugin, it won't be merged in. I get people are busy, but PRs from years ago still sitting in here? The plugin could use some cleanup to say the least.

[SSGitAdmin]

Thanks Markam. I have used the chrome inspect to verify the characteristic has both read and notify; also in the Android 8.1 platform it is working correctly. I connect, and I startNotification - I am not using any other interrupt in between.

As a check, I then commented out the startnotification and tried in a timed loop to read the characteristic and it gives values that are updated correctly.

Not sure what else to try - than kluging the looped read as a replacement for notification :-(

[DCGoD]

Thanks Markam. I have used the chrome inspect to verify the characteristic has both read and notify; also in the Android 8.1 platform it is working correctly. I connect, and I startNotification - I am not using any other interrupt in between.

As a check, I then commented out the startnotification and tried in a timed loop to read the characteristic and it gives values that are updated correctly.

Not sure what else to try - than kluging the looped read as a replacement for notification :-(

It's hard to say without seeing your implementation on the firmware side but generally it's related to how the characteristic is defined. Security, client control, etc.

For instance, I just discovered Android 10 on s20 devices won't reconnect to a module I have unless I wait until all auth commands are finished before I stop advertising on the module. Some are just pickier than others. Dabble around in the stack.

[tellybrown]

I can't say 100% I saw the same thing but essentially I was doing a connect and startnotification actually returned an ok but shortly thereafter it would tell me notifications stopped. Once I moved to autoconnect and doing things more asynchronously I think things are better now. It could just be that I wasnt as proficient with JS async/await and causing issues with things running in proper order. autoconnect -> connect callback -> check flag and startnotification autoconnect -> disconnect callback -> clear flag to restart notification on next connect

[SSGitAdmin]

Thanks @tellybrown. I will re-review my code, but it is indeed done async with OnConnect start notifications, and OnDisconnect stop notifications as you mention.

[MonksterFX]

Have any similar issue with my IPhone12. I'm connected correctly and I'm also recieving notfications but they are always emtpy.

[Dizi0]

I have the same issue (Xiaomi Redmi Note 7), I'm connected correctly and I can read characteristics , but notifications are empty (buffer.byteLentgh will return "undefined")

I tested my code with nRF connect, and everything worked fine, this package seems to be the issue,

Reverting to 5.27 fixed the issue

[Path-A]

Had the same issue and couldn't figure it out for hours. It turns out that something has changed in the newest version of the plugin. Instead of using the entire buffer, you need to grab the first element of the buffer: const data = new Uint8Array(buffer[0]);

What's really strange about this is that ble.read() still uses the entire buffer. I'm sure this discrepancy is causing a lot of headaches. Hopefully the docs get updated soon.

[SkyL4rk-original]

If anyone stumbles upon this thread after the Android10 upgrade, and using Cordova as the framework:

I had a new issue adding BLE into an existing application that used device back-button blocking. I could use all device BLE actions except the readings of the data array, and the starting of the notification process.

Removing ons.disableDeviceBackButtonHandler(), which I had in my code, solved this for me, and funnily enough, the app still functioned as intended with the back button handling.

[peitschie]

Just to confirm, are these complaints with using the raw plugin, or the ionic wrapped version? I haven't noticed any of these issues with the standalone functions, so would be interested in any code or reproduction steps showing this issue.

[peitschie]

I'm closing this out as my own tests have not shown any problems with Android 9 and startNotification calls. Please feel free to re-open if this issue is still occurring.