安卓蓝牙低功耗（BLE）会意外地并反复地重新连接到外围设备

Question

我正在开发一款与BLE设备进行接口交互的Android应用程序，并最近遇到了一些奇怪的问题：当应用程序与设备断开连接后，几秒钟后似乎会有其他东西重新建立连接。

我正在逐步确定问题并专注于Bluetooth MAP和PBAP配置文件； 它们在问题点附近出现在日志中。 但我不确定这是否是根本原因，也没有找到解决方法。

该应用程序支持API 23-25。 到目前为止，我只在存在SIM卡的手机上遇到过此问题，这再次指向PBAP，因为许多手机似乎仅在使用SIM卡时支持此配置文件。 但我尚未能够在API 23上重现此问题，但现在这些测试手机没有SIM卡。

BLE设备与汽车应用程序无关，也无法处理联系人或消息。 我没有在应用程序中故意启用任何此类功能。 此外，我的应用程序与设备之间没有配对/绑定，设备也不支持配对/绑定。

大多数情况下，尝试重新连接仅发生一次，在应用程序通过设备断开连接的几秒钟后。 应用程序中的随后连接-断开连接序列具有相同的行为。 但是，我至少看到过一种情况，即重新连接（在应用程序外部）每隔几秒钟就会无限期地继续。

似乎唯一可以短期解决问题的方法是循环打开手机上的蓝牙或强制停止蓝牙共享进程。 我不认为重新连接会自己恢复，但是当用户通过我的应用程序连接/断开连接设备时，它们通常会重新出现。

我对PBAP / MAP并不十分熟悉，因此不知道它们如何启用或者如果可能的话如何禁用它们。 我不确定它们是否是罪魁祸首，但它们在重新连接的那一刻出现在日志中。

以下是关于设备断开连接和随后重新连接的日志语句。 此处的接口名称是“Foo04”，MAC = B0：B4：48：E8：FA：04。

03-31 14:27:44.305 D/RxBle#Radio(14105):  STARTED RxBleRadioOperationDisconnect(186827491)
03-31 14:27:44.319 D/BluetoothManager(14105): getConnectionState()
03-31 14:27:44.320 D/BluetoothManager(14105): getConnectedDevices
03-31 14:27:44.332 D/BluetoothGatt(14105): cancelOpen() - device: B0:B4:48:E8:FA:04
03-31 14:27:44.334 D/BtGatt.GattService(13168): clientDisconnect() - address=B0:B4:48:E8:FA:04, connId=5
03-31 14:27:44.339 E/bt_btif (13168): bta_gattc_mark_bg_conn unable to find the bg connection mask for: b0:b4:48:e8:fa:04
03-31 14:27:44.340 D/BtGatt.GattService(13168): onDisconnected() - clientIf=5, connId=5, address=B0:B4:48:E8:FA:04
03-31 14:27:44.341 D/BluetoothGatt(14105): onClientConnectionState() - status=0 clientIf=5 device=B0:B4:48:E8:FA:04
03-31 14:27:44.342 D/RxBle#BluetoothGatt(14105): onConnectionStateChange newState=0 status=0
03-31 14:27:44.345 D/RxBle#Radio(14105): FINISHED RxBleRadioOperationDisconnect(186827491)
03-31 14:27:44.352 D/BluetoothGatt(14105): close()
03-31 14:27:44.352 D/BluetoothGatt(14105): unregisterApp() - mClientIf=5
03-31 14:27:44.354 D/BtGatt.GattService(13168): unregisterClient() - clientIf=5
03-31 14:27:45.376 W/bt_l2cap(13168): l2cble_process_conn_update_evt: Error status: 22
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
03-31 14:27:45.377 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:13 reason:22
03-31 14:27:45.381 E/BluetoothRemoteDevices(13168): state12newState1
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:45.402 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action = 
03-31 14:27:45.404 D/BluetoothPbapReceiver(13168): Calling start service with action = null
03-31 14:27:45.405 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:46.407 W/bt_smp  (13168): smp_br_connect_callback is called on unexpected transport 2
03-31 14:27:46.408 W/bt_btif (13168): bta_dm_acl_change info: 0x0
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 D/bt_btif_dm(13168): remote version info [b0:b4:48:e8:fa:04]: 0, 0, 0
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=16 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.412 E/BluetoothRemoteDevices(13168): state12newState0
03-31 14:27:46.457 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth connect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:47.317 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl()
03-31 14:27:48.421 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK ON using UART driver's ioctl()
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
03-31 14:27:48.483 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:14 reason:22
03-31 14:27:48.488 E/BluetoothRemoteDevices(13168): state12newState1
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:48.524 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action = android.bluetooth.device.action.ACL_DISCONNECTED
03-31 14:27:48.527 D/BluetoothPbapReceiver(13168): Calling start service with action = null
03-31 14:27:48.530 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04
03-31 14:27:49.430 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl()

