Cwa-app-ios: Battery draining since 1.10.1(0)

[secuninja]

I see a battery usage of 12% today in release 1.10.1(0) in iOS 14.3 which hasn’t been that high in any other release

---

• Model: iPhone 12
• Battery health at 90%
• Original Battery
• There is at least one more device typically in range most of the day.
  I’ve never seen it using so much battery, it usually was at 2-5% all the time. Even over the night it’s showing 9% now.
  Screenshot:
  

---

Internal Tracking ID: EXPOSUREAPP-1882

[Ein-Tim]

Hi @secuninja 👋🏻

I've got a few questions:

• Could you please share some screenshots of the battery section in your phone settings?
• What is the battery health (Settings->"Battery"->"Battery Health")?
• Are you using the original or a replaced battery?
• What iPhone are you using?
• Is there any device with CWA installed near your device which constantly broadcasts Bluetooth beacons?

Please also note that the battery consumption from the underlying framework, the ENF (Exposure Notification Framework), can't hardly be influenced by the Corona-Warn-App.
Still, it's worth to share the information I asked above and we will maybe find a solution.

Thanks, and stay safe!

---

Related Issues: #1664, #671, #912

[dsarkar]

Internal Tracking ID: EXPOSUREAPP-1882

[secuninja]

Hey @Ein-Tim
thanks for your reply. Here are the required information:

• Model: iPhone 12
• Battery health at 90%
• Original Battery
• There is at least one more device typically in range most of the day.
  I’ve never seen it using so much battery, it usually was at 2-5% all the time. Even over the night it’s showing 9% now.
  Screenshot:
  

Thanks and Best
SecuNinja

[Ein-Tim]

Hi @secuninja

Thanks for providing the information.
A short-term solution would be to turn Bluetooth off during the night or whenever it is not necessary that contacts are recorded. But I don't recommend this since the background task to download keys from the server, which tells the App which users you met tested positive, is also stopped when you deactivate Bluetooth (restriction by Apple).

The 9% are relative to the whole usage.
So, if you do not use your phone during the night (maybe even deactivate WiFi) than it makes sense that "Begegnungsmitteilungen" is responsible for a high percentage of the battery usage (same applies for daytime, if the phone is not used that much - the only thing that can drain the battery is "Begegnungsmitteilungen").

Maybe you could test something for me.
Charge your phone to 100% and leave it unplugged during the night. Turn WiFi off too.
At the next morning you can see how much the battery was actually drained. On an iPhone 12 with battery health 90% and another device in reach, I expect this to be between 5% and 10% (max 15%).

This is the only (fast) way to find out the real batter usage of "Begegnungsmitteilungen" since all the other numbers are relative to the usage (as explained above).

Thank you

[secuninja]

Hi @Ein-Tim

thanks for you reply. I was just wondering what has been changed in the past releases that increased the relative baterry usage. I was always at 2-5% by "Begegnungsmitteilungen" while I did not change my other device usage.
Yesterday in the evening, the remaining battery was at 25% means 12% of the 75% used has been drained by the CWA which is pretty much in my eyes ;)
Turning off WIFI at night is not possible for me unfortunately as I need that for incoming alerts.

Thanks! :)

[Ein-Tim]

Okay. If you are not able to turn WiFi off, you can leave it on too, but then there are also other Apps with active background updates (which will drain the battery too) so this is not that clear.

Could you please reboot your phone and keep monitoring for a few days?

Thanks

[secuninja]

Sure :)

[secuninja]

So I’ve been monitoring for the last two days and also restarted the phone. Now Begegnungsmitteilugen is at 15% for the last 24h now at 21:30 while battery remaining power is 50% sind the last 100% loading.
I feel like this is too much compared to where it has been 🤷🏼‍♂️

[Ein-Tim]

@secuninja
Okay thank you.
I can sadly not help you any further here. Maybe @thomasaugsten could take a look at this.

Thanks and have a nice evening.

[dsarkar]

@secuninja Thanks for reporting. We have added your information to the internal ticket for the developers. Should you observe any change in the behaviour, please let us know. Any further development on this issue will be reported here. Many thanks. Best wishes, DS

[Ein-Tim]

@secuninja
Please update to iOS 14.4 and CWA 1.11 and continue monitoring. Thanks.

[secuninja]

Done ✅
I’ll let you know the results

[stweil]

With iOS 14.3 and CWA 1.11.0(9) the power usage is still extremely high (59 % used by CWA "Begegnungsmitteilungen").

[Ein-Tim]

Hey @stweil

Please update to iOS 14.4 and keep on monitoring.

Thanks

[stweil]

That's still not offered for my device.

[Ein-Tim]

Interesting, what device are you using?

Edit: Please follow these steps: https://support.apple.com/en-us/HT204204

