簡體   English   中英

BLE:從后台iOS應用程序廣告UUID

[英]BLE : Advertising of UUID from background iOS app

正如iOS文檔所述,當使用BLE作為外圍設備的iOS應用程序轉移到后台模式時,不會公布本地名稱,並且所有服務UUID都放在溢出區域中。 該文檔指出它們只能由iOS設備發現。

我的整體問題是如何在較低的層面上發生這種情況。 使用非iOS藍牙數據包嗅探器,當我處於前台和后台模式時,我檢查了我的iOS外圍應用程序中的廣告數據結構。 前台模式中的廣告數據結構看起來是預期的,類似於來自非iOS設備的其他廣告數據,例如我來自Android設備的那些。

當iOS應用程序是后台模式時,此結構會更改,並且服務UUID不明顯。 我沒有看到任何暗示“溢出”區域。

如果UUID不是廣告數據包的一部分,iOS中央設備如何發現處於后台模式的外圍設備?

根據Apple文檔,有一個所謂的溢出區域。 有關Core Bluetooth概念的此存檔頁面中可以找到更多信息。

我已經在空中嗅探了數據包。 您可以在github上閱讀詳細信息。 iOS所做的是使用代表UUID的特定位來廣播自定義包。 例如,UUID 3333由BLE包中的一個位表示。

04 3E 24 02 01 00 01 8C 91 A0 AD 8F 40 18 02 01 1A 14 FF 4C 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D3

你在這里看到02被零包圍的地方(在D3之前的8位RSSI值)。

每個UUID都是單熱編碼到此范圍內的一位。 這將導致碰撞。 您會注意到,如果您通過一部iPhone發送1001並通過另一部iPhone掃描3333 ,您將收到廣告,就好像發送了UUID 3333

請注意,有很多關於此的廢話。 它只是一個常規的無向BLE數據包。 這不是掃描響應。 在后台運行時,我每隔0.2秒就可靠地獲得BLE數據包。

在此輸入圖像描述

時間在x軸上(過了幾天)。 消息之間的間隔繪制在y軸上。 您會看到有時間隔是0.2秒的倍數。 但是,您還會看到這是在三個iPhone之間共享的(一個廣播1000 ,一個廣播FFFF ,一個廣播3333在后台)。 這意味着這是接收消息的筆記本電腦中的工件。 iPhone可能比這更強大。 在整個周末,電池電量下降了25% ,這很可能與BLE廣播以外的其他事情有關。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM