Android Beacon库-正确使用BluetoothMedic吗？

基于以下观察,我对蓝牙医疗的使用有一些疑问.

因为蓝牙在我的其中一台设备上停止,所以我一直在查看BluetoothMedic以查看它是否可以提供帮助.我看过调试消息和源代码.根据我使用enablePeriodicTests()还是单独运行runScanTest()和runTransmitterTest(),得到的结果会有所不同.

使用enablePeriodicTests(),BluetoothTestJob.onStartJob()每15分钟运行一次扫描和发射器测试,显然可以.如果我的信标正在传输,则从扫描测试中获得“扫描测试成功”然后“扫描测试完成”,如果没有,则获得“超时运行扫描测试”,然后“扫描测试完成”.在运行发射机测试之后,在所有情况下我都获得“发射机测试成功”然后“发射机测试完成”的信息.

但是,当我添加执行runScanTest()和runTransmitterTest()调用的按钮时,会得到不同的行为.在这两种情况下,代码都进入while()循环以等待非空测试结果,并在5秒后超时.由于测试结果为空,因此调用将返回true(对于扫描测试)和false(对于发射器测试).

在扫描测试的情况下,如果我的信标未传输,则从不会调用onScanResult()回调,但是如果信标正在传输,则将调用10-20次(我看到许多“扫描测试成功”消息),但仅在AFTER之后runScanTest()返回.

在进行发送器测试的情况下,将触发一次onStartSuccess()回调,并且会看到“发送器测试成功”消息,但只有在runTransmitterTest()之后才返回.

两个设备(Android 7和8)的行为相同.

最好有关于这些测试以及如何使用它们的进一步文档.

首先,这些测试做了什么,它们会发现什么错误？

其次-应该如何使用它们？看起来runScanTest()和runTransmitterTest()不能简单地调用-它们需要自己的线程还是其他东西？

最后,它们在测距和监视代码运行时是否安全使用,或者它们会干扰？

解决方法:

Android Beacon Library的BluetoothMedic旨在检测Android蓝牙堆栈进入不良状态的症状,然后有选择地对蓝牙重新上电以退出该状态. Medic查找两个OS级错误代码,这些错误代码是从尝试扫描Bluetooth LE设备或传输Bluetooth LE广告返回的.已知这些错误代码与蓝牙堆栈的状态不佳相关,如果没有干预,通常不会从中恢复.

设置它的最简单方法是被动地像这样：

BluetoothMedic medic = BluetoothMedic.getInstance();
medic.enablePowerCycleOnFailures(context);

上面的两行代码将开始让医务人员监听封闭的应用程序正常使用库功能(扫描和/或传输)而导致的任何蓝牙错误.如果检测到这些故障,它将重启电源以尝试恢复.

通常这样做是安全的,但是重启电源会给其他功能(例如经典蓝牙)带来问题-如果在这种情况下手机使用蓝牙扬声器,则显然会断开连接.蓝牙LE功能不太可能受到关机后再开机的影响,因为蓝牙堆栈中的错误情况可能会阻止功能正常工作.

如您所见,您还可以将BluetoothMedic设置为定期运行自己的测试.如果您的应用仅定期与信标一起使用,并且您想在应用需要使用任何错误条件之前主动从中恢复,这可能是一个好主意.要进行设置,请致电：

medic.enablePeriodicTests(context, BluetoothMedic.SCAN_TEST | BluetoothMedic.TRANSMIT_TEST);

您也可以直接调用测试,但这是高级用法,不是主要设计.如果您决定这样做,则绝对应该在新线程上执行此操作,否则它们将阻塞UI线程,直到测试完成.这将导致您描述的问题.

如果在扫描测试过程中附近没有BLE设备,则测试“超时”,结果不确定-您不确定蓝牙堆栈是否处于良好状态.调试行表明了这一事实.

标签：android,ibeacon,altbeacon,ibeacon-android,android-ibeacon
来源： https://codeday.me/bug/20191010/1884814.html