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]

@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.