的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長度歧義

回答

相關問題