Android BLE 意外并反复重新连接到外围设备 [英] Android BLE unexpectedly and repeatedly reconnects to peripheral
问题描述
我正在开发一个与 BLE 设备接口的 Android 应用程序，最近偶然发现了一些奇怪的行为:当应用程序与设备断开连接时，几秒钟后其他东西似乎建立了连接.
I am developing an Android app that interfaces with a BLE device and recently stumbled across some strange behavior: when the app disconnects from the device, a few seconds later something else seems to establish the connection.
我正在更全面地描述问题的特征，并一直专注于蓝牙 MAP 和 PBAP 配置文件；它们出现在问题点周围的日志中.但是，我不确定这是否是根本原因，我也没有找到解决方法.
I am in the process of characterizing the issue more fully and have been focused on the Bluetooth MAP and PBAP profiles; they show up in the logs around the point of issue. I am unsure, however, if this is the root cause, nor have I found a workaround.
该应用支持 API 23-25.迄今为止，我只在带有 SIM 卡的手机中遇到过这个问题，这再次指向 PBAP，因为许多手机似乎仅通过 SIM 卡支持此配置文件.我还没有能够在 API 23 上重现，但目前这些测试手机没有 SIM 卡.
The app supports API 23-25. To date, I have only experienced the issue in phones with SIM cards present, which points again to PBAP since many phones seem to support this profile only with a SIM card. I haven't yet been able to reproduce on API 23, but for now those test phones do not have SIM cards.
BLE 设备与汽车应用无关，也没有处理联系人或消息的能力.我没有故意在应用程序中启用任何这些.此外，我的应用和设备之间没有配对/绑定，设备也不支持配对/绑定.
The BLE device has nothing to do with automotive application, nor does it have the ability to deal with Contacts or Messaging. I haven't intentionally enabled any of this within the app. Furthermore, there is no pairing / bonding between my app and the device, nor does the device support pairing / bonding.
在大多数情况下，在设备通过应用断开连接后的几秒钟内，会尝试重新连接一次.应用程序中的后续连接-断开序列具有相同的行为.但是，我至少在一个实例中看到，重新连接(在应用程序之外)每隔几秒就会无限期地继续.
In most cases, the attempt to reconnect happens once, a few seconds after device disconnect via the app. Subsequent connect-disconnect sequences in the app have the same behavior. However, I have seen in at least one instance where the reconnects (outside of the app) continue indefinitely every few seconds.
似乎可以在短期内解决问题的唯一方法是在手机上循环使用蓝牙，或者强制停止蓝牙共享过程.我不相信重新连接会自行恢复，但是一旦用户通过我的应用与设备连接或断开连接，它们会重新出现是很常见的.
The only thing that seems to resolve the issue short-term is to cycle Bluetooth on the phone, or force-stop the Bluetooth Share process. I don't believe the reconnects come back on their own, but it is common that they do reappear once the user connects-disconnects with the device through my app.
我对 PBAP/MAP 不是很熟悉，所以我不知道它们是如何启用的，或者如果可能的话，如何禁用它们.我不确定它们是否是罪魁祸首，但它们会在重新连接时出现在日志中.
I am not very familiar with PBAP / MAP so am unaware how they get enabled or, if possible, how to disable them. I am not sure if they are the culprit, but they appear in the logs at the moment of reconnect.
以下是关于断开连接和随后重新连接的日志语句.这里的接口名称是Foo04"，MAC = B0:B4:48:E8:FA:04.
Following is the log statements around the point of disconnection and subsequent reconnection. The interface name here is "Foo04" with 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 有时会延迟中发布了一个相关问题.
I posted a related question in Android BLE ACL_DISCONNECTED sometimes delayed.
我发现问题的设备的一个共同点是存在 SIM 卡，但另一个是 API 24 或 25.我还没有能够在 API 23 设备上重现，或者无论如何一个没有实际安装SIM卡的版本.
One commonality among the devices where I've seen the problem has been the existence of a SIM card, but another one is API 24 or 25. I haven't yet been able to reproduce on an API 23 device or, regardless of version, one without a SIM card physically installed.
经过进一步调查，我不太怀疑是 SIM 卡，更多的是 API 版本.有几个突出的(或最近修复的)错误具有相关行为，其中一些指向 API 版本 > 23；但是，我随后能够在 API 23 上重现.
After even further investigation, I'm less suspect of the SIM card, and more of the API version. There are several outstanding (or recently fixed) bugs that have related behavior, some of which points to API versions > 23; however, I have subsequently been able to reproduce on API 23.
- BLE:有两个待处理的直接连接并取消第二个不会工作
- BLE:连接后直接断开/关闭 GATT 有时没有效果，因为竞争条件
- BLE:自 Android 以来，关闭 gatt 对象或应用程序不会删除挂起的连接否
- 使用 BluetoothDevice#connectGatt() 时在 BluetoothGatt 中的竞争条件
我觉得这与 PBAP/MAP 配置文件关系不大.相反，它们在日志中的存在仅表明这些配置文件在任何 BLE 断开连接时被激活.虽然没有表现出重新连接行为，但在使用 TI SensorTag 时，我能够看到类似的 PBAP/MAP 激活:这些配置文件再次记录了任何断开连接(与我的应用程序无关).
I'm feeling this has little to do with PBAP / MAP profiles. Rather, the existence of them in the logs points simply to these profiles being activated with any BLE disconnection. While not manifesting the reconnection behavior, I was able to see similar PBAP / MAP activation when messing with a TI SensorTag: these profiles again logged any disconnect (unrelated to my application).
受影响设备列表
我已经能够在以下设备上不同程度地重现此问题:
I've been able to reproduce this issue, to varying degrees, on the following devices:
- 三星 S6 - API 23
- 三星 S7 - API 23
- 三星 S7 Edge - API 24
- 索尼 Xperia Z5 Compact - API 24
- 摩托罗拉 Droid Turbo 2 - API 24
- Nexus 5x - API 25
- Google 像素 - API 25
推荐答案
经过大量调查，我能够确定问题的根本原因:Spotify.
After a great deal of investigation, I was able to determine the root cause of my issue: Spotify.
在 Android 设备上安装 Spotify 就足以体现这种异常行为；用户无需登录或启动 Spotify 应用程序.在所有情况下都卸载或强制停止应用程序纠正了问题.
Having Spotify installed on the Android device was enough to manifest this aberrant behavior; the user need not have logged into or ever started the Spotify app. Uninstalling or force-stopping the app in all cases rectified the issue.
似乎 Spotify 有一项服务可以注册与任何蓝牙外围设备的断开连接.当系统通知 Spotify 时，该服务会立即连接到刚刚断开连接的外围设备——我没有费心去描述来自 Spotify 的通信.约 5 秒后连接断开；然而，由于 Spotify 收到蓝牙断开连接事件的通知，该服务再次尝试与外围设备连接.这实际上是一个无限循环，只能通过强制停止 Spotify 或在 Android 设备上循环蓝牙才能中止.
It appears that Spotify has a service that registers for disconnects from any bluetooth peripheral. When the system notifies Spotify, the service immediately connects to the just-disconnected peripheral --- I didn't bother to characterize the communication from Spotify. After ~5 seconds the connection is dropped; however, since Spotify is notified of bluetooth disconnection events, the service again tries to connect with the peripheral. This effectively is an infinite loop that can be aborted only by force-stopping Spotify or cycling bluetooth on the Android device.
为了进行调查，我开发了一个简单的应用程序，它会通知和报告蓝牙连接和断开连接(ACL_CONNECTED、ACL_DISCONNECTED)事件.我在我的 Android 设备上使用了 BLE 扫描仪，并与各种蓝牙外围设备连接/断开连接.我的测试应用程序将显示我与外围设备的初始交互，然后是无限的连接流，然后断开连接事件.同样，这种情况会一直持续到 Spotify 被强制停止.
To investigate, I developed a simple app that is notified of and reports bluetooth connection and disconnection (ACL_CONNECTED, ACL_DISCONNECTED) events. I used a BLE scanner on my Android device and connected / disconnected with a variety of bluetooth peripherals. My test app would show my initial interaction with the peripheral followed by an infinite stream of connect then disconnect events. Again, this would continue until Spotify was force-stopped.
以下是日志记录示例...
Following is example logging...
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 是根本原因.
It was difficult to determine Spotify was the root cause.
我的第一个迹象是通过查看开发者选项 -> 运行服务并注意到 Spotify 定期弹出与外围设备连接/断开相关.
My first indication was through looking at Developer Options -> Running Services and noting Spotify regularly popping up correlated with peripheral connection / disconnection.
最后，它归结为消除过程:一旦异常行为开始，我有选择地浏览已安装的应用程序列表，强制停止可能对蓝牙感兴趣的应用程序，最终发现问题停止当我停止 Spotify 时立即.
In the end, though, it came down to process of elimination: Once the aberrant behavior started, I selectively went through the list of installed apps, force-stopping ones that likely had some interest in bluetooth, eventually seeing the issue cease immediately when I stopped Spotify.
几周前我向 Spotify 提供了详细的错误报告，但我还没有收到他们的回复.
I have provided a detailed bug report to Spotify several weeks ago, but I have yet to hear back from them.
这篇关于Android BLE 意外并反复重新连接到外围设备的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