[secuninja]

Can you give an idea of what the average battery consumption of CWA should be like? So it would be easier to compare if the own consumption is too high or not.

[Ein-Tim]

This is really hard to tell since, as you know, this depends on the overall usage of your phone.

I use my main phone, an iPhone XR with 95% battery health (CWA 1.11 & iOS 14.4), very often, there "Begegnungsmitteilungen" is responsible for 2% of the battery consumption in the last 24h

On my secondary device, which is hardly used, an iPhone 6s with 100% battery health (CWA 1.11 & iOS 14.4), "Begegnungsmitteilungen" is responsible for 95% of the battery consumption in the last 24h.

So, I'm sorry, I can't really give you any average or so since all the numbers you're seeing in the battery settings are relative to the usage of your device.

Edit:
What I can tell you is on the iPhone 6s, which was charged to 100% at 00:48h today, the battery now is by 93%. From these 7% usage, "Begegnungsmitteilungen" is responsible for 95%. So, I would say since the last full charge, "Begegnungsmitteilungen" used ca. 6% of the battery in ca. 20 hours. This is ok.

[secuninja]

thanks. i‘m on 14.4 now since it’s available and on latest CWA. i’ll let you know

[ndegendogo]

Today (weekend) I used my iPhone a lot for surfing the internet, so today Safari is 80%; followed by Begegnungsmitteilungen (exposure checks, 7%) and cwa (4%).
On other days with less 'active' usage, the relative consumption of cwa plus exposure checks is much higher (15 - 20%).
I am not sure which 'budget' (exposure checks, or cwa?) is used for the background task / risk checking. Since the risk check is performed 5 - 6 times daily instead of only once, the battery consumption has significantly increased. The other factor is the higher number of keys in the risk check (much higher infection rates than we had in summer, and on top of this the European federation of keys).

Personally I am very happy with the frequent risk check, and would be reluctant to return to a daily check only.
A solution could be to let the user decide, and spend a configuration parameter like 'frequency of risk check' where everybody can fine-tune battery consumption vs faster warnings.

@Ein-Tim you have an amazing overview over all items on our wishlist. 😀😀 Has such a configuration parameter already been suggested?

[stweil]

Was the frequency of risk checks the relevant change which increased the energy needs of the app?

I wonder why that seems to be different on Android where I see only 1 % or 2 % battery drain for cwa.

How much data is typically transferred for each check? Does it transfer all data each time (which would be expensive), or is most of the data cached locally?

[Ein-Tim]

@ndegendogo

you have an amazing overview over all items on our wishlist. 😀😀 Has such a configuration parameter already been suggested?

You talked about this before, but besides of this I only found this Issue:

• https://github.com/corona-warn-app/cwa-wishlist/issues/81

[stweil]

Battery load is a critical factor for the success of the warn app. People consider removing it from their iPhone because it reduces the availability when too much power is used. I would remove it from my Android, too, if it would increase the power consumption that much.

[Ein-Tim]

@stweil

Was the frequency of risk checks the relevant change which increased the energy needs of the app?

Yes, we saw a higher battery usage in versions after 1.6 (1.7 introduced more frequent risk checks)

How much data is typically transferred for each check?

I'm afraid I can't answer this. 😕

Does it transfer all data each time (which would be expensive), or is most of the data cached locally?

Most of the data is cached (Source): "No new key files are downloaded they are cached based on the hash."

[ndegendogo]

How much data is typically transferred for each check? Does it transfer all data each time (which would be expensive), or is most of the data cached locally?

@stweil cwa caches the key files after first download and subsequently loads only the new files. A daily key file currently has between ~ 12000 and ~ 30000 keys.
(To be more precise: since multiple checks per day, cwa loads the hourly files of current day, and at the end of the day the daily file with the aggregated keys of the day; so this accounts to ~ 12000 .. 30000 additional keys downloaded).

However, the significant increase of power consumption is not the download of keys from the server, but the local key matching and risk calculation. This part is mainly performed in the ENF (Exposure Norification Framework) provided by Apple / part of iOS; so we know the functional description what they are doing, but not the exact details of implementation.

What they are doing basically:
1) each downloaded key is the 'master key' of all 144 RPIs of one day that the corresponding user sent around (one RPI for every timeslot of 10 minutes); so the first step is to perform this key derivation for all RPIs.
Key derivation is a cryptographic operation -> expensive in terms of CPU usage.

2) find matches. Which of these derived RPI correspond to captured / locally stored RPI. The time slot of each RPI is known, so
this step can be optimized. Still, for mitigation of not perfectly synchronized clocks between sender and receiver, they extend the 10-minute lifetime of an RPI to a time slot of 2 hours.
This second step is just a comparison. If you are able to have very few contacts, there is not much to do. But if your phone has captured a lot of RPIs all day long, even from a family member of your household, then it's different.

