我有一个正在通过蓝牙与beagle板上的服务器通信的应用程序。我已经使用bluez和平板电脑上的Android应用程序在C++中创建了服务器代码。
我看到的问题是服务器应用程序未启动时，我希望平板电脑能够继续尝试连接。尽管经过随机尝试后，平板电脑将崩溃并实际上重新启动。服务器应用程序可能未运行，但是操作系统正在运行，并且蓝牙在技术上处于打开状态。由于服务器应用程序未运行，因此它只是监听端口未监听。
这两个设备已绑定(bind)，并且在一切运行时都可以正常连接。用例是服务器未运行且平板电脑正尝试通过通信环路连接时。显然它将永远不会连接，因为服务器应用程序未运行，这很棒。我只是不明白为什么重试一会后为什么会锁定平板电脑。
平板电脑冻结之前，重试的次数从40次到300至1000次不等。正如我在logcat中看到的那样，这不是内存泄漏，在崩溃之前有10％的可用空间。我正在关闭所有套接字和流，并在每次重试连接尝试时都打开所有新内容，所以我看不到有任何问题。
在连接之前，我检查以确保在连接到绑定(bind)设备时发现未运行。
因此，我认为我在连接失败时遇到的错误仅仅是因为服务器未运行，因此没有监听端口打开。由于我正在测试错误情况，因此这是有效的和预期的。我只需要帮助，以了解为什么连接失败太多会迫使平板电脑自行重启。
D UI_BT:stateMachineCurrent:正在连接
E BluetoothEventLoop.cpp:onDiscoverServicesResult:D-Bus错误:org.bluez.Error.InProgress(发现正在进行中)
D蓝牙服务:清理失败的UUID通道查找:00:02:76:24:C2:8F 00001101-0000-1000-8000-00805f9b34fb
D UI_BT:失败的连接(95)-java.io.IOException:服务发现失败
有人知道什么地方可能出问题吗？谢谢。
编辑:
这是更多信息。我决定看看它是否与蓝牙功能有关，而在beagle板上没有运行任何应用程序，而蓝牙却全部关闭。我整夜重试，重试650万次，并且在平板电脑上没有崩溃，这很棒。
现在，我打开蓝牙并启动我的应用程序，我希望一切都可以开始通信。我觉得这是通信链接的标准用例。好吧，一旦一切开始，平板电脑就会像以前一样崩溃。
这是一些logcat输出...
09-13 09:23:28.600 7581 7590 D UI_BT:stateMachineCurrent:正在连接
09-13 09:23:28.600 5419 5670 D蓝牙服务:updateDeviceServiceChannelCache(00:02:76:24:C2:8F)
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.620 5875 5875 V BluetoothEventManager:收到了android.bleutooth.device.action.UUID
09-13 09:23:28.680 5875 5878 D dalvikvm:GC_CONCURRENT释放467K，14％释放6435K / 7431K，暂停2ms + 24ms
因此，我不确定为什么会收到这么多UUID操作意图。尽管我认为问题的根本原因可能与updateDeviceServiceChannelCache()调用有关？我不确定答案是什么，但是在长时间的重新启动后，此内部 call 会以某种方式混乱吗？我知道此方法是由于我的代码调用了connect例程而执行的。所以我不直接叫它。
希望这些补充信息可以帮助有人指出我的解决方案。
谢谢!
最佳答案
看起来问题出在使用createRfcommSocketToServiceRecord()出于某种原因，此方法不喜欢在没有连接时进行故障转移。
相反，我使用了反射和createRfcommSocket()来解决问题。