The technical aspects discussed are slightly wrong because they are different between iOS and Android.
>The NHS has insisted its engineers have worked around this problem "sufficiently well" by waking the app after it detects itself running on a nearby phone emitting an ID: the software is blocked from sending out its ID when in the background but it can passively listen for IDs of apps still allowed to broadcast. However, this assumes there are a sufficient number of phones running the tracing app nearby still broadcasting to keep enough people's apps awake: there needs to be a critical mass of users while we're all supposed to be socially distancing. If two or more people pass each other and their apps have stopped broadcasting, the software will never know they came in contact.
Bluetooth LE has four main states: scanning, advertising, peripheral connection, and central connection. In order to exchange the data that the app needs it needs one device in the peripheral connection mode and the other in the central connection mode. This means one device must have previously been advertising and the other scanning. The two important states are advertising and scanning.
Android devices can advertise in the background but they can't scan reliably, they can do this for a short period of time enforced by the Android time limits on apps running in the background and possibly manufacturer specific power savings measures. These limits are not well documented and cause issues on any device using Bluetooth.
iOS devices can't advertise in the background, however they do advertise an Apple specific advertisement which can't be controlled by the app but can still be connected to. iOS devices also can't reliably scan in the background however they can scan more reliably for iBeacons (special adverts) [1]
Combined this makes it difficult to work well in the background, Android devices can't reliably connect to any device, iOS devices can't connect to each other but iOS devices may be able to connect to Android devices.
On Android the broadcasting bit is fine. But to effectively scan for advertisements you need to start a foreground service and actively scan for them continuously. That will keep the phone awake all the time and rinse your battery. It also don't really work very well because Android's Bluetooth stack is shockingly unreliable.
iOS is muchmuch better. You can scan for iBeacons (a restricted subset of advertisements) continuously in the background and it works extremely well. Their Bluetooth stack is a million times faster and more reliable than Android's. But I'm pretty sure there is no way to scan for, or broadcast non-iBeacon advertisements in the background.
There are waaaay too many gotchas to do this reliably without OS support.
Thanks for the link. They assume that Android devices can scan in the background but my experience is that whilst this is theoretically achievable, the experience is unreliable in practice. See this guide which shows how to make things more reliable https://openpathsupport.zendesk.com/hc/en-us/articles/360024...
And they state that for iOS in background mode:
> A nearby Android device acts as a bridge. It receives TCNs through “central” write operations and adds them to a rotating list to broadcast alongside its own TCN.
> Android devices can advertise in the background but they can't scan reliably, they can do this for a short period of time enforced by the Android time limits on apps running in the background and possibly manufacturer specific power savings measures.
Since Android 8.0 there are no time limits for background scanning if you're calling startScan() with a PendingIntent. It's not 100% reliable, particularly on devices which aren't on stock Android as you mention, but it works reasonably well.
>The NHS has insisted its engineers have worked around this problem "sufficiently well" by waking the app after it detects itself running on a nearby phone emitting an ID: the software is blocked from sending out its ID when in the background but it can passively listen for IDs of apps still allowed to broadcast. However, this assumes there are a sufficient number of phones running the tracing app nearby still broadcasting to keep enough people's apps awake: there needs to be a critical mass of users while we're all supposed to be socially distancing. If two or more people pass each other and their apps have stopped broadcasting, the software will never know they came in contact.
Bluetooth LE has four main states: scanning, advertising, peripheral connection, and central connection. In order to exchange the data that the app needs it needs one device in the peripheral connection mode and the other in the central connection mode. This means one device must have previously been advertising and the other scanning. The two important states are advertising and scanning.
Android devices can advertise in the background but they can't scan reliably, they can do this for a short period of time enforced by the Android time limits on apps running in the background and possibly manufacturer specific power savings measures. These limits are not well documented and cause issues on any device using Bluetooth.
iOS devices can't advertise in the background, however they do advertise an Apple specific advertisement which can't be controlled by the app but can still be connected to. iOS devices also can't reliably scan in the background however they can scan more reliably for iBeacons (special adverts) [1]
Combined this makes it difficult to work well in the background, Android devices can't reliably connect to any device, iOS devices can't connect to each other but iOS devices may be able to connect to Android devices.
[1] https://developer.apple.com/documentation/corelocation/deter...