Scanning for iBeacons

[azlekov]

Hello,

I want to scan for a device advertising as iBeacon
I have installed nRF Connect on both Android and iOS device.

• When I scan using nRF Connect on android I got the device name and the full manufacture data, basically all information
• When I scan using nRF Connect on iOS I got only the device name nothing else

Now the Kable part:

The only way I can distinguish and scan for this iBeacon device is without any filters and filtering all advertisements by name.
This is working only on iOS and macOS but not on Android. On Android I'm not even sure that I'm getting these advertisements using Kable or I cannot find a way to distinguish the device.

Any hints what I'm doing wrong or suggestions? Is Kable able and how to handle iBeacons on Android and iOS do anyone know?

[twyatt]

The only way I can distinguish and scan for this iBeacon device is without any filters and filtering all advertisements by name.

Perhaps #396 might provide a filtering mechanism (filtering by name) for you?

On Android I'm not even sure that I'm getting these advertisements using Kable or I cannot find a way to distinguish the device.

With #401, are you able to scan (without any filters) and then query the Advertisement.name to find the device of interest?
In other words, if we merge/release #401, does that unblock you?

[azlekov]

Perhaps #396 might provide a filtering mechanism (filtering by name) for you?

If filters by the scanRecord.name should work.

[azlekov]

Hey @twyatt seems that Kable is not handling property iBeacons. All necessary information about iBeacon name UUID and stuff is hidden in the scanRecord.getBytes() raw bytes. Some AD structures must be parsed.

I'm wondering what is your development flow, so I can play around with the Kable library and eventually add iBeacon and other kind of beacons support?

[twyatt]

To test out changes:

1. Checkout library: git clone https://github.com/JuulLabs/kable.git
2. Make changes
3. Install to local maven: ./gradlew -PRELEASE_SIGNING_ENABLED=false -PVERSION_NAME=999.0.0-local publishToMavenLocal
4. Use Kable in a local project
   • Make sure that you have mavenLocal() as a repositories
   • Use the version you used above to publish locally as your version of Kable to use

Due to occasional Gradle caching issues, I found it best to increment the version for each change, e.g. 999.0.1-local then 999.0.2-local, etc. This may not be necessary, but may avoid some strange caching bugs. 🤷

[azlekov]

Just FYI, a nice recent article on the topic https://www.ckhang.com/blog/2022/ibeacon-detection-with-android/
I spend some time checking:

• https://github.com/TakahikoKawasaki/nv-bluetooth
• https://github.com/vhiribarren/beacon-simulator-android
• https://github.com/AltBeacon/android-beacon-library

All of them are parsing the raw scanRecord.getBytes() into called AD structures. There are structures for the name for the proximity UUID etc.

My plan is to extend the Android implementation and take in mind the different beacons structure. A question to you - do you know if this is also required on iOS? It looks like the Bluetooth Core is returning the iBeacons out of the box, but cannot confirm if any other beacons will be reported properly.

Do you think if will be nice to put some 'common' fields when advertisement is a beacon on all platforms like simply if advertisement is a beacon plus some beacon-specific data?

[twyatt]

do you know if this is also required on iOS?

I have not worked with iBeacon before, so unfortunately I don't know what the support looks like on each platform.

It looks like the Bluetooth Core is returning the iBeacons out of the box

Being that "iBeacon is a protocol developed by Apple"¹ it would make sense that they provide support directly in Core Bluetooth. I think it is safe to assume it should just work on Apple platforms and to focus on adding support in the other platforms.

Do you think if will be nice to put some 'common' fields when advertisement is a beacon on all platforms like simply if advertisement is a beacon plus some beacon-specific data?

Being that it sounds like the support involves parsing the raw bytes, I think it makes the most sense to provide extension function(s) (on either Advertisement or ByteArray) that parses and returns a Beacon (or similarly named) class. The extension function could still be used on Apple if for some reason their support differs from what you'd add, users would have the option of using the extension function or not; but at least it would provide a consistent implementation across all the platforms. The extension function approach also makes for simpler implementation that works across the platforms, rather than having to do a bunch of expect / actual functions.

Ultimately, just suggesting possible design, feel free to diverge if needed.

[azlekov]

Hello,

Mystery resolved and I'm writing some guidelines and takeaways for iBeacon and Android.

First, be very careful about Bluetooth permissions when you are scanning and expecting iBeacons as results. Check here.

In my case I tried to be very granular about permissions and I had to remove the assert never for location iBeacons looks like that they can "report physical user location", so ACCESS_FINE_LOCATION permissions was required and android:usesPermissionFlags="neverForLocation" should be removed.

About iBeacon specific data. As @twyatt proposed on Android you can have extension functions for the Advertisement class and parse its raw bytes using bytes property. For parsing you can use different libraries like:

• https://github.com/AltBeacon/android-beacon-library
• https://github.com/TakahikoKawasaki/nv-bluetooth

or manually.

Case closed 🕵️