While background scanning is limited you can key off iBeacon devices via the location framework. This allows your app to wake up when certain devices are near.
Thinking this might be different. I've been curious what the BLE packet structure might look like. Looks like there's 16 bytes of unique id needed for the "Rolling Proximity Identifier" in the spec. Typically iBeacon would have 16 bytes of unchanging UUID, and 4 bytes that can change: https://support.kontakt.io/hc/en-gb/articles/201492492-iBeac....
Could probably flip it to be a 4 byte prefix (to identify this packet for contact tracing), followed by 16 bytes of the Rolling Proximity Identifier, but not sure if the underlying hardware (the BLE chips) can do low-power matching on a pattern like that. Something only Apple and Google could make work, so this is exciting.
(Or, it could be iBeacon to wake, then making a connection to fetch the Rolling Proximity Identifier. Though, in my experience, not requiring a connection will be more reliable in practice, especially for Android.)
Could probably flip it to be a 4 byte prefix (to identify this packet for contact tracing), followed by 16 bytes of the Rolling Proximity Identifier, but not sure if the underlying hardware (the BLE chips) can do low-power matching on a pattern like that. Something only Apple and Google could make work, so this is exciting.
(Or, it could be iBeacon to wake, then making a connection to fetch the Rolling Proximity Identifier. Though, in my experience, not requiring a connection will be more reliable in practice, especially for Android.)