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

10
votes

TLDR: Is it expected that service discovery results via discoverServices() 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?

1
androidbluetooth-lowenergyandroid-bluetooth
If i remember correctly, when your Beacon advertizes BR/EDR support, android defaults to use it, which results in errors. See stackoverflow.com/a/31369286/3623345 and the corresponding thread. If this is WAI, or if there is at least a good reasson to do so, i dont know. – Dominik Gebhart
Sorry, i linked the wrong post. In stackoverflow.com/a/31148924/3623345 is also a link to a google bug report about this issue (code.google.com/p/android/issues/detail?id=58896) dating back to 2013 still being listed as "New"... – Dominik Gebhart

1 Answers

4
votes

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.