繁体   English   中英

Android BLE意外地重复连接到外围设备

[英]Android BLE unexpectedly and repeatedly reconnects to peripheral

我正在开发一个与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中发布了相关问题, 有时会延迟

我看到问题的设备之间的一个共同点是SIM卡的存在,但另一个是API 24或25.我还没有能够在API 23设备上重现,或者,无论版本如何,没有物理安装SIM卡的人。

经过进一步的调查 ,我不太喜欢SIM卡,而是更多的API版本。 有几个有相关行为的突出(或最近修复)错误,其中一些指向API版本> 23; 但是,我随后能够在API 23上重现。

我觉得这与PBAP / MAP配置文件没什么关系。 相反,它们在日志中的存在仅仅指向这些配置文件在任何BLE断开时被激活。 虽然没有表现出重新连接行为,但是在弄乱TI SensorTag时我能够看到类似的PBAP / MAP激活:这些配置文件再次记录了任何断开连接(与我的应用程序无关)。

受影响设备列表

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

  • 三星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 Pixel - API 25

经过大量调查,我能够确定问题的根本原因:Spotify。

在Android设备上安装Spotify足以表现出这种异常行为; 用户无需登录或启动Spotify应用程序。 在所有情况下卸载或强制停止应用程序可以解决问题。

似乎Spotify有一项服务可以注册与任何蓝牙外设的断开连接。 当系统通知Spotify时,服务会立即连接到刚断开连接的外围设备---我没有费心去表征Spotify的通信。 大约5秒钟后连接断开; 但是,由于Spotify会收到蓝牙断开连接事件的通知,因此该服务再次尝试连接外围设备。 这实际上是一个无限循环,只能通过在Android设备上强制停止Spotify或循环蓝牙来中止。

为了调查,我开发了一个简单的应用程序,通知并报告蓝牙连接和断开连接(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提供了详细的错误报告,但我还没有收到他们的回复。

这似乎是从2017-09-14发布的Spotify 8.4.19.792开始修复的。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM