Validation of backgrounded service behaviour 'in the wild'...?
jimsmart opened this issue · comments
With reference to the discussion in issue #2, I have some questions:
In reality, on iOS, backgrounded services can often be killed if one launches other apps that require a lot of RAM, e.g. games, or even visiting big webpages.
I am curious to know how the effectiveness of the app's backgrounded services is monitored, if at all, outside of 'laboratory'/test conditions?
Are there any built-in (opt-in) diagnostic analytics to monitor whether this is actually working as expected/intended in real-life / in the wild, under regular users' normal usage patterns?
Or is this understanding of backgrounded services' behaviour based solely upon on observations made during test conditions?
"To measure is to know"
Thanks.
Related to this, I'm surprised that the app is using Bluetooth peripheral mode instead of iBeacon (presumably to get around background running issues in iOS). Peripherals aren't really designed for this kind of constant scanning, discovery, ranging behaviour - they were intended to allow devices to discover, communicate and exchange data.
While it may appear that things "kind of" work, there may be side effects such as:
- Peripheral connection limits (e.g. see https://stackoverflow.com/questions/13469502/maximum-number-of-peripherals-on-corebluetooth )
- Battery usage due to the keepalive ( see https://reincubate.com/blog/nhs-covid-19-background-tracing-details/ ) and being constantly connected to multiple devices
- Sporadic timeouts, throttling behaviour etc (in addition to OP point about memory usage etc)
- Apple deciding to fix the loopholes that keep a device alive in the background in a way which was probably not intended
Using iBeacon wouldn’t work for two reasons:
-
apps that want to act as a beacon device require access to location services (it’s part of Core Location, not Core Bluetooth) which introduces the same trust and PR issues that the Android app currently has
-
apps can only broadcast beacon signals in the foreground.
Would also be curious to know how well they've actually stress tested the limits of the Apple + Android Bluetooth frameworks by putting several hundred devices in one room. If a subsequent device enters the room is it reliably discovered by all devices?
Yeah I would agree with this, given the extensive discussions and testing taking place in #2. It would be extremely useful to have access to the test data that the developers have.
There have been small scale tests and currently larger tests in progress. It would be useful to have access to the testing methodology and any results from these tests.
I'm pasting this message in every active GitHub issue, so you may receive duplicate notifications.
Today, I'm happy to announce that NHSX has released the full git commit history for the Isle of Wight Beta apps.
- Android - https://github.com/nhsx/COVID-19-app-Android-BETA
- iOS - https://github.com/nhsx/COVID-19-app-iOS-BETA
As discussed, we have redacted API keys, sensitive domain names, and some of the developers' personal details. I am still waiting on final approval to publish the server-side code.
I would like to personally thank the community for your comments, bug reports, and vulnerability disclosures. They all went into helping the development process.
The beta trial of this app has now ended and we've moved to the next phase of app development. It is our intention to publish the source code of future apps as the binaries are released to the public.
Once again, thank you for being part of this.
Terence Eden
Head of Open Technology - NHSX