gpt4 book ai didi

android - 蓝牙重新连接导致平板电脑 Honeycomb 3.2 崩溃

转载 作者:行者123 更新时间:2023-12-02 05:09:21 25 4
gpt4 key购买 nike

我有一个应用程序通过蓝牙与 beagle 板上的服务器通信。我在平板电脑上使用 bluez 和 Android 应用程序用 C++ 创建了服务器代码。

我看到的问题是当服务器应用程序未启动时,我希望平板电脑继续尝试连接。尽管经过随机次数的尝试后,平板电脑会崩溃并在我身上重新启动。服务器应用程序可能没有运行,但操作系统正在运行并且蓝牙在技术上处于开启状态。它只是监听端口没有监听,因为服务器应用程序没有运行。

这 2 台设备已绑定(bind),并且在一切运行时都可以正常连接。用例是当服务器未运行并且平板电脑试图通过通信环路连接时。它显然永远不会连接,因为服务器应用程序没有运行,这很好。我只是不明白为什么它会在重试一段时间后锁定平板电脑。

在平板电脑卡住之前,重试次数从 40 次到 300 到 1000 次不等。这不是内存泄漏,正如我在 logcat 中看到的那样,它在崩溃之前有 10% 的空闲空间。我正在关闭所有套接字和流,并在每次重试连接尝试时打开所有新内容,所以我看不出有任何问题。

就在我连接之前,我检查以确保发现在我连接到绑定(bind)设备时没有运行。

所以我认为连接失败的错误只是因为服务器没有运行,因此没有打开监听端口。这是有效的并且是预期的,因为我正在测试一个错误案例。我只是需要帮助,了解为什么连接失败次数过多会迫使平板电脑自行重启。

D UI_BT: stateMachineCurrent: Connecting

E BluetoothEventLoop.cpp: onDiscoverServicesResult: D-Bus error: org.bluez.Error.InProgress (Discover in progress)

D BluetoothService: Cleaning up failed UUID channel lookup: 00:02:76:24:C2:8F 00001101-0000-1000-8000-00805f9b34fb

D UI_BT: FAILED Connection (95) - java.io.IOException: Service discovery failed

有人知道哪里出了问题吗?谢谢。

编辑:

这里有更多信息。我决定看看它是否与打开蓝牙但没有在 beagle 板上运行应用程序或蓝牙一起关闭有关。我整夜重试,重试 650 万次,平板电脑没有崩溃,这很棒。

现在我打开蓝牙并启动我的应用程序,我希望一切都开始通信。我觉得这是通信链路的标准用例。好吧,一旦一切都开始说话,平板电脑就会像以前一样崩溃。

这是一些 logcat 输出...

09-13 09:23:28.600 7581 7590 D UI_BT : stateMachineCurrent: Connecting

09-13 09:23:28.600 5419 5670 D BluetoothService: updateDeviceServiceChannelCache(00:02:76:24:C2:8F)

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.620 5875 5875 V BluetoothEventManager: Received android.bleutooth.device.action.UUID

09-13 09:23:28.680 5875 5878 D dalvikvm: GC_CONCURRENT freed 467K, 14% free 6435K/7431K, paused 2ms+24ms

所以我不确定为什么我会收到这么多 UUID 操作 Intent 。虽然我认为我的问题的根本原因可能与 updateDeviceServiceChannelCache() 调用有关?我不确定答案是什么,但是这个内部调用在长时间重启后不知何故搞砸了?我知道此方法是由于我的代码调用连接例程而执行的。所以我不直接调用它。

希望这些添加的信息能帮助有人指出我的解决方案。

谢谢!

最佳答案

看起来问题是出于某种原因使用 createRfcommSocketToServiceRecord() 时,此方法不喜欢在没有连接时一遍又一遍地失败。

相反,我使用反射和 createRfcommSocket() 来解决我的问题。

关于android - 蓝牙重新连接导致平板电脑 Honeycomb 3.2 崩溃,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7393433/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com