3) For all matches: decrypt the meta data of the RPI. These are data like calibration of the attenuation values of the sender, and they are needed to estimate the distance of a contact from the signal strength.
Decryption again is a cryptographic operation.

4) Again for all matches: group them to 'exposure windows' (30 minutes) and
estimate distance, duration, and risk scores, based on cwa risk parameters.

5) Cumulate all the exposure windows to a single risk score / risk level (red or green). This final step is implemented in cwa.

[stweil]

Thanks for the detailed information. This sounds as it should be possible to run integration tests for iOS and Android with hand crafted test apps and power meters, so more precise data like Joule per cycle could be determined. As this is essential for the success of the cwa and there seem to be major unexplained differences between iOS and Android, I'd expect such tests to be made by Apple and Telekom / SAP.

[thomasaugsten]

We have the battery draining "problem" more visible on iOS because of the misleading battery consumption feature.
When you drop in 1h from 100% to 90% and iOS stated 90% is regarding the exposure notification framework. This means not the framework used 90% of your battery. It was using 90% of the 10% = 9%.

But the features shows only app consumption in this 10% there are also hardware consumption included which are not visible and in the winter time you have also drop of battery charge because of the temperature.

[Ein-Tim]

@stweil & @secuninja please update to CWA 1.12.1 and keep us posted about the issue.

Thanks

[stweil]

CWA 1.11.0(9) "Begegnungsmitteilungen" used 12 % battery on iPhone, that's more than mail, but about the same as browser, a heavily used other app used 20 %.

I'll report numbers for CWA 1.12.1 as soon as it is updated to that version.

[secuninja]

So I’m on the latest app and IOS and at this time my remaining battery is in 36% and the consumption of CWA is 14% which is still too much in my eyes. This is way more than my twitter, mail or browser app I’m using most of the day. For comparison twitter and mail are both at 7%.

[ndegendogo]

latest app and IOS

@secuninja so that's iOS 14.4, right?
How much more details does your iOS version show? Could you give us more details?

I am still on 14.2 and I can switch between 24 hours and 10 days view. And I can switch between "activity" and "battery usage". And for 'activity' it shows separate numbers for 'foreground' and 'background'.

My numbers actually look not bad:

10-days view:
activity: cwa 1:12 h foreground + 5 min background = 1:17 h
battery: exposure notifications (Begegnungsmitteilungen) 11%
cwa 2%

24h view:
activity: cwa 1 min foreground
battery: exposure notifications 8%
cwa negligible

cwa 1.11 / iOS 14.2 / iPhone 8

[dsarkar]

@ndegendogo Thanks for info.
@secuninja Also thanks for reporting.

We keep that observing, however, it doesn´t seem that there is a fundamental or critical issue here.

[secuninja]

thank you all so far!
Yes I’m on 14.4
Today’s view right now 24h:
Begegnungsmitteilungen 11%
CWA 0% (not opened today)

10days:
BM 10%
CWA 2%

Notable might be that i’m mostly at home so there is only one other phone in range throughout the day.

If that’s all fine in numbers I’ll have to live with that 🤷🏼‍♂️

[dsarkar]

@secuninja Thanks for the feedback.

[stweil]

How is the current strategy for "Begegnungsmitteilungen"? How often is it run each day?

As far as I have understood it is a critical factor for power usage, so optimizing it can reduce the battery drain.

I noticed for example that CWA shows a nightly update of that information, at a time where I would not care because I sleep. So I could imaging either an optional user setting "no nightly updates" or use sensor information to see whether the smartphone is in use and stop nightly updates when it isn't used. Maybe users should also have an option to decide themself how often they would like to have an update.

[ndegendogo]

I noticed for example that CWA shows a nightly update of that information, at a time where I would not care because I sleep. [...] use sensor information to see whether the smartphone is in use and stop nightly updates when it isn't used.

@stweil well, you don't care about the nightly risk assessment, but other people need it before they are going to work and meeting other people (clients / collegues / ...).

So I could imaging either an optional user setting "no nightly updates" [...] users should also have an option to decide themself how often they would like to have an update.

Yes, you are right, there should be more options.

Feel free to upvote this wishlist item and/or extend it with your ideas.

[stweil]

@stweil well, you don't care about the nightly risk assessment, but other people need it before they are going to work and meeting other people (clients / collegues / ...).

Just replace "nightly" by periods of sleep or other inactivity, then it applies to most people. I don't think that it is necessary to wake someone just to say that there was a critical contact. That's why I suggested to use sensor data. The typical acceleration sensors would indicate whether the phone is in use or laying somewhere motionless.

Your wishlist item has good ideas. I upvoted it and added a comment.