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

Question

TLDR：是否预计通过 discoverServices() 的服务发现结果会根据底层传输（LE 与 BR/EDR）而有所不同？

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

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

当我通过 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）？用这个 'mixed mode' 操作设计外围设备是不是不好的形式？

Answer 1

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

方法是 public 自 API 23 起，因此似乎是避免上述问题的认可方法。

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