RxAndroidBle icon indicating copy to clipboard operation
RxAndroidBle copied to clipboard

Enforce LE transport mode for dual-mode (LE/EDR) peripherals

Open dariuszseweryn opened this issue 6 years ago • 14 comments

Summary

Double mode devices (LE/EDR) can be connected in both modes in which situation Android tends to use the EDR mode. There is at least one known behaviour related—in EDR mode specific services may not be discovered correctly. As RxAndroidBle is library aiming on BLE devices the BLE mode should be forces where possible.

dariuszseweryn avatar Sep 01 '17 18:09 dariuszseweryn

Small point, but I think the official Bluetooth term for these devices is "dual-mode".

I wonder if we will see "treble-mode" devices that also support Bluetooth Mesh :-)

RobLewis avatar Sep 02 '17 16:09 RobLewis

Thanks for pointing that. English is not my first language and I have added this issue quite late in the evening. ;)

dariuszseweryn avatar Sep 02 '17 20:09 dariuszseweryn

@dariuszseweryn as far as I know we already do that. BleConnectionCompat is enforcing TRANSPORT_LE on AndroidM+.

Would you like to go further and use hidden API introduced by the https://android.googlesource.com/platform/frameworks/base/+/b88fa824ab6337684de9aa8437c4952df4f1a75e%5E%21/ ?

uKL avatar Nov 21 '17 08:11 uKL

Yes—that is what I had in mind—it may fix some issues on <M. We would need to track on which Android SDK this method was introduced.

dariuszseweryn avatar Nov 21 '17 12:11 dariuszseweryn

It looks like it was introduced with 5.0.0 here: https://android.googlesource.com/platform/frameworks/base/+/android-5.0.0_r1/core/java/android/bluetooth/BluetoothDevice.java

Android L preview didn't have it.

uKL avatar Nov 21 '17 12:11 uKL

So it could be valueable to use the method by reflection on Android L even if autoConnect=false. It could help with service discovery and potentially bonding problems

dariuszseweryn avatar Nov 21 '17 12:11 dariuszseweryn

Bonding has it’s own, separate call. There is a hidden createBond method, allowing to force bonding over LE.

uKL avatar Nov 21 '17 12:11 uKL

But maybe it would help in situation when the Android OS does kick-off bonding after GATT_INSUF_AUTH response to read/write characteristic?

dariuszseweryn avatar Nov 21 '17 13:11 dariuszseweryn

@dariuszseweryn We encountered a weird issue when the app and the BLE device were exchanged data back and forth and suddenly the connection was disconnected by "BleDisconnectedException: Disconnected from 7C:**:**:**:**:** with status 8 (GATT_INSUF_AUTHORIZATION)". This often happens if the app runs on the Moto G (4) phone.

Does GATT_INSUF_AUTHORIZATION mean that, bonding has just got lost in that case based on your understanding? Also, I saw this answer https://stackoverflow.com/a/48956494/2563009 (on the question that you guys mentioned on https://github.com/Polidea/react-native-ble-plx/wiki/Device-Bonding) claimed that if using TRANSPORT_BREDR for the transport option, it will somehow fix the random lost of bonding. What do you think about it? Did you guys ever try that transport option?

thuytrinh avatar Sep 27 '18 15:09 thuytrinh

We are using TRANSPORT_LE whenever possible and it was a deliberate decision. Earlier versions of Android did pose difficulties when TRANSPORT_BREDR or TRANSPORT_AUTO was selected. In fact this is a BLE library hence the TRANSPORT_LE

From my experience the GATT_INSUF_AUTHORIZATION should not disconnect the peripheral but only reject a characteristic write/read. I have seen disconnections (even Today in fact) with status 8 which were not connected with bonding as the peripheral did not support bonding at all (from my knowledge). So I think that this may be a misattribution.

dariuszseweryn avatar Sep 27 '18 16:09 dariuszseweryn

I have seen disconnections (even Today in fact) with status 8 which were not connected with bonding as the peripheral did not support bonding at all (from my knowledge).

The peripheral which I tested does actually support bonding. We didn't encounter this GATT_INSUF_AUTHORIZATION on other phones such as some Samsung phones & Google Pixel 2 XL. So that makes me thinking that this is a problem of the bluetooth stack included in the Android OS of the Moto G phone.

thuytrinh avatar Sep 27 '18 22:09 thuytrinh

Hi! I'm wondering if at the moment of the connection you're passing the Transport_le parameter to the connectGatt call. I've navigated to the connection operation in the library and I see that you're just passing three parameters: f

inal BluetoothGatt bluetoothGatt = connectionCompat .connectGatt(bluetoothDevice, autoConnect, rxBleGattCallback.getBluetoothGattCallback());

How can we add the fourth parameter there?

Thanks!

joaquinalegatti avatar Oct 15 '18 18:10 joaquinalegatti

@joaquinlateral You need to go deeper™

ConnectionCompat is library's code

dariuszseweryn avatar Oct 15 '18 20:10 dariuszseweryn

I have seen disconnections (even Today in fact) with status 8 which were not connected with bonding as the peripheral did not support bonding at all (from my knowledge).

The peripheral which I tested does actually support bonding. We didn't encounter this GATT_INSUF_AUTHORIZATION on other phones such as some Samsung phones & Google Pixel 2 XL. So that makes me thinking that this is a problem of the bluetooth stack included in the Android OS of the Moto G phone.

Same issue here. Only on Samsung Galaxy Note9 - Android 10.

@thuytrinh Have you found any solution for this issue?

Drjacky avatar Nov 30 '20 11:11 Drjacky