Nearby Connections 2.0 中的错误代码答案

【问题标题】：Error codes in Nearby Connections 2.0Nearby Connections 2.0 中的错误代码
【发布时间】：2017-09-04 11:37:34
【问题描述】：

我一直在试验新的Android Nearby Connections v2.0 API。我的大多数设备现在大部分时间都可以相互通信，但我在尝试连接时也会收到很多error codes。在我的程序中检查status.getStatusCode()，我可以看到以下返回码：

STATUS_ALREADY_CONNECTED_TO_ENDPOINT (8003)
STATUS_BLUETOOTH_ERROR (8007)
STATUS_ENDPOINT_IO_ERROR (8012)
STATUS_ERROR (13)

我很难理解这些。第一个错误代码似乎不言自明，除了我在所谓的连接的任一侧没有使用“SUCCESS”返回代码点击 onConnectionResult 回调的情况下看到它。我当前的代码充满了跟踪语句，如果已经达到这些回调，我会看到日志条目。所以也许设备在某个较低级别连接，但如果是这样，较高级别的代码并不总是听到它。

我猜 STATUS_BLUETOOTH_ERROR 表示记录它的一侧的蓝牙错误，而 STATUS_ENDPOINT_IO_ERROR 表示另一端的错误（可能涉及蓝牙）？是否有可能获得更多详细信息？我偶尔看到的 STATUS_ERROR (13) 状态听起来像是程序员在那些“WTF，我们永远不应该到达这里”的时刻使用的那种错误代码，但如果无法访问源代码，我只能猜测。

请注意，我在使用相同代码的设备之间看到了这些错误，这些设备在其他时间可以很好地相互通信。有时，如果代码重试了足够多的时间，它最终会获得稳定的连接。有时它会连接并立即与另一端断开连接。有时我会收到无穷无尽的重复错误消息（STATUS_BLUETOOTH_ERROR 和/或 STATUS_ENDPOINT_IO_ERROR）。

我正在使用具有连接策略P2P_CLUSTER 的附近连接。当双方都做广告和发现时，这些问题似乎最常发生。但是，我编写了两个专门用于广告或发现的较小程序，它们有时也会出现这些错误（但不太常见）。

在跟踪消息中，我还注意到来自附近连接的许多警告消息，如下所示：

09-04 22:54:40.070 3866-3924/? W/NearbyConnections: Cannot deserialize BluetoothDeviceName: expecting min 16 raw bytes, got 6

我猜这是因为 Nearby Connections 使用自己的短令牌（如ZGbx）而不是设备蓝牙名称？不过，我对此完全不确定。无论如何，如果这些是 Nearby Connections 自己的特殊令牌，那么它为什么会发出有关它的警告消息？

【问题讨论】：

标签： android bluetooth google-nearby

【解决方案1】：

[免责声明：我在附近的连接上工作]我可以尝试提供帮助。

STATUS_ALREADY_CONNECTED_TO_ENDPOINT：如果您在与给定端点有任何挂起 (onConnectionInitiated) 或已建立 (onConnectionResult) 连接时调用“requestConnection”，则会发生这种情况。将之前的日志语句移至 onConnectionInitiated，您应该会明白为什么我们会抛出此错误。

STATUS_BLUETOOTH_ERROR：蓝牙出现问题。手机可能状态不佳。这（希望）不应该经常发生。但是，如果您真的想要修复，请在重新尝试 requestConnection 之前停止广告和发现。 Nearby Connections 将在检测到此错误时切换蓝牙，但前提是没有其他操作。

STATUS_ENDPOINT_IO_ERROR：我们失去了与其他设备的连接。发生这种情况的原因有很多（他们可能走得太远、蓝牙不稳定、设备停止响应等）。如果您在有联系时发现，请避免这种情况。手机上的发现可能很困难，而且最多会减少带宽，最坏的情况会导致连接中断。

STATUS_ERROR：出现了与其他错误代码不符的错误。这是一个包罗万象的。这通常在 onConnectionResult(FAILED) 中返回，以通知您在 onConnectionInitiated 和等待双方接受连接之间出现问题。

我们还在即将发布的版本中降低了“无法反序列化 BluetoothDeviceName”的日志严重性，因为这并不是真正的警告。就像你说的；当我们在发现时看到非附近连接设备时的预期行为。

