我玩过Airlocate和两部iPhone。还介于Linux / hcitool信标发射器和Airlocate测距之间。我看到要跟踪的一组邻近UUID是在Airlocate源代码中硬编码的。
当iOS应用程序位于任何iBeacon（任何邻近UUID）附近时，它是否有可能获得更通用的回调，并让该应用程序决定如何按照自己的方式行事。
据我所知，从操作系统的角度来看，这肯定是可能的，因为我在PDU的开头看到一个9字节的iBeacon前缀，它与邻近UUID无关。
另一个查询 - 我认为将APP中的邻近UUID硬编码为某种配对。一般的蓝牙配对与此有何不同。
我提出这些问题的目的是了解使用信标发送（广播）数据的可行性，以便附近的所有接收者都可以接收它。如果我选择使用特定的16字节邻近UUID，那么我只剩下5个字节（主要/次要/功率）来发送数据。否则我得到21个字节
答案 0 :(得分：2)
通过＆＃34;更通用的回叫＆＃34;，您似乎正在尝试收听未部署的iBeacons。答案是否定的，你不能这样做。
根据这篇文章：http://beekn.net/2013/10/ibeacons-can-my-ios-app-find-beacons-that-arent-mine/，为了收听iBeacon，你必须首先知道它的proximityUUID。 不幸的是，Apple决定限制你这样做的能力。 CoreBluetooth框架可以检测附近的iBeacon，但由于它只返回设备UUID而不是proximityUUID，因此无法向它们添加回调。
Android可以毫无问题地读取任何iBeacon的proximityUUID。