Android的BLE服务发现(BluetoothGatt#discoverServices())和低能耗与BR/EDR

Question

TLDR:服务发现结果discoverServices()是否会因底层传输(LE与BR/EDR)而有所不同？

我有一个混合模式蓝牙配件,提供蓝牙经典设备和蓝牙LE外设的独特功能.

Android无法发现配件的蓝牙LE GATT服务,除非您使用隐藏的peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE)API允许您强制使用其中任何一个TRANSPORT_LE或TRANSPORT_BREDR.

当我通过设备连接peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback)然后调用时,discoverServices()我只发现通用的服务UUID(并且只有在许多连接尝试失败后才会发送神秘状态133 onConnectionStateChange).

• "00001800-0000-1000-8000-00805f9b34fb"(通用访问)
• "00001801-0000-1000-8000-00805f9b34fb"(通用属性).

但是,当我调用隐藏peerBluetoothDevice.connectGatt(context, autoConnect, gattCallback, BluetoothDevice.TRANSPORT_LE)然后调用时,discoverServices()我得到完整的预期服务发现响应:

• "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"(我的定制服务)
• "00001800-0000-1000-8000-00805f9b34fb"(通用访问)
• "00001801-0000-1000-8000-00805f9b34fb"(通用属性).

这是预期的Android框架行为(怀疑它,因此隐藏API)？用这种"混合模式"操作设计外围设备是不好的形式？

Answer 1

这

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

从 API 23 开始，该方法是公开的，因此似乎是避免上述问题的公认方法。

该方法似乎已在该版本中引入到 AOSP android-5.0.0_r1，并且在 API 23 中公开之前的每个版本中都存在。因此，对于 API 级别 21 和 22 的设备，通过反射调用应该是安全的。对于使用早期平台版本的设备，Android 框架似乎没有提供缓解该问题的工具。