我正在开发一个与自定义蓝牙设备通信的 Android 应用程序。调用后,BluetoothGatt.Disconnect()
我看到调用了OnConnectionStateChange
回调,并且新状态为Disconnected
,但是,在发生这种情况与设备本身实际断开连接之间似乎存在延迟。例如,如果我使用已连接的设备调用 BluetoothManager.GetConnectionState(...),它仍会返回 Connected。有时需要几秒钟才能GetConnectionState
返回Disconnected
. 这是正常的吗?我是否有可能在我的应用程序中做错了可能导致这种情况的事情?例如与非 UI 踏板断开连接,或类似的东西?或者,物理蓝牙设备本身是否有可能没有正确处理断开连接并且可能没有及时完成断开连接事件?
2 回答
Android的BLE系统太乱了。我已经看到了您所描述的内容,但更糟糕的是 - 您与 Android 断开连接,但在引擎盖下它与您的外围设备保持持久连接。
通常需要 30 秒才能最终断开连接,有时需要几分钟!一切都取决于您当时使用的手机。
如果您有能力,我强烈建议您向外围设备添加断开连接特性,以便您通过编写断开连接请求并让外围设备强制断开连接来实际断开连接 - 然后 Android 将接手它。
我看到的好处是它总是有效的(因为 Android 总是会选择“硬”断开连接,而“软”断开连接请求可能会在某些手机上导致一些问题)。通常,“好”手机不会表现出这种行为(尤其是 Marshmallow 等),但回到 KitKat 时代......哇......
另一个好处...如果您使用的是 iOS,您可以更快地扫描或重新连接到断开连接的外围设备。
当您调用“disconnect()”时,您只会断开您的客户端对象(BluetoothGatt 对象)。您可以将多个 BluetoothGatt 对象连接到同一物理设备。多个应用程序也可以将自己的 BluetoothGatt 对象连接到同一设备。
一旦您调用“disconnect()”,请求就会在系统的蓝牙堆栈中进行处理,然后它会在完成处理请求后立即在您的应用中调用 onConnectionStateChange 回调。但是,在所有其他客户端断开连接之前,它不会断开链接。较新版本的 Android 也会将物理断开延迟几秒钟(不知道为什么)。此外,一旦断开连接请求已发送到蓝牙控制器,实际断开连接可能需要一些时间,因为远程设备需要确认断开连接(或超时)。默认超时为 20 秒,直到最近在最新的 Android 版本中更改为 5 秒。