bug: iOS advertisment manufactuer data is not available when scanning while app is in background

[drolpi]

When I run a scan task while my app is in background the manufacturer data is not included in the advertisement data.

I am using capacitor v7 and iOS 18.3.

[peitschie]

Hi @drolpi

This sounds like a passive vs active scan difference: https://uynguyen.github.io/2020/08/23/Best-practice-Advanced-BLE-scanning-process-on-iOS/

If the advertisement data is important, you'll want to shift it from the scan response packet into the primary advertise packet 🙂

Unfortunately, there's nothing we can do from the plugin side.

[drolpi]

@peitschie what do you mean with "shift it from the scan response packet into the primary advertise packet"?

[drolpi]

On the peripheral side?

[peitschie]

@drolpi correct. This is a peripheral side change. This is the difference between the advertising packet (ADV_IND) and the scan response packet (SCAN_RSP): https://stackoverflow.com/questions/75292547/are-ble-devices-required-to-respond-to-a-scan-req-requests

The fact this only shows up when the application is in the foreground means the peripheral only provides the data in the scan response. If it's critical to receive this data in the background, the only solution is for the peripheral to instead send the data in the advertising packet itself.

[peitschie]

You can see the distinction more clearly using something like nrf Connect (Android, but they may have an iPhone equivalent)

[drolpi]

With nrf connect on iOS the manufacturer data is always available

[drolpi]

My peripheral is a VanMoof S5 bike, which also has an original app that checks the manufacturer data in the background

[peitschie]

Are you able to post some screenshots of the packet structure as presented by nrf Connect? I'm specifically looking for the advertisement history (Scanner > select your peripheral > "More") so we can see what payloads are in each packet.

Another common behaviour is that peripherals can rotate their advertising payloads. If this is the case, you'll need to build the handling for this as part of your own application. There is no general standard for how this occurs, so I can't implement any feature in the plugin.

[drolpi]

This?

[peitschie]

Can we see more information about the packets there? In nrf Connect on Android, the MORE button here leads to a lot more insight into what's in the advertising packet.

[drolpi]

[drolpi]

The manufacturer data was not available in the first packet, but only later, but I also went closer to it

[drolpi]

If this isnt what you mean, show me how it look on android

[peitschie]

The manufacturer data was not available in the first packet, but only later, but I also went closer to it

This does keep pointing to this just being something your application needs to learn how to deal with, unfortunately 🙂 .
The plugin behaviour definitely does not change based on proximity to the device...

[drolpi]

Ok what would you suggest how I should implement this now? How can I listen to an advertisement change or how can I access updated versions of the advertisement?

[peitschie]

I'd recommend starting your scan using startScanWithOptions, and specifically setting reportDuplicates: true

As per the docs:

reportDuplicates: true if duplicate devices should be reported, false (default) if devices should only be reported once.

This will trigger your callback every time the phone receives an advertising packet, and will always report the current advertising payloads.