如果您仍然发现问题，请告诉我们您正在使用哪些设备，我们会确保将它们添加到我们的测试套件中。

【讨论】：

非常感谢！我目前在我的代码中都有日志语句，所以我将根据这些新信息重新检查我的日志，看看是否出现了模式。从内存中，一个非常常见的模式是 STATUS_BLUETOOTH_ERROR 立即（在下一次重试时）和 STATUS_ALREADY_CONNECTED_TO_ENDPOINT （没有成功点击 onConnectionResult）。在重试之间添加延迟没有帮助。您是否建议我停止对每个 STATUS_BLUETOOTH_ERROR 的发现和/或广告？如果是这样，我应该在重新启动之前延迟吗？
嗯。这可能是同时发生的连接冲突；如果您有 2 个设备同时相互连接，我们将（随机）在第二个设备在两个设备上触发 onConnectionInititated() 之前使设备的第一个 requestConnection() 失败。但是，我们使用 IO_ERROR，而不是 BLUETOOTH_ERROR……是的，对 BLUETOOTH_ERROR 的有效修复是停止发现/广告，然后重试 requestConnection()。
我是否需要停止/启动广告和发现才能修复它？我将代码更改为在蓝牙错误后停止/开始发现，但它不起作用。我想我也可能会看到同时发生的连接冲突，这在两个测试设备上尝试新代码时尤其可能发生。我尽量小心：发现后，当我发出连接请求时，我会忽略任何新发现，只响应我们请求的 onConnectionInitiated。（我应该对其他人做出回应吗？）我正在尝试创建一个简单的可重复测试用例（您知道这很难）。
停止两者。发生的越少，我们就越能尝试修复它。也就是说，请给我们您手机的型号。我们宁愿着眼于解决根本原因，也不愿让您像这样跳槽。
除此之外，对于同时连接，我们故意使一个连接失败，因此您看到的那些异常是预期的。但另一个连接应该成功......如果不是，我需要调查一下。最好的办法是继续尝试这种重试策略（+ 可能是随机退避）。

【解决方案2】：

我只想补充一点，调用 API 时可能需要有一个简短的客户端名称字符串。

例如，Nearby.Connections.requestConnection(googleApiClient, shortNameHere,....)

我一直在使用 UUID.randomUUID().toString() 生成自己的客户端名称，这似乎导致了 STATUS_BLUETOOTH_ERROR。我所做的只是将代码示例更改为使用 UUID 名称并使用 P2P_CLUSTER，但我得到了那个错误。

这是我关于STATUS_BLUETOOTH_ERROR的解决方案。

【讨论】：

这很有趣！不过，我有很多问题。您是使用 4 个字符的字符串作为短名称，还是使用其他长度？你如何生成它？它与您开始做广告或发现时所用的名称相同吗？它真的摆脱了你所有的 STATUS_BLUETOOTH_ERROR 吗？我仍然断断续续地看到这种情况，有时它会进入一种永远不会出现的状态（即使在停止/开始广告和发现之后）。我愿意尝试您的想法，但需要先更好地理解它。
我现在使用 5 个字符的数字字符串，就像示例中的数字一样（仅使用 java.util.Random 类）。是的，我曾经/正在使用 SharedPreferences 来存储生成的 ID。所以我已经玩了大约一个小时，我确实间歇性地得到了另一个STATUS_BLUETOOTH_ERROR。以前我每次都会收到这个错误。这是我正在谈论的示例github.com/googlesamples/android-nearby
现在我遇到了一个问题，我尝试按照此处developers.google.com/nearby/connections/android/exchange-data 的描述发送字节和文件，但是当我尝试发送时，连接立即丢失。我还在调查。
嗯，间歇性错误总比每次错误都要好，所以我想这就是进步。我目前正在使用 17-31 个字符的名称（16 个伪随机字符存储在共享首选项中，与用户定义的 1-15 个字符的屏幕名称连接）。
很高兴知道。我刚刚意识到我之前评论中的问题是因为当我开始打算选择图像（将文件发送到其他设备）时，主要活动暂停了。显然，当活动进入后台时，一切都会断开连接。我确定原因是电池耗尽。我真的希望带有前台通知的 IntentService 也可以利用 Nearby API。不过不确定这是否可能。