Addressing the "horror list" of BLE

[RobLewis]

I first saw this a year ago, and don't know if it has been updated since: Android BLE Issues

In any case, it details some of the many problems programmers can run into with Android BLE. It's published by a competitor, but I wonder if the Polidea folks might like to comment on it.

(Personally I haven't run into a lot of problems using RxAndroidBle, so maybe the library works around these issues under the covers.)

[RobLewis]

Update: today I am near cross-eyed from trying to plumb the mysteries of Android BLE Bonding (which is often called "pairing"—even by Google—though I think this is incorrect). I would give a lot for a clear, simple, complete, and correct explanation of these issues. I realize this may be impossible due to the discrepancies between implementations on Android devices, but it's something to hope for.

[uKL]

This is a huge list with some magic behind. So-called Bonding/Binding/Authorization/etc was already mentioned in #35 and I hope it will be included someday.

This list indeed could be a helpful source of ideas for new features. Are there any you/community is especially interested in?

[RobLewis]

A few that come to mind: --Use occasional bursts of scanning to simulate continuous scanning (which, according to the article, is guaranteed to fail eventually) --Automatically re-establish dropped connections --Automatic management of the AutoConnect flag (determine what works best for a given pair of devices and remember it for the future) --Provide a global Bluetooth reset if things get completely screwed up

[dariuszseweryn]

I have looked on the list quite some time ago already and I think that it is meant to be more a "scareware" than a list of issues. Though there are valid points there.

A few thoughts about the features mentioned in the post above:

--Use occasional bursts of scanning to simulate continuous scanning (which, according to the article, is guaranteed to fail eventually)

The scanning on Android is quite energy consuming and the settings are automatically managed by the OS. After a while even the LOW_LATENCY scan is turned into OPPORTUNISTIC mode. I do not think that fighting against the OS is a good idea. There is however a new ,%20android.bluetooth.le.ScanSettings,%20android.app.PendingIntent)" rel="nofollow" target="_blank" >scan API that could be fit for prolonged/background scanning.

--Automatically re-establish dropped connections

This I think is very use-case dependent. Usually the connections are somehow stateful and restoring the state may be different for each project. Restoring the connection should be done on the RxJava layer above the library. The library itself should only make it possible to do.

--Automatic management of the AutoConnect flag (determine what works best for a given pair of devices and remember it for the future)

I think that this point is a bit misleading in the mentioned list. Some devices (i.e. Samsung) after turning on the BluetoothAdapter need to scan a BluetoothDevice before BluetoothDevice.connectGatt() call would succeed. Using autoConnect=true does just that—it starts a periodic, low-powered scan in the background and connects after the peripheral is scanned. Although it would be a good idea to have this fixed somehow. The best solution would be to find out when a direct connection would fail and the start a scan before connecting.

--Provide a global Bluetooth reset if things get completely screwed up

Could be useful though I have not been in a situation where I would need to do such things for quite a long time now. This was the case mostly for devices with API 18, 19 which are a margin right now.

Best Regards