iOS 服务广告如何在后台工作？答案

【问题标题】：How does iOS Service Advertising Work in the Background?iOS 服务广告如何在后台工作？
【发布时间】：2020-08-17 04:32:17
【问题描述】：

Apple 在 iOS 上用于后台 GATT 服务广告的专有技术如何工作？

根据 Apple 的文档，当使用 CoreBluetooth 实现 BLE 外设的 iOS 应用程序在后台时，服务 UUID 不再广告，而是放在一个特殊的“溢出区域”：

CBAdvertisementDataServiceUUIDsKey 键的值中包含的任何不适合分配空间的服务 UUID 都会进入一个特殊的“溢出”区域。这些服务只能由显式扫描它们的 iOS 设备发现。当您的应用程序在后台时，不会公布本地名称，并且所有服务 UUID 都在溢出区域中。 -- developer.apple.com

但是这个“溢出区域”是什么？它是如何工作的？

I set up a bluetooth sniffer and captured the BLE data exchange，但未能找到此服务 UUID 的任何通信。前台的第二台 iOS 设备反复成功地发现后台 iOS 设备上的服务广告，但the packet capture 从未记录过服务 UUID。

那么这是如何工作的呢？

如果我能弄清楚它是如何工作的，我想尝试对 Android 设备进行编程以使用相同的进程。

【问题讨论】：

你读过github.com/crownstone/bluenet-ios-basic-localization/blob/…吗？制造商数据似乎包含服务集的小指纹/哈希，因此可以对其进行缓存。 iOS 中心没有对外围设备进行服务发现吗？你应该改用 nRF 嗅探器，它可以很容易地与 wireshark 一起使用，并且通常会捕获任何通道上的连接请求，因为当它在 37 上看到一个 adv 数据包时，它会切换到 ch 38，然后切换到 ch 39，然后再返回。
我没有看过那篇文章。迷人！它说专有制造商广告包含位图哈希，其中任何位置的 1 表示正在广告服务 UUIDS 子集的任何一个。如果为真，则表明所宣传的服务 uuid 从未真正被 iOS 知道或检查过。如果设置了所需服务 UUID 的位，则中心会收到发现回调，即使广告来自 iPhone 广告不同的服务 UUID，该服务 UUID 由于哈希冲突而碰巧也使用该位。我会做一些测试来确认。谢谢，埃米尔！

标签： ios bluetooth-lowenergy core-bluetooth bluetooth-gatt

【解决方案1】：

溢出区域是当至少一个 iOS 应用在后台宣传 CoreBluetooth 服务时从 iOS 设备发出的制造商广告。它看起来像这样：

ff 4c 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80

ff 表示制造商广告，4c 00 字节对应于蓝牙 SIG 分配的苹果制造商代码 0x004C。 01 将此标识为溢出区域广告。最后 16 个字节（128 位）是广告服务的散列位掩码。

您宣传的每个服务 UUID 都会导致这 128 位中的一个被设置为 1。服务 UUID 与其在此位掩码中设置的位位置之间存在一对一的映射。这在 iOS 设备上是一致的。将服务 UUID 转换为位掩码中的位位置是一些专有的 Apple 散列算法。

因为有大量可能的 128 位 UUID - 2^128（大约 10^38） - 多个服务 UUID 共享相同的位位置。

由于许多服务 UUID 共享溢出区域位掩码中的每个位位置，因此冲突是不可避免的。 iOS 将给一个扫描回调一个冲突但不同的服务 UUID。这不会经常发生。但程序员应该意识到，他们可能扫描他们的服务只是为了获得一个回调，以检测一个后台 iOS 设备广告一个完全不同的服务，该服务恰好在溢出区域的位掩码中发生冲突。

有趣的是，可以操纵溢出区域，让两个后台 iOS 应用在后台交换数据。 See my blog post for more info.

【讨论】：