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

Question

TLDR:是否预期服务发现结果是通过 discoverServices() 产生的？会根据底层传输(LE 与 BR/EDR)而有所不同吗？

我有一个混合模式蓝牙配件，它提供了作为蓝牙经典设备和蓝牙 LE 外围设备的独特功能。

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

当我通过 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 开始公开，因此似乎是避免上述问题的认可方法。

该方法似乎是 introduced在 android-5.0.0_r1 版本中添加到 AOSP，并且出现在每个版本中，直到它在 API 23 中公开。因此，对于 API 级别 21 和 22 的设备，通过反射调用应该是安全的。对于具有先前平台版本的设备，Android 框架似乎没有提供缓解该问题的工具。