基于以下观察，我对蓝牙医疗的使用有一些疑问。
由于Bluetooth停止在我的其中一台设备上，因此我一直在查看BluetoothMedic以查看它是否可以提供帮助。我看过调试消息和源代码。根据我使用enablePeriodicTests（）还是单独运行runScanTest（）和runTransmitterTest（），得到的结果会有所不同。
使用enablePeriodicTests（），BluetoothTestJob.onStartJob（）每15分钟运行一次扫描和发射器测试，显然可以。如果我的信标正在传输，则从扫描测试中获得“扫描测试成功”然后“扫描测试完成”，如果没有，则获得“超时运行扫描测试”，然后“扫描测试完成”。在运行发射机测试之后，在所有情况下我都获得“发射机测试成功”然后“发射机测试完成”的信息。
但是，当我添加执行runScanTest（）和runTransmitterTest（）调用的按钮时，会出现不同的行为。在这两种情况下，代码都进入while（）循环以等待非空测试结果，并在5秒后超时。由于测试结果为空，因此调用将返回true（对于扫描测试）和false（对于发射器测试）。
在扫描测试的情况下，如果我的信标未发送，则从不会调用onScanResult（）回调，但是如果信标正在发送，则调用10-20次（我看到许多“扫描测试成功”消息）但是只有在runScanTest（）之后才返回。
在进行发送器测试的情况下，将触发一次onStartSuccess（）回调，并且会看到“发送器测试成功”消息，但仅在runTransmitterTest（）之后返回。
两个设备（Android 7和8）的行为相同。
最好拥有有关这些测试以及如何使用它们的进一步文档。
首先，这些测试是做什么的，它们会发现什么错误？
第二-如何使用它们？看起来runScanTest（）和runTransmitterTest（）不能简单地调用-它们需要自己的线程还是其他东西？
最后，它们在测距和监视代码运行时是否安全使用？或者它们会干扰吗？
答案 0 :(得分：1)
Android信标库的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设备，则测试“超时”，结果不确定-您不确定蓝牙堆栈是否处于良好状态。调试行表明了这一事实。