Android: Scan only detects the device after the third consecutive attempt or more

[davixz]

Hey guys,

We always used version 1.2.5 and it worked fine.

Now google forced us to update to support android 12+

So we had to move to version 1.5.0+ of this plugin.

But when we do so, we get this problem.

[peitschie]

Hi @davixz... certainly sounds interesting! How long are you scanning for on each attempt?

From the plugin itself, there's very little change in the scanning paths between those versions. The key impact that I can think of here are all on the Android side of things, due to the higher target SDK versions.

As of Android 13, there is a neverForLocation permission that this plugin sets by default which has been shown to filter out some beacon types, and may possibly cause throttled scan reporting from Android itself: https://developer.android.com/guide/topics/connectivity/bluetooth/permissions#assert-never-for-location.

If you are game, it might be worth trying out cordova-plugin-ble-central@slim, which is the same plugin but with all the Android permissions stripped out so you control these yourself. This would allow you to see if the scanning is more responsive if you remove the neverForLocation permission.

See this comment for more details: #943 (comment)

Let me know how you go!

[davixz]

Hey @peitschie

Thank you for the support,

I tried the slim 1.6.3 version but even removing the neverForLocation flag it make very little difference.

The scan and connection is not consistent as it were in the past like version 1.2.5

We are using 8000 ms as scan timeout

[peitschie]

Reviewing the changes between those versions, v1.3.1 of the plugin switched to the new BluetoothLeScanner API, as the previous BluetoothAdapter.startLeScan was deprecated: #796

I wonder if there is a functional difference between these two interfaces which is causing the behaviour you may be seeing.

If you haven't already, can you perhaps try ble.startScanWithOptions with some of options there set to be more power-aggressive? https://github.com/don/cordova-plugin-ble-central#startscanwithoptions

The key one here is to try setting scanMode: "lowLatency", as the default option there from android is lowPower (as per the Android docs)

Using matchMode: "aggressive" might also impact things.

[davixz]

Thank you so much for the help @peitschie ill try it out

[davixz]

Hey @peitschie thank you so much!

It seems that ble.startScanWithOptions with the option scanMode: "lowLatency" fixes the issue for us!

You are the man!

[peitschie]

That's fantastic news @davixz ! Appreciate you taking the time to report back how it's gone. Always nice to resolve an issue 🙂

[mikerusso-tsi]

Yes, I too have seen a major drop-off in scanning performance of standard peripherals devices (i.e., non-beacon). And this is in the cozy confines of my office - I shudder to think what we'll see out on a factory floor! I wonder if you will need to change the plugin so it will use the low-latency option by default to accommodate for this severity of performance loss??

The trouble with the low-latency option work-around (above) is that I haven't been using ble.startScanWithOptions() or even ble.startScan(), I use ble.scan(), which takes no options. For now, I suppose I'll need to change to the ble.startScanWithOptions() paradigm. It's too bad one of the options isn't the timeout parameter of the ble.Scan() call!

[peitschie]

I wonder if you will need to change the plugin so it will use the low-latency option by default to accommodate for this severity of performance loss??

I'm not really wanting to replace the OS's default preference here. The impact of the scanning mode is heavily dependent on how frequently the BLE device is advertising, so it's not guaranteed that low latency is important for all (or even most) situations. The downside of defaulting to the low latency mode is that the higher battery usage may get an application flagged to a user as consuming too much battery (unlikely, but it certainly would be a nasty surprise for a developer).

It's too bad one of the options isn't the timeout parameter of the ble.Scan() call!

I like this idea! It allows me to lean out the native implementations a bit as well. I'll raise a PR for this (won't get a chance to test & release this weekend probably), but if you're game to try it out or review, any feedback would be welcome @mikerusso-tsi

[peitschie]

@mikerusso-tsi have a look here: #967

If you want to try it out locally, you can install cordova plugins directly from branches like this:

npm install don/cordova-plugin-ble-central#scan-with-timeout