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

Android BLE意外且重复地重新连接到外围设备,android,bluetooth,bluetooth-lowenergy,Android,Bluetooth,Bluetooth Lowenergy,我正在开发一个Android应用程序,它与一个可编程设备接口,最近我偶然发现了一些奇怪的行为:当应用程序与设备断开连接时,几秒钟后,似乎有其他东西建立了连接 我正在更全面地描述这个问题,并一直关注蓝牙地图和PBAP配置文件;它们出现在问题点周围的日志中。但是,我不确定这是否是根本原因,也没有找到解决办法 该应用程序支持API 23-25。到目前为止,我只在有SIM卡的手机上遇到过这个问题,这再次指向PBAP,因为许多手机似乎只支持SIM卡的个人资料。我还不能在API 23上复制,但目前这些测试手

我正在开发一个Android应用程序,它与一个可编程设备接口,最近我偶然发现了一些奇怪的行为:当应用程序与设备断开连接时,几秒钟后,似乎有其他东西建立了连接

我正在更全面地描述这个问题,并一直关注蓝牙地图和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()
进一步调查

我在网上发布了一个相关的问题

我所看到的这些设备中的一个共同点是SIM卡的存在,但另一个是API 24或25。我还不能在API23设备上复制,也不能在没有实际安装SIM卡的设备上复制(无论版本如何)

经过进一步调查,我对SIM卡的怀疑减少了,对API版本的怀疑增加了。有几个突出的(或最近修复的)bug具有相关的行为,其中一些指向API版本>23;然而,我随后能够在API 23上复制

我觉得这与PBAP/MAP配置文件没有什么关系。更确切地说,日志中存在这些配置文件仅仅表明这些配置文件在任何可中断断开的情况下被激活。虽然没有表现出重新连接的行为,但在处理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
  • 谷歌像素-API25

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

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

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

为了进行调查,我开发了一个简单的应用程序,可以通知并报告蓝牙连接和断开(ACL_已连接,ACL_已断开)事件。我在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开始修复的。

非常感谢。感谢您的跟进,Peter。事实上,它在9月份发布时已被修复,大约在我重新发布后6个月