进一步的调查

我在 Android BLE ACL_DISCONNECTED sometimes delayed 中发布了相关问题。

我见过这个问题的设备中有一个共性，那就是存在 SIM 卡，但另一个共性是 API 24 或 25。我还没有能够在 API 23 设备或者不管是哪个版本，只要没有物理安装 SIM 卡的设备上重现该问题。

经过更深入的调查，我对 SIM 卡的怀疑度降低了，而对 API 版本的怀疑度增加了。有几个未解决（或最近已解决）的 bug 与此行为有关，其中一些指向 API 版本 > 23；然而，我后来也能够在 API 23 上重现该问题。

• BLE：拥有两个挂起的直接连接并取消第二个连接无法工作
• BLE：直接连接后直接断开 / 关闭 GATT 有时没有效果，原因是竞态条件
• BLE：自 Android N 以来关闭 Gatt 对象或应用程序不会删除挂起的连接
• 在使用 BluetoothDevice#connectGatt() 时，BluetoothGatt 中存在竞态条件

我感觉这与 PBAP/MAP 档案关系不大。相反，日志中存在这些档案只是指这些档案被激活并随着任何 BLE 断开而记录。虽然没有表现出重新连接的行为，但我在玩 TI SensorTag 时也能看到类似的 PBAP/MAP 活动：这些档案再次记录了任何断开（与我的应用无关）。

受影响的设备列表

我已经能够在以下设备上以不同程度地重现此问题：

• Samsung S6 - API 23
• Samsung S7 - API 23
• Samsung S7 Edge - API 24
• Sony Xperia Z5 Compact - API 24
• Motorola Droid Turbo 2 - API 24
• Nexus 5x - API 25
• Google Pixel - API 25

- Steve Yohanan

---

我最近也遇到了这个问题，正在开发一个蓝牙BLE应用程序。我的Android设备是索尼（http://www.gsmarena.com/sony_xperia_x_performance-7949.php），使用API 24。它从API 23升级而来，从Android 6 -> 7。它没有SIM卡，所以我认为SIM卡不会有影响。但它确实有一个SIM卡插槽，也许这就是你的意思。它配备了BLE芯片版本4.2 - 不确定你的问题是否与此相关。我今天会继续研究这个问题。 - Ulf Karlsson

Answer 1

经过大量调查，我确定了我的问题根源：Spotify。

在Android设备上安装Spotify就足以表现出这种异常行为；用户不需要登录或启动Spotify应用程序。卸载或强制停止该应用程序在所有情况下都可以纠正此问题。

似乎Spotify有一个服务用于注册从任何蓝牙外围设备的断开连接。当系统通知Spotify时，该服务立即连接到刚刚断开的外围设备，我没有去描述来自Spotify的通信。大约5秒后，连接会断开；然而，由于Spotify被通知蓝牙断开事件，服务又会尝试与外围设备连接。这实际上是一个无限循环，只有通过强制停止Spotify或在Android设备上循环蓝牙才能中止。

为了进行调查，我开发了一个简单的应用程序，它会被通知并报告蓝牙连接和断开（ACL_CONNECTED，ACL_DISCONNECTED）事件。我在Android设备上使用BLE扫描器连接/断开各种蓝牙外围设备。我的测试应用程序将显示我与外围设备的初始交互，然后是无限流的连接和断开事件。同样，这将继续直到强制停止Spotify。

以下是示例日志记录...

04-10 19:56:24.109  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:32.057  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:34.197  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:40.396  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:43.857  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:56:49.962  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:56:51.130  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:17.348  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:57:17.927  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:37.621  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
04-10 19:57:38.157  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED
04-10 19:57:44.364  D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED
...

确定Spotify是根本原因很困难。

我的第一个提示是通过查看“开发者选项”->“运行的服务”，注意到Spotify经常弹出，与外围连接/断开相关联。

最后，我采取排除法：一旦异常行为开始，我会选择性地浏览已安装应用的列表，强制停止可能对蓝牙有些兴趣的应用程序，最终看到当我停止Spotify时，问题立即消失了。

我几周前向Spotify提供了详细的错误报告，但至今尚未收到回复。

- Steve Yohanan

Answer 2

这个问题似乎在2017年9月14日发布的Spotify 8.4.19.792版本中得到了解决。

- Pete Doyle