Android BLE出乎意料地反复重新连接到外围设备

Question

我正在开发一个与BLE设备接口的Android应用程序，最近偶然发现了一些奇怪的行为：当应用程序与设备断开连接时，几秒钟后似乎建立了连接。

我正在更充分地描述问题，并一直专注于蓝牙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版本。有几个优秀的（或最近修复的）具有相关行为的错误，其中一些指向API版本> 23;然而，我后来能够在API 23上进行复制。

• BLE: Having two pending direct connections and cancelling the second one does not work
• BLE: Disconnecting/closing GATT directly after connect sometimes has no effect due to race conditions
• BLE: Closing gatt object or app does not remove pending connection since Android N
• Race condition in BluetoothGatt when using BluetoothDevice#connectGatt()

我觉得这有一点做与PBAP/MAP配置文件。相反，它们在日志中的存在仅仅指向这些配置文件在任何BLE断开的情况下被激活。虽然没有显示重新连接行为，但在与TI SensorTag混淆时，我能够看到类似的PBAP/MAP激活：这些配置文件再次记录了任何断开连接（与我的应用程序无关）。受影响的设备

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

列表：

• 三星S6 - API 23
• 三星S7 - API 23
• Samsung S7 Edge - API 24
• Sony Xperia Z5 Compact - API 24
• 摩托罗拉Droid涡轮2 - API 24
• 的Nexus 5X - API 25
• 谷歌像素 - API 25

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提供了详细的错误报告，但我还没有收到他们的回复。

Answer 2

我也只是碰到这种问题制定蓝牙BLE应用跌跌撞撞。我的Android设备是带有API 24的索尼（http://www.gsmarena.com/sony_xperia_x_performance-7949.php）。它是从API 23升级而来的。从Android 6 - > 7.

它没有SIM卡，所以我不认为SIM卡有什么区别。但它有一个SIM卡插槽，所以也许这就是你的意思。

它配备了BLE芯片版本4.2 - 不确定是否属于您的问题。我今天将尝试更多地处理这个问题。

Answer 3

这似乎是固定在Spotify 8.4.19.792开始2017-09-14发布。