dbro dbro - 2 months ago 24
Android Question

Android's BLE Service Discovery (BluetoothGatt#discoverServices()) and Low Energy vs BR/EDR

TLDR: Is it expected that service discovery results via

will differ based on the underlying transport (LE vs. BR/EDR)?

I have a mixed-mode Bluetooth accessory that offers distinct features as a Bluetooth Classic device and as a Bluetooth LE Peripheral.

Android has trouble discovering the accessory's Bluetooth LE GATT services unless you use the hidden
peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE)
API that allows you to force use of either
TRANSPORT_LE
or
TRANSPORT_BREDR
.

When I connected the device via
peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback)
and then called
discoverServices()
I'd only discover the generic Service UUIDs (and only after many failed connection attempts with mysterious status 133 delivered to
onConnectionStateChange
).


  • “00001800-0000-1000-8000-00805f9b34fb” (Generic Access)

  • “00001801-0000-1000-8000-00805f9b34fb” (Generic Attribute).



However, when I invoke the hidden
peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE)
and then called
discoverServices()
I get the full expected service discovery response:


  • "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" (My custom service)

  • “00001800-0000-1000-8000-00805f9b34fb” (Generic Access)

  • “00001801-0000-1000-8000-00805f9b34fb” (Generic Attribute).



Is this expected Android framework behavior (Doubt it, hence hidden API)? Is it bad form to design a peripheral device with this 'mixed mode' operation?

Answer

The

BluetoothDevice.connectGatt(Context context, boolean autoConnect, android.bluetooth.BluetoothGattCallback callback, int transport)

method is public as of API 23, and so seems to be the sanctioned way of avoiding the problem described above.

The method appears to have been introduced to AOSP in the android-5.0.0_r1 release, and was present in every release leading up to it being made public in API 23. Therefore, it should be safe to invoke via reflection for devices with API levels 21 and 22. For devices with prior platform versions, it appears the Android framework does not provide tools to mitigate the issue.

Comments