的Android BLE BluetoothAdapter.LeScanCallback scanRecord长度歧义

我使用从谷歌（BluetoothLeGatt）的示例项目以从BLE设备接收数据，并试图内它是由onLeScan方法获得scanRecord读取一个特定字节。的Android BLE BluetoothAdapter.LeScanCallback scanRecord长度歧义

我的问题是，我在网络中观察到的数据与我在日志中看到的数据之间存在不匹配。

这是在Android 4.3上，并使用三星Galaxy S4来测试它。要验证scanRecord日志是正确的，在Android上，我使用了TI的数据包嗅探器来观察字节流由设备正在播出，在这里它是： enter image description here

这是31个字节的数据通过正在播出设备连接到网络，并且周围没有其他工作设备。

02 01 1A 1A FF 4C 00 02 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0C C6 64

在另一方面，机器人日志声称所接收的数据长度为62个字节，并且它与数据匹配直到第29个[0-indexed]字节，其余数据为0。

02-12 15：34：09.548：d/DEBUG（26801）：LEN：62 数据：02011a1aff4c000215000000000000000000000000000000000000000cc60000000000000000000000000000000000000000000000000000000000000000

而这是代码块予以获得内日志中使用所述LeScanCallback方法：

int len = scanRecord.length; 
String scanHex = bytesToHex(scanRecord); 
Log.d("DEBUG", "len: " + len + " data:" + scanHex);

用于字节数组转换为十六进制表示的方法：

private static String bytesToHex(byte[] bytes) { 
     char[] hexChars = new char[bytes.length * 2]; 
     int v; 
     for (int j = 0; j < bytes.length; j++) { 
      v = bytes[j] & 0xFF; 
      hexChars[j * 2] = hexArray[v >>> 4]; 
      hexChars[j * 2 + 1] = hexArray[v & 0x0F]; 
     } 
     return new String(hexChars); 
    }

我用一些其他的例子项目，其中包括戴维·史密斯的example和RadiusNetworks' Android iBeacon Library和我结束了相同的结果。当“Packet Sniffer”显示（我也知道）它应该是31个字节时，我无法理解为什么我会收到62个字节的数据。如果我能够正确读取最后一个字节中的数据（我从Android的BluetoothAdapter获取而不是），这不是我主要关心的问题。但事实并非如此。

我很感激任何有关可能导致数据（仅最后一个字节）和Android接收到的数据与网络上实际数据之间的数据大小不匹配的原因的建议。

来源

2014-02-12 mass

当其内部长度字段指示它应该总共只包含30个字节（PDU长度36）时，您的传输格式错误，包含31个字节的有效负载数据（PDU长度为37）。

让我们来看看你的数据

02 01 1a

这是类型代码的长度（2） - 01和1a，和好为止

1a ff 4c ...

现在我们有一个问题 - 1a是该字段的长度代码（制造商特定数据），值为26.然而，在您的情况下，27字节的数据会跟在它的后面，而不是您提供的适当的26。

现在，如果你有一个正确形成的数据包，你仍然会得到一个更大的缓冲区，填充适当内容后的无意义（可能是未初始化的）值，但是你可以简单地忽略这个缓冲区，长度值并且忽略任何不在所宣称的长度中计算的东西。

但是对于当前格式错误的数据包，将数据包数据复制到缓冲区会停止在已声明的内容大小，并且未通知的额外字节永远不会将其存入您的程序收到的缓冲区 - 所以您会看到随机的东西，剩下的未使用的长度。

也许，当你让你的所有零“区域UUID”（可能要重新考虑），您只需输入一个额外的字节...

来源

2014-02-12 16:12:24

有没有额外的字节，其实还有一个额外的字节但它是由制造商在流的末尾故意放置的。这里的长度确实是问题，当我们将1A改为1B时，正好有27个字节被缓冲区占用，并解决了问题。非常感谢您指出这一点。在您的推荐之后，在@ davidgyoung的答案帮助下：http：//stackoverflow.com/a/19040616/1505341，我已经阅读了Core Bluetooth规范中的相关章节，它阐明了很多事情。我会编辑我的问题以反映我对其他可能需要的人的观察。 – mass

我想，只要它是你自己的外设和中央代码，一个正确格式化的（自我一致的）更长的数据包就可以工作，并且有可能它有时可以与其他实现互操作，但我会谨慎对待除非你打算只使用可定制的组件构建一个封闭的系统，而不是（例如）这种类型的数据包解码可能由操作系统执行，而不是由你提供或可以改变的代码执行。 –

我认为我的主要担心是有一天会失去与iBeacon的兼容性，我的意思是，如果他们决定为他们的iBeacon数据包添加长度控制，那么任何不与iBeacons具有相同数据长度的设备都将与iOS设备不兼容。至少现在看起来，只有16位保留的UUID才能让这个数据流与Apple标准兼容：https：//www.bluetooth.org/en-us/specification/assigned-numbers/company-identifiers。但谁知道他们是否会决定为他们的数据包添加额外的控制权。 – mass

的Android BLE BluetoothAdapter.LeScanCallback scanRecord长度歧义

回答

相关问题