Android 的 BLE 服务发现 (BluetoothGatt#discoverServices()) 和 Low Energy vs BR/EDR答案

【问题标题】：Android's BLE Service Discovery (BluetoothGatt#discoverServices()) and Low Energy vs BR/EDRAndroid 的 BLE 服务发现 (BluetoothGatt#discoverServices()) 和 Low Energy vs BR/EDR
【发布时间】：2015-08-19 16:39:23
【问题描述】：

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

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

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

当我通过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）？用这种“混合模式”操作设计外围设备是不是很糟糕？

【问题讨论】：

如果我没记错的话，当你的 Beacon 宣传 BR/EDR 支持时，android 默认使用它，这会导致错误。请参阅stackoverflow.com/a/31369286/3623345 和相应的线程。如果这是 WAI，或者至少有充分的理由这样做，我不知道。
对不起，我链接错误的帖子。在stackoverflow.com/a/31148924/3623345 中还链接到关于此问题的 Google 错误报告 (code.google.com/p/android/issues/detail?id=58896)，该问题可追溯到 2013 年，但仍被列为“新”...

标签： android bluetooth-lowenergy android-bluetooth

【解决方案1】：

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

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

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

【讨论】：