Background update does not work, despite v.1.1.1 and “prioritized background activity”

Version 1.1.1 is installed since last week and “prioritized background activity” is set to on. Today I clicked on my risk status and saw that the last update was two days ago ("vorgestern").
Is this how it is supposed to be?
Some seconds later, the update was performed.
Device is a Huawei P30 lite running with Android 10.0.0

Internal Tracking ID: EXPOSUREAPP-1922

I could confirm the issue.
Honor 10
Andorid 10
CWA 1.1.1
ENF<PHONE_NUMBER>3
no check 2020/07/24.
prioritized background activity enabled from within the app

Same issue on bq Aquaris X, Android 8.1.0. Automatic updates worked in Version 1.0.5.

Same issue on a Samsung Galaxy S10e on Android 10.
I am using the latest app version, and excluded it from the phone's energy optimization.
The last time I've used the app was over 24 hours ago (Juli 26, 2020 14:49)
I've checked the entries under Settings --> Google --> COVID-19 Notifications. They don't get updated until I open the app again.

Same issue on Xiaomi Mi9 Android 10
Also  "I've checked the entries under Settings --> Google --> COVID-19 Notifications. They don't get updated until I open the app again."

I also have the issue on a Xiaomi Mi 9 Lite. This is also reported in #756, but I think we can't expect the developers to take care of this.
For me open source is not defined as "putting the code somewhere and don't care afterwards", open source means for me also taking the advantages and especially using for example this issue tracker. But I don't have the impression, that the developers are using this. If they would, they should communicate more often!
 But the app is not able to reliable do this.

Is there any way in the production version of CWA (currently Version 1.1.1) to see when the next risk evaluation is scheduled? I only know how to look via Settings > Google > COVID-19 exposure notifications > Exposure checks to see what requests have been previously made.

@mbw83 We are taking this issue (and the others of course as well) seriously. We are continuously checking if we can reproduce the issue with the devices people have mentioned here. So please keep on posting the devices which still face the issues. We are taking them into account in further test efforts.
@MikeMcC399 The latest update is also shown on the home screen of the app. The next automated evaluation is scheduled for 24 hours later. It depends on OS scheduling and other aspects when it will actually happen. Usually it's 24 hours plus a little bit more. Only if the next update happens later than 24+4 hours after the last update, the scheduling hasn't worked properly and we recommend opening the app manually once again.

can you please double check in OS settings if the app is excluded from the phone's energy optimization/ akkuoptimierung
Also try to restart the phone and start the app once and check after ~28h if there is an entry in COVID-19 Notifications.
Please check this page https://dontkillmyapp.com/ for a working solution for your device.

@SebastianWolf-SAP

The latest update is also shown on the home screen of the app. The next automated evaluation is scheduled for 24 hours later. It depends on OS scheduling and other aspects when it will actually happen. Usually it's 24 hours plus a little bit more. Only if the next update happens later than 24+4 hours after the last update, the scheduling hasn't worked properly and we recommend opening the app manually once again.

Thank you for describing the expected interval of 24+4. Today my Samsung Galaxy A50 / Android 10 device did an automatic risk update at 19:35 following on from a previous automatic risk update the previous day at 7:25. This is an interval of 24:00+12:10. I have not opened CWA during this time, so the automatic risk update is delayed more than 8 hours (12:10 - 4:00) compared to what was expected.

@MikeMcC399
Was there any special conditions like heavy load, low battery or poor network connection?

@thomasaugsten

can you please double check in OS settings if the app is excluded from the phone's energy optimization/ akkuoptimierung
Also try to restart the phone and start the app once and check after ~28h if there is an entry in COVID-19 Notifications.
Please check this page https://dontkillmyapp.com/ for a working solution for your device.

Double check is done. Corona warn app is excluded from battery optimization

Restart is done. I will report here after ~28 hours.

@thomasaugsten

Was there any special conditions like heavy load, low battery or poor network connection?

No special conditions were occurring. I am checking against https://dontkillmyapp.com/. Although my model is not specifically referenced I think I can still infer what settings might help and I will try them out.

I wasn't involved in Android development in recent years, so take this with a grain of salt, but someone mentioned that foreground services should be used instead of background services, because they are less likely to be killed. They received no response to that comment.
Does corona-warn-app already use a foreground service for risk updates? Since foreground services must show a notification while they are active, and I haven't noticed any "update in progress" notifications from CWA, I assume it is a background service right now? If so, shouldn't the implementation be changed to use a foreground service instead?
Also regarding the scheduled update time, I can't confirm that the next update will take place 24 hours after the previous update. It appears like my phone used to schedule automatic updates at 6pm, but I've since switched to manually opening the app at ~6am instead, and 7am or 8am on weekends. The app never scheduled an automatic update at ~6am on weekends, it was always triggered by my opening the app a few hours later. I guess automatic updates are still scheduled for 6pm, so that would be 36 hours after my last manually triggered update.

@w-flo I would not recommend a foreground service as this causes the app to "run" all the time. More or less an endless loop. There are ways to mitigate, but using scheduled tasks AlarmManager  and  WorkManager is the correct pattern. However, it seems that in some versions of android the work scheduler API is not using AlarmManger but seems to choose TaskScheduler which is more energy efficient (bulk updates), but obviously ia not reliable on some devices/OS. If changing something I would rather propose to change to AlarmManger instead.
Another interesting thing appears in my Settings --> Google --> COVID-19 Notifications. It seems that the keys are checked multiple times with the same timestamp.
However, it only dates back 4 days. I guess that's because the list only shows the latest 100 entries.
Anyway, it seems as it is updating too often.

Nokia 7 plus
Android 10 (latest)
Corona-app 1.1.1

@matherm

As already reported in #637 there is a general android problem with background processing on several devices. https://issuetracker.google.com/issues/122098785
Very interesting link, but very frustrating to read...

Comment no. 91 in that linked issue thread has a nice idea...
Maybe it is possible to ask Google, to implement a scheduled task to the ENF, that triggers the registered exposure notifivcation app? Is something like this technically possible?

@vaubaehn

Maybe it is possible to ask Google, to implement a scheduled task to the ENF, that triggers the registered exposure notification app (for us: CWA) to run every couple of hours per day? Is something like this technically possible?

I read about the following improvement in the ENF:
"App force-stop improvements: if an app has been force-stopped in the background, the Exposure Notifications service will wake it up again automatically." in the Exposure Notifications release notes . Is this functionality doing what it is described to do, and if yes, why isn't that enough to solve the issue? Does anybody know?

@MikeMcC399 Thanks very much for that hint. Actually, I knew the release notes but overlooked it there!
For me it looks like the way to go.
Obviously it still seems to be buggy or not fully functional, would need a closer look together from google and our devs here, imho.

@MikeMcC399 thanks for pointing out this new feature. We are working day and night together with Google to improve the app. This new feature will be adopted soon by our app and should increase the stability of the background task.

Here is an overview of some Android devices from friends/family.
“Prioritized Background Activity” (PBA) was activated manually on all the devices on the 24.07. and I followed the Button in CWA to the device settings to check that the App is actually exempt from “Energy Saving”. I checked the logs for those phones on the 24th (the day of activating PBA) and on 28.07. to see whether days were missing before/after enabling PBA.
All Phones were running CWA version 1.1.1, and ENF version<PHONE_NUMBER>3.
The Phones checked were:

2x Samsung Galaxy S8 (Android 9): Both had lots of entries missing before the 24th, and were working perfectly afterwards even though the users didn’t regularly open the app manually.

LG G5 (Android 8): This was the only phone where the checks were performed every day even before the 24th. Unsurprisingly everything also worked fine after the 24th.

Samsung Galaxy S10e (Android 10): App was not working before the 24th (no checks within the last 14 days as the user hadn’t manually opened the app). Afterwards it was working perfectly even though the user didn’t regularly open the app manually.

Xiaomi Redmi 5 Plus (Android 8.1) and  Xiaomi Redmi Note 7 (Android 9): Before the 24th: the App was not working properly, only when manually opened checks were performed. Unfortunately, this didn’t change after the 24th even though PBA was enabled on both devices (one check was automatically performed on the 25th, but nothing afterwards).

Screenshot of the Redmi Note 7 Energy settings:

So in summary: On the Samsung devices setting PBA to “on” fixed the Problem. On the LG G5 there was no problem to start with, and CWA continued to work reliably after setting PBA.
Unfortunately for both Xiaomi devices activating PBA didn’t help.

@daimpi very nice and useful research!
That information might be very useful to the public also.

As written earlier, my Samsung Galaxy s10e was NOT fixed by activating PBA.
However, I've updated another setting (disabled it), and I need to wait for a new test result.

@thomasaugsten

can you please double check in OS settings if the app is excluded from the phone's energy optimization/ akkuoptimierung
Also try to restart the phone and start the app once and check after ~28h if there is an entry in COVID-19 Notifications.
Please check this page https://dontkillmyapp.com/ for a working solution for your device.

After reboot and waiting for ~28 hours still no improvement.
When starting CWA the update started immediately. ("Aktualisiert: Heute, 7:46")
More details can be provided on request

@thomasaugsten @speedy-1702

After reboot and waiting for ~28 hours still no improvement.
When starting CWA the update started immediately. ("Aktualisiert: Heute, 7:46")

I have also seen updates taking longer than 28 hours and I am beginning to suspect there are multiple root causes for the issue of risk update not running reliably without user interaction. I have been trying to check by using a USB cable and debugging with Android Debug Bridge (adb). I am though a complete newby at this!
I have one Samsung Galaxy Android 8 device that updated yesterday at 06:32 and I am puzzled that
adb shell dumpsys jobscheduler is showing an entry where the job seems to want to run for another 23h21m. It is currently 08:35, so I would expect it to run the next risk update within the next 2 hours (maximum of 24 +4 hours after the previous run). I will have to wait until 10:32 this morning to check whether the Google COVID-19 UI is telling me that it ran or not.
Here is a relevant portion of the output of adb shell dumpsys jobscheduler:
JOB #u0a172/0: 9365b07 de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
u0a172 tag=job/de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
Source: uid=u0a172 user=0 pkg=de.rki.coronawarnapp
JobInfo:
Service: de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
Requires: charging=false batteryNotLow=true deviceIdle=false
Extras: mParcelledData.dataSize=180
Minimum latency: +23h59m59s972ms
Backoff: policy=0 initial=+1m0s0ms
Has early constraint
Required constraints: BATTERY_NOT_LOW TIMING_DELAY
Satisfied constraints: CHARGING BATTERY_NOT_LOW APP_NOT_IDLE DEVICE_NOT_DOZING
Unsatisfied constraints: TIMING_DELAY
Doze whitelisted: true
Tracking: BATTERY TIME
Enqueue time: -38m59s343ms
Run time: earliest=+23h21m0s628ms, latest=none
Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)

can you please double check in OS settings if the app is excluded from the phone's energy optimization/ akkuoptimierung
Also try to restart the phone and start the app once and check after ~28h if there is an entry in COVID-19 Notifications.
Please check this page https://dontkillmyapp.com/ for a working solution for your device.

It also does not work on my Mi 9 Lite. The battery saving settings are off since a few weeks (I switched them of the first time it was recommended by a developer). Yesterday morning I double checked it, rebooted my device, started the app (updated 6:53) and waited until now (so ~30 hours). The update takes place immediately when starting the app (12:42) and not on its own.

The current date / time is Jul 30, 2020 15:00 and I am looking at another device (a Samsung Galaxy A60 running Android 10).
Settings > Google > COVID-19 exposure notifications shows
"Last checked for potential exposure on yesterday at 10:54"
24 + 4 hours after 10:54 is 14:54 today. Compare to current time 15:00 - the risk update is now late.
open CWA which causes manual risk update at 15:05
Settings > Google > COVID-19 exposure notifications shows
"Last checked for potential exposure on today at 15:05"
adb shell dumpsys jobscheduler shows the following, and the (planned) Run time was not affected by the manual update.
JOB #u0a379/63: 406e72d de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
u0a379 tag=job/de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
Source: uid=u0a379 user=0 pkg=de.rki.coronawarnapp
JobInfo:
Service: de.rki.coronawarnapp/androidx.work.impl.background.systemjob.SystemJobService
Requires: charging=false batteryNotLow=true deviceIdle=false
Extras: mParcelledData.dataSize=180
Minimum latency: +23h59m59s958ms
Backoff: policy=0 initial=+1m0s0ms
Has early constraint
Required constraints: BATTERY_NOT_LOW TIMING_DELAY [0x80000002]
Satisfied constraints: CHARGING BATTERY_NOT_LOW DEVICE_NOT_DOZING BACKGROUND_NOT_RESTRICTED WITHIN_QUOTA [0x3400003]
Unsatisfied constraints: TIMING_DELAY [0x80000000]
Doze whitelisted: true
Tracking: BATTERY TIME QUOTA
Implicit constraints:
readyNotDozing: true
readyNotRestrictedInBg: true
Standby bucket: ACTIVE
Enqueue time: -19h31m42s177ms
Run time: earliest=+4h28m17s781ms, latest=none, original latest=none
Last run heartbeat: 0
Ready: false (job=false user=true !pending=true !active=true !backingup=true comp=true)
If CWA carried out a manual risk update due to it being opened by the user, wouldn't it make sense for the automated update time to get reset, so the next automated update took place 24 hours later? Also it would be helpful as an enhancement for the CWA UI to show when it next plans to carry out an automated risk update if there is no user interaction in the meantime.

@SebastianWolf-SAP asked for affected devices.
Mine ist the Honor View 20 with the latest patches
"Priorisierte Hintergrundaktivität" is turned on
Same problem "I've checked the entries under Settings --> Google --> COVID-19 Notifications. They don't get updated until I open the app again."
Pleased let me know If I can support you.
Of course I might test a fix.

I have some news from my Samsung Galaxy S10e.
After I had set "Adaptive Battery" and "Standby for unused Apps" to false, the COVID-19 Notifications got automatically updated after 24 hours.
The "Standby for unused Apps" seems to be the critical point. I've just enabled "Adaptive Battery" back to true to verify tomorrow that it will still work, hopefully.
What is also interesting about "Standby for unused Apps": the setting allows to declare apps as exceptions from the standby. However, the Corona-Warn-App is not listed there, meaning, I cannot add it as an exception.

And I can tell about my partner's Honor View 20 on Android 10.1: The notifications get updated in the background since he has set the following:  Battery --> App Start -->disable "Corona-Warn-App" --> new page: let all three entries active.

@NKarolak Thank you! Just activated the
suggested setting. Will see the result tomorrow (Hope I remember not to start cwa manually 🤣).
Will report here.

@SebastianWolf-SAP

So please keep on posting the devices which still face the issues. We are taking them into account in further test efforts.

Huawei P30 here. App version is 1.1.1, recommended settings applied in the app after the latest update. Never manually tinkered with battery settings anywhere. Still, in Settings - Google - COVID-19 Exposure Notifications, I read

Last checked for potential exposure July 30 at 07:59

That is >3 days ago. I have now applied the setting from https://github.com/corona-warn-app/cwa-app-android/issues/933#issuecomment-667570667 and will wait and see if  that resolves the issue without having to open the app.

No background notification today.
But I did not start the app yesterday after activating the setting.
Did that now, will report tomorrow.

@NKarolak Thank you! Just activated the
suggested setting. Will see the result tomorrow (Hope I remember not to start cwa manually 🤣).
Will report here.

Same problem on the bq Aquaris X2 (Android One). Using v1.1.1 with PBA turned on.
Android Version 10; Security Patch Level 2020/7/1; Build 3.1.1_20200629-1045
"Adaptive Battery" was active; I just now deactivated it for testing and will report back if it changed anything.

Same problem on the Fairphone FP3, CWA v1.1.1 with PBA on
Android 9 / GPS 20.26.14

Same problem here on Xiaomi Mi A3. CWA v1.1.1, PBA on. Android 10, latest security patches.

24 + 4 hours after 10:54 is 14:54 today. Compare to current time 15:00 - the risk update is now late.

I still believe the 24+4 "rule of thumb" is incorrect. My phone does automatic risk updates reliably, but it's always around 6pm. Same for my partner's phone, but always at ~9pm. If we open the corona-warn-app at 6am in the morning, it will instantly do the update for that day and obviously skip the automatic update in the evening. Next day, it won't do the automatic background update after 24 hours in the morning at ~6am, but at ~6pm or ~9pm in the evening as it always does. So the time between risk updates is ~36 or ~39 hours in those cases, not 28.
If it's the same for other phones, you can only be sure about failed background updates if a full day from midnight to midnight has gone by without any risk updates.

@w-flo

I still believe the 24+4 "rule of thumb" is incorrect. My phone does automatic risk updates reliably, but it's always around 6pm. Same for my partner's phone, but always at ~9pm. If we open the corona-warn-app at 6am in the morning, it will instantly do the update for that day and obviously skip the automatic update in the evening. Next day, it won't do the automatic background update after 24 hours in the morning at ~6am, but at ~6pm or ~9pm in the evening as it always does. So the time between risk updates is ~36 or ~39 hours in those cases, not 28.
If it's the same for other phones, you can only be sure about failed background updates if a full day from midnight to midnight has gone by without any risk updates.

What you describe is also what I am seeing: The background update planned time is independent of any foreground risk update that takes place due to opening the app. I hope to get some clarity about what a user can expect through the https://github.com/corona-warn-app/cwa-wishlist/issues/142 , although right now this just a wish-list item. Maybe another wish-list item would be to reschedule the next planned background update to be based on the latest risk update time, whether it was caused by a background or a foreground update? Using the current intervals that would mean the next update would be 24 hours later, not 36 or 39 as in your examples.

Identische Fehlermeldung beim öffnen der App auf meinem  Samsung Galaxy M20 (SM-M205FN) mit Android 10, Corona-Warn-App 1.1.1.
In den Geräteeinstellungen ist der Energiesparmodus für die Corona Warn App schon seit einem früheren Problem ausgestellt und in der Corona App ist der Schalter für die priorisierte Hintergrundaktivität an. Bis vorgestern lief alles problemlos, ohne dass seitdem irgendetwas geändert wurde; und ein neustart des Geräts hat auch keinen Einfluss darauf, der Fehler bleibt.

No background notification today.
But I did not start the app yesterday after activating the setting.
Did that now, will report tomorrow.

@NKarolak Thank you! Just activated the
suggested setting. Will see the result tomorrow (Hope I remember not to start cwa manually 🤣).
Will report here.

Waitet a bit longer because of the 24+4 discussion.
No background notification since 02.08. 17:48.
I wonder why it works on @NKarolak s mobile...

@heinosahling  My partner's phone ;-)
I was in the very same situation like you: Another user reported for my phone that the CWA update already fixed the issue.
But this did not work for me because I had additional settings the other user's (friend/family) phone apparently had not: Standby for unused apps
There must be some similar advanced battery setting active on your phone. My boyfriend is not using any special battery settings since the battery on the Honor View 20 is awesome all by itself (as he says) :-)

Last checked for potential exposure July 30 at 07:59

I have now applied the setting from #933 (comment) and will wait and see if that resolves the issue without having to open the app.

It did not (without manually opening the app), I'm still at "July 30 at 07:59". After opening the app, the update worked fine: it's now at "today at 09:29". I closed all apps again (App overview -> recycle bin) and am eager to see when the next update happens.

For me it seems to be working now, August 1. to 4. all got checks in the google api log.
My phone is a Xiaomi Mi 8 with MIUI 11.0.5.

I have now applied the setting from #933 (comment)

After opening the app, the update worked fine: it's now at "today at 09:29". I closed all apps again (App overview -> recycle bin) and am eager to see when the next update happens.

Just now, it was at "yesterday at 06:27". So it has updated, but again, more than 24(+4) hours ago. I remember opening the app yesterday night, which did not trigger an update apparently - not sure is that should have an effect.
Anyway, let's hope 1.2.0 has something so say about this :)

Same problem here on Xiaomi Mi A3. CWA v1.1.1, PBA on. Android 10, latest security patches.
BTW: Android One

UPDATE: Did not open the app since 3rd August. Today I looked into the Einstellungen->Google->Covid-19-Benachrichtigungen->Überprüfungen.....
Here are the results: entries for 3. August 14:57 (when I lastly opened the app); 4. August 16:57 (26 hours from then); 5. August 17:27 (24,5 hours) and today 17:22, which is 23 hours and 55 minutes from yesterday.
So for me it kinda seems to work. Hope this helps someone.

@vaubaehn

Maybe it is possible to ask Google, to implement a scheduled task to the ENF, that triggers the registered exposure notification app (for us: CWA) to run every couple of hours per day? Is something like this technically possible?

I read about the following improvement in the ENF:
"App force-stop improvements: if an app has been force-stopped in the background, the Exposure Notifications service will wake it up again automatically." in the Exposure Notifications release notes . Is this functionality doing what it is described to do, and if yes, why isn't that enough to solve the issue? Does anybody know?

@MikeMcC399 It looks like this is functionality is being implemented: https://github.com/corona-warn-app/cwa-app-android/pull/947 🙂

@daimpi

I read about the following improvement in the ENF:
"App force-stop improvements: if an app has been force-stopped in the background, the Exposure Notifications service will wake it up again automatically." in the Exposure Notifications release notes . Is this functionality doing what it is described to do, and if yes, why isn't that enough to solve the issue? Does anybody know?

@MikeMcC399 It looks like this is functionality is being implemented: #947 🙂

According to the Release Notes for 1.2.0 there are two changes which mention the WakeUpService:

Re-schedule jobs if they were killed and the app was woken up by the WakeUpService https://github.com/corona-warn-app/cwa-app-android/pull/972
Added key retrieval logic in app's onCreate to include Googles WakeUpService https://github.com/corona-warn-app/cwa-app-android/pull/947

I haven't seen Version 1.2.0 published on Google Play Store yet. It is still showing Version 1.1.1. Has anybody seen a planned publication date?

I haven't seen Version 1.2.0 published on Google Play Store yet. It is still showing Version 1.1.1. Has anybody seen a planned publication date?

It has probably already been pushed to Google, but it always takes a while to go through the process there until it actually shows up in the play store. My guess would be that it arrives there sometime later today :).

Version 1.1.1 is installed since last week and “prioritized background activity” is set to on. Today I clicked on my risk status and saw that the last update was two days a

sorry i write here, but found no other place to come in. Similar problem: app has its 1.1.1, akku-optimierung is off. my app shows me one risk (green) since over 4 weeks now. Should have disappeared after 14 days, right? No second one up to now. Does it still work? Actualisierung every day works..hope to find back here for the answer later. I am an old women, who was in the end sent here after much trying to answer this question at the usual places... :-)

@digundi
We are working on this and fix this soon
https://github.com/corona-warn-app/cwa-app-android/issues/911
The app is working correctly please ignore this 1 risk until we fix this.

vielen Dank und many thanks :-)

I haven't seen Version 1.2.0 published on Google Play Store yet. It is still showing Version 1.1.1. Has anybody seen a planned publication date?

It has probably already been pushed to Google, but it always takes a while to go through the process there until it actually shows up in the play store. My guess would be that it arrives there sometime later today :).

Hi @daimpi , I'm replying here to your Gitter question 😉, but it also fits here in this context.
My Playstore on phone actually shows 6/8/2020 as update date, but is only offering v1.1.1. Playstore on desktop browser shows July 20th though.
I guess it was indeed pushed to playstore, but is either still on hold by dev team (if this is possible?) for testing purposes, or the checks from Google are still not finished... I somehow remember that somewhere in Google's ENF documentation was mentioned that checks of all Corona apps get special treatment for security after publishing to the store.

I'm now seeing CWA Version 1.2.0 appearing on Google Play Store. :-)

The version 1.2 supports the App force-stop improvements from the ENF. This means if the app is forced stop by the device specific Battery optimization the ENF will restart the App every 24h to allow a background exposure check. Please check on your device with not stable background check if this helps to ensure a check every 24h.

No background notification today.
But I did not start the app yesterday after activating the setting.
Did that now, will report tomorrow.

@NKarolak Thank you! Just activated the
suggested setting. Will see the result tomorrow (Hope I remember not to start cwa manually 🤣).
Will report here.

Waitet a bit longer because of the 24+4 discussion.
No background notification since 02.08. 17:48.

Just updated to 1.2.0 and checked settings.
Will report tomorrow if background notifications are working (hope so).

I've also updated the two Xiaomi devices which still had problems. I'll report back in a few days whether this fixed the issue for them🙂.

I updated yesterday CWA to v1.2.0,. Today ~9:45 the background update worked automatically, which is ~24hrs since last update.
So all in all, for me the problem seems to be solved.

Unfortunately no success with my Honor View 20 :(
Still "Letzte Überprüfung ... gestern um 12:14".
I checked possible settings (@NKarolak 's suggestions and links) but found nothing.
Any ideas? I will open CWA manually but other people?

@heinosahling please wait with opening the app until the next day. Can you give more details about your phone and os version

@thomasaugsten OK
Here a few screenshots:

@thomasaugsten
no background update until now :(
Anything I can do for further analyses?

You can contact me directly and we can create a android bug report
<EMAIL_ADDRESS>

@heinosahling
One reason, why it might still not work for you, could be, that the background process for the update is actually started but not completed successfully. If an exception is thrown (e. g. 9002 xxx) in the background (CWA is closed), that exception would be discarded silently and the matching for keys would be interrupted, hence the Google Covid notifications show no current update.
Did you ever come across one exception 9002 when CWA was open, or API 39508 during times between 2am in the morning and 23:59pm?
Did I see right from your last screenshots that you have VPN enabled (the key symbol in the notification bar)? Do you always use VPN? There may be a chance that there is a timeout exception in the background when CWA tries to download the diagnosis keys.
Do you use any firewall on your phone? Or some antivirus app?
Is there any chance, even background prioritization enabled, that still an energy saving setting is active that causes the CPU to throttle the speed down? Then there might be a time out exception within ENF while matching the keys.
Did you ever use or ever enable PrivateSpace (Huawai/Honor specific privacy data storage container) for your phone, or might have been preconfigured to be active when you bought it?
If one answer to above questions above is 'yes', there may be a chance it's related. And if @NKarolak 's partner's phone is still working without problems with CWA, maybe in above questions there maybe one point differently in your phone setups.
Regards,
V.

@thomasaugsten

The version 1.2 supports the App force-stop improvements from the ENF. This means if the app is forced stop by the device specific Battery optimization the ENF will restart the App every 24h to allow a background exposure check. Please check on your device with not stable background check if this helps to ensure a check every 24h.

I haven't had update problems lately but I was curious about how robust the restart functionality would be, so I deliberately killed CWA via.
Settings > Apps > Corona-Warn > FORCE STOP at 16:22 yesterday Aug 12, 2020. The previous last check for potential exposure according to
Settings > Google > COVID-19 Exposure Notifications was at 08:57 yesterday Aug 12, 2020.
At 14:55 today Aug 13, 2020 a new check for potential exposure was carried out. So there was a gap of 24 hours + 5h58m between exposure checks.
I'm happy that CWA is recovering from no background activity running without any user intervention! :-) Great job!
Configuration is:
Exposure Notification System:<PHONE_NUMBER>0
CWA: 1.2.0
Android: 8.0.0
Phone: Samsung Galaxy A5 (2017) SM-A520F

@MikeMcC399
These are great news!
And moreover,

Configuration is:
Exposure Notification System:<PHONE_NUMBER>0

a new ENF is out! Documentation yet seems to have updated only partially.

@vaubaehn

Configuration is:
Exposure Notification System:<PHONE_NUMBER>0

a new ENF is out! Documentation yet seems to have updated only partially.

I'm enrolled in the Google Play Services beta, and so Exposure Notification System:<PHONE_NUMBER>0 is probably a beta version.
Unfortunately the Google Exposure Notifications release notes don't list detailed version numbers and the best explanation is the CWA:FAQs Which version of the COVID-19 Exposure Notification Framework is currently installed?
In fact for this device Settings > Apps > Show system apps > Google Play services > App details in store
shows Version 20.26.14 under "About this app" which is lower than the installed ENS version 20.30.16.
That may not make any difference as far as the WakeUpService is concerned. It's difficult to know from the Google documentation that I have found.

As more crashes of Huawei devices upon opening CWA are reported here in repository and in reviews on Google Play Store, and referencing to https://github.com/corona-warn-app/cwa-app-android/issues/642#issuecomment-673567727 and https://github.com/corona-warn-app/cwa-app-android/issues/642#issuecomment-673547370, are there any incompatibilities of "prioritized background activity" addressed by CWA and/or ENF-WakeUpService, at least for Huawei P8 lite on Android 6 (Modus "geschützte Apps")?

Hi @GabiLele and @marcelm,
GabiLele, could you try to set CWA to Modus "geschützte Apps" like marcelm described in the 9002 sqllite crash thread? Some pictures on where to find are also here: https://salfeld.de/faq/android/huawei/akku-einstellungen/ (scroll down)
marcelm and GabiLele, if you are able to open CWA again, can you check whether if "Priorisierte Hintergrundaktivität" is "An" in the menu "Einstellungen" of CWA?
And could you report in a couple of days, if everything is still fine for you = no app crash on start & background update works ervy day? Thank you

I updated yesterday CWA to v1.2.0,. Today ~9:45 the background update worked automatically, which is ~24hrs since last update.
So all in all, for me the problem seems to be solved.

Sorry for contradicting myself, but I must admit that there is no improvement with v1.2.0
So at the first day it could be coincidence, that it worked fine. I remember, that I have rebooted my phone after installing new version, which I usually don't do.
Screenshots attached.

@speedy-1702 thanks for this information but why is there no exposure check after you open the app? Can you give us details about your phone we will handover this to google.

@speedy-1702 thanks for this information but why is there no exposure check after you open the app? Can you give us details about your phone we will handover this to google.

@thomasaugsten
I think, this is a new bug. Didn't see this in 1.1.1.
But in 1.2.0 (and now 1.2.1). Perhaps an UX problem?
Here some screenshots (Honor View 20)

Thank you @vaubaehn
Here are my comments

@heinosahling
One reason, why it might still not work for you, could be, that the background process for the update is actually started but not completed successfully. If an exception is thrown (e. g. 9002 xxx) in the background (CWA is closed), that exception would be discarded silently and the matching for keys would be interrupted, hence the Google Covid notifications show no current update.
Did you ever come across one exception 9002 when CWA was open, or API 39508 during times between 2am in the morning and 23:59pm?

No. Are there logs where I may have a look (without root)?

Did I see right from your last screenshots that you have VPN enabled (the key symbol in the notification bar)? Do you always use VPN? There may be a chance that there is a timeout exception in the background when CWA tries to download the diagnosis keys.

Yes, adblocker working as VPN. Deactivated it the
1,5 days but no difference.

Do you use any firewall on your phone? Or some antivirus app?

No.

And for sure, network (either wifi or mobile) needs to be active while CWA is in the background or the telephone dozes (screen off) -> there are some apps like netguard, that may turn off network, while screen is off - do you use something like this?

No. I use "nicht stören" during the night. But this should not be a problem?

Is there any chance, even background prioritization enabled, that still an energy saving setting is active that causes the CPU to throttle the speed down? Then there might be a time out exception within ENF while matching the keys.

I had a look (also @NKarolak  links) but didn't find anything.

Did you ever use or ever enable PrivateSpace (Huawai/Honor specific privacy app & data storage container) for your phone, or might have been preconfigured to be active when you bought it?

I don't think so. If Honor preinstalled something like that, what could it be?!

If one answer to above questions above is 'yes', there may be a chance it's related. And if @NKarolak 's partner's phone is still working without problems with CWA, maybe in above questions there may be one point differently in your phone setups.

Yes. But what?

Regards,
V.

I got some more bad news: on 11th August I installed CWA 1.2.0 on the two Xiomi phones in my family where background sync was not working properly even with PBA enabled in 1.1.1.
“Prioritized Background Activity” (PBA) was activated on both devices and I followed the button in CWA to the device settings to check that the App is actually exempt from “Energy Saving”. I checked the logs for those phones on the 11th  (the day of updating to version 1.2.0) and today (15.08) to see whether days were missing after upgrading to 1.2.0. I also instructed the phone owners not to open CWA after I had updated it to version 1.2.0 on August 11th.
Both phones were running ENF version<PHONE_NUMBER>3.
The two phones tested were:

Xiaomi Redmi 5 Plus (Android 8.1)
Xiaomi Redmi Note 7 (Android 9)

Before the 11th: CWA was not working properly, only when manually opened checks were performed. Unfortunately, this didn’t change after the 11th even though PBA was enabled and version 1.2.0 was installed on both devices (no checks were performed on either device after opening the app manually on the 11th).
When opening the App today I was first greeted with a white screen saying “Risk Calculation not possible:

I took a screenshot and when I switched back to CWA the app was now showing a proper “green/low risk” screen indicating that everything was fine. Probably it just took a few seconds for the app to update after laying dormant for so long.
Another thing I noticed is that the App had been updated to 1.2.1 at some point in between 11th and today.

So in summary:
Unfortunately for both Xiaomi devices updating to 1.2.0 didn’t help with automatic background sync.

Thanks for your feedback we will handover this information to google.

Hi @heinosahling , thanks for your reply.

One reason, why it might still not work for you, could be, that the background process for the update is actually started but not completed successfully. If an exception is thrown (e. g. 9002 xxx) in the background (CWA is closed), that exception would be discarded silently and the matching for keys would be interrupted, hence the Google Covid notifications show no current update.
Did you ever come across one exception 9002 when CWA was open, or API 39508 during times between 2am in the morning and 23:59pm?

No. Are there logs where I may have a look (without root)?

There are some tools that can be helpful (for example SysLog), but limitations may apply without root, and it's some effort to set it up working.
Maybe the developers here may think about implementing a small debug feature, like a switch 'debug mode' inside CWA-settings, that provides logging tasks and exceptions, and compiles a simple text output for copy/paste?

VPN?

Yes, adblocker working as VPN. Deactivated it the 1,5 days but no difference.

If VPN-adblocker was fully deactivated, can be excluded then.

firewall? antivirus?

No.

network disabled? netguard-like stuff?

No.

Any additional energy saving setting active?

No.

PrivateSpace (Huawai/Honor specific privacy app & data storage container)

I don't think so. If Honor preinstalled something like that, what could it be?!

Could almost be excluded meanwhile, by reports of other users.
(PrivateSpace, in short, is an encrypted app & data container for Huawei and Honor devices, that prevents other people that are using/stealing your phone, to peek inside your private data (pictures, chats, etc). The feature is introduced since EMUI5/EMUI8, depending on device type)
I'm now running out of ideas. Last resort - see next comment.

Hi @daimpi (and also @heinosahling ),
while everone is now waiting for news from google in this subject, one last question addressed to you. I know, that question sounds ridiculous, but ...
Have your devices been connected to a charge during the time when automatic update was expected to happen?
Could you maybe try to connect at least one device for 24h+, and see, if this makes the automatic update work?
Background: I'm referring to here, here , and here. We know, that since ENF 1.5 a WakeUpService can be used, that starts CWA (1.2.0+), if it was killed/suspended by the device's energy policies, or if it was force-stopped (by the user). What I do not know (maybe the developers can give more elaborate information on this), is, whether waking CWA up/starting it, is just enough to let it work. If the device is not connected to the power charge, doze mode may be active, when phone was not used for some time and screen is off. If CWA was not used for a longer time, it may be in App-StandBy. If it was not used for an even longer time, it may be inside the RareBucket. If the Battery Saver is enabled (not to mix up with PBA), CPU clock may be drastically throttled down.
 As we saw here, manually waking up the phone from Battery Saver and immediately starting CWA ends up in a 9002: Time Out waiting for 60000ms. If the same happened with CWA working in background, I guess the automatic update would just fail silently.
is the doze mode completely disabled for CWA and all dependent components? If not, we might expect the background tasks for fetching the data from server, and for matching diagnosis keys with collected RPIs to be deferred to a maintenance window somewhere in the future. If many other tasks start inside that maintenance window, I think it's not impossible, that we could end up in a race condition, and maybe again in a silently discarded exception 9002... especially when performing the cryptography in ProvideDiagnosisKeys().

If the WakeUpService is actually waking up CWA and all nescessary components, no problems with doze or AppStandBy occur, then I guess, CWA would still need to validate that all components are up and running, before fetching data from server, and before calling ProvideDiagnosisKeys(), or there may be the likelihood to run into a race condition.
Just my 2 cents.
Let's see, what Google may report, or if the developers like to give some information.

Automatic Update also still doesn't work for me on my Xiaomi Mi9 Lite.

@thomasaugsten

@speedy-1702 thanks for this information but why is there no exposure check after you open the app? Can you give us details about your phone we will handover this to google.

WiFi network has been switched off while taking the screenshot.
Otherwise, date/time of last exposure check would not be visible in CWA.
Or at least I don't know where to look up.
After switching network on and triggering update manually, exposure check works fine.
Please take care of this issue most seriously. Understand, that for me personally this issue does not bear any risk, because I manually update every 2nd day. But there might be hundreds of thousands of users with this same problem, not being aware of the risk they are taking, lulling themselves in safety and spreading the disease.

We working 24/7 together with google to get a stable background task on Huawei and Xiaomi devices.

@vaubaehn
Thank you for your comment.
did change the settings to "geschützte App" after I got this recommendation. Then I took a break of about 30 hours (another recommendation from RKI) and checked for the first time today. I am afraid, I still cannot open the app. I do see the logo on a white background on the whole display, before it "implodes".
The app has been updated to version 1.2.1. since my last post.
Thanks for all your help and suggestions.
GabiLele

Hi @GabiLele ,
Can you try to delete both cache and data from within your phone's settings menu,
Settings > Apps > CWA > Storage (Speicher)

Will CWA open again after deleting cache and data?

We working 24/7 together with google to get a stable background task on Huawei and Xiaomi devices.

@thomasaugsten
Just to let you know that background update on my Huawei P20 works like a charm for 3 days by now.
But I must admit that there were a lot of tests and restarts necessary to get this result.
Huawei P20
Android-version 10
EMUI-version 10.0.0
CWA version 1.2.1
ENF version<PHONE_NUMBER>3
CWA version (starting point) : 1.2.0
"Prioritized Background Activity" (PBA) was activated manually and after excluding CWA from Huawei's method to reduce energy consumption via -
(Einstellungen  -> Akku  -> App-Start) switching CWA to "Manuell verwalten" (setting "Auto-Start", "Sekundärer Start" and "Im Hintergrund" to ON)

I made a restart of the device.

The timeline concerning various updates in the last 4 days now looks as follows :
13.08.2020 - 07:03   update by manually/foreground start of CWA
(CWA running with version 1.2.0)
13.08.2020 - 08:25   Huawei P20 was restarted
(CWA running with version 1.2.0)
14.08.2020 - 14:52   change of CWA version - manually updated from 1.2.0 to 1.2.1
14.08.2020 - 15:10   update by background start of CWA
15.08.2020 - 15:16   update by background start of CWA
16.08.2020 - 15:16   update by background start of CWA
Due to the update time of CWA version 1.2.1 I unfortunately can't explain if the problem solution depends on the new app version or on another condition.
My guess : It's version 1.2.1 that caused the change.
Another difficulty concering the testing is that you must be aware of the possible time lag between last foreground and first background update (in my case 24h + 8h) !
Perhaps you can explain here what is the maximum value for this time lag to be expected (24h or less)?

@vaubaehn

Have your devices been connected to a charge during the time when automatic update was expected to happen?
Could you maybe try to connect at least one device for 24h+, and see, if this makes the automatic update work?

I don't know whether they were charging while the checks should have been performed, but there is a good chance that they were not.
And yes: I can make this test with 24h+ charger connection on the Redmi Note 7. This device had their last update today (16th) at approx. 4am (from opening CWA manually). I'll connect it now and leave the app closed and report back tomorrow whether or not a check has been performed. Anything additionally you'd want me to check? 🙂
Btw: wouldn't this be a perfect opportunity to leverage the Telekom testing center?
Maybe some of the devs could contact them and ask to help out? 🙂

Hi we work together with google to improve the wakeupservice. To get this improvement is no CWA or manual interaction needed we will inform you when the wakeUpService is changed. The Telekom Test Cloud is already testing with a huge effort the CWA but the the amount of Android device is so large we also need your support. Thanks for your input here.

No problem 🙂
The test is running and I'll report back tomorrow. If there is any additional logging data etc. which I should provide, lemme know :).

Hi @daimpi ,

And yes: I can make this test with 24h+ charger connection on the Redmi Note 7. This device had their last update today (16th) at approx. 4am (from opening CWA manually). I'll connect it now and leave the app closed and report back tomorrow whether or not a check has been performed.

That's great, thank you!

Anything additionally you'd want me to check? 🙂

To have the best prerequisites to test for a problem associated with the doze mode, and to enable best conditions to not run into a race condition, could be good if

you maybe check tomorrow afternoon (24h + 12h)
you leave the device plugged to charge when checking
you turn on screen, and maybe at first start a browser, surfing internet for some minutes, just to be sure, all components run at full speed (sounds a little paranoid, I know)
you then check from Google Covid-notificatons, if the update was performed
you finally start CWA.

Btw: wouldn't this be a perfect opportunity to leverage the Telekom testing center?

Cool, I didn't know, something like this exists 😃
All phones in the picture are plugged to charge there, btw...
I'm very curious, what will be the result of your test. However, I don't have much hope. The chances that it works are dependent on

if the Redmi respects official Android specs (= no dozing when charge is plugged) at all, and
if there is no special energy management (switching to slow CPU cores, when screen was turned off) to not run into a race condition with hardware and OS when starting background task.

Thanks again and see you tomorrow!

To have the best prerequisites to test for a problem associated with the doze mode, and to enable best conditions to not run into a race condition, could be good if

you maybe check tomorrow afternoon (24h + 12h)

you leave the device plugged to charge when checking

you turn on screen, and maybe at first start a browser, surfing internet for some minutes, just to be sure, all components run at full speed (sounds a little paranoid, I know)

you then check from Google Covid-notificatons, if the update was performed

you finally start CWA.

Will do 👍

I'm very curious, what will be the result of your test. However, I don't have much hope. The chances that it works are dependent on

if the Redmi respects official Android specs (= no dozing when charge is plugged) at all, and
if there is no special energy management (switching to slow CPU cores, when screen was turned off) to not run into a race condition with hardware and OS when starting background task.

Ya I'm also not super hopeful wrt this… it's not the first time that I hear that especially some Chinese manufacturers pull some crazy shenanigans when it comes to battery management, completely ignoring spec and only allowing apps they manually whitelisted to run properly…

@vaubaehn
Thank you for the suggestion. I did delete both the cache and data and was able to open the app again. I am back to square one, same after I first installed the app, but I think in the end it would have been the same if I de-installed and re-installed the app.
I just hope, that this will not be the way for the future. To go back to the beginning every couple of days seems to defeat the purpose.
GabiLele

@GabiLele

I did delete both the cache and data and was able to open the app again.

Happy to hear, that it helped as a first aid.

I am back to square one, same after I first installed the app, but I think in the end it would have been the same if I de-installed and re-installed the app.

Actually, for the time being, there is a huge difference whether you uninstalled / reinstalled the app, or you just deleted data/cache of CWA:
All the 'bluetooth signals' (RPIs) that you collect from other people when you are outside, they are not stored by CWA, but by / 'inside' the Google Exposure Notification framework (ENF). If you just delete the data of CWA, what will be deleted is, in short, just some data, that is used by CWA to give some information to the user, like, how long (how many days) has Exposure Logging been active, what time has the last risk calculation been done by CWA, and so on. If you delete CWA's data, the RPIs will stay stored on your device. And the next time CWA performs a risk calculation, your personal risk can be evaluated for up to the last 14 days. If you had a risk encounter in the past 14 days, CWA would be able to tell. The only not accurate data is, how long had your exposure logging been active.
When you uninstall and reinstall CWA, the ENF is triggered to also erase all of your stored RPIs inside the ENF. In that case, you are really starting from the very beginning. If there was any risk encounter in the past 14 days, CWA couldn't tell you, because all information for that was lost with uninstalling CWA.

I just hope, that this will not be the way for the future. To go back to the beginning every couple of days seems to defeat the purpose.

I don't think so. I strongly believe in what @thomasaugsten wrote here https://github.com/corona-warn-app/cwa-app-android/issues/933#issuecomment-674498052 : Google and SAP working 24/7 together to find a solution. And in the past two weeks, I really found @thomasaugsten replying to user concerns 24/7 ( <- as a personal note to him: thanks a lot for your engagement. But please also take care & stay healthy, we need you!). The reason, that he is almost the only one communicating with us here in these days, I guess, is, that after a strainful episode of releasing CWA 1.x, maybe most of the developers are now in their well-deserved summer vacation to regain some energy?
One important question is, if you maybe can work-around to prevent CWA from crashing in the future, until SAP and Google may provide a solution for this problem.
I now, more and more, assume, that many of reported severe bugs and crashes here are related to problems with energy saving policies of some combinations of devices and OS versions.
I know, it sounds weird, but what you might try to prevent CWA from crashing is (needs to be done regularly!):

plug the power charge to your device (that should awake your device from doze mode)
start a browser and read some news in internet for a minute (that should ensure, all nescessary hardware and software components are up and running)
now you can start/open CWA.
when you are finished with CWA, close it, and leave the power plug connected to your phone for maybe 10 seconds, then disconnect (with some chance, this might prevent your OS from killing all CWA-tasks before CWA was able to write all data to your internal storage).

To ensure that your OS is not doing any harm to CWA's data (what may lead to the crash), you might also want to connect your device to a power charge around the time the automatic background update of diagnosis keys is done. For many users, this is usually during the night time when sleeping. For other users, it's done during the day time, which somehow seems to be associated with the day time when the latest CWA releases were installed (I guess, the new ENF version is triggered by installation and uses that time to schedule the WakeUpService).
Or, in other words: for now, until final solution is provided, try to keep your device plugged to power as often and long as possible.
But - this work-around can only work, if the OS of your device follows the official Android specs for doze mode at all (see comments above, if you want to have some more insight), and, if I'm not completely wrong in my assumption that these problems are related to energy saving policies.
Would be nice to get a feedback from you in some days, whether the work-around was helpful for you.
See you

Hi, @daimpi ,

you maybe check tomorrow afternoon (24h + 12h)
you leave the device plugged to charge when checking
you turn on screen, and maybe at first start a browser, surfing internet for some minutes, just to be sure, all components run at full speed (sounds a little paranoid, I know)
> > * you then check from Google Covid-notificatons, if the update was performed

Just in case, there was no automatic update, and if, for sure, you family member allows it, could you then wait to open CWA at past midnight? Because we don't know, what time the background task is scheduled to, so, theoretically it still could run in the rest of the day...
See you :)

Just in case, there was no automatic update, and if, for sure, your family member allows it, could you then wait to open CWA at past midnight? Because we don't know, what time the background task is scheduled to, so, theoretically it still could run in the rest of the day...
See you :)

Yes, that was my plan anyway 😉.
In this case I'll actually wait till 02:15 when the new packages arrive on the server, just to be sure 🙂.

@vaubaehn I just checked (after 24 + 12h) w/o opening CWA and while still being connected to power. I also ran the phone for a few minutes (browsing etc…) before checking the Google ENF settings.
Unfortunately, still no update has been performed.
I will report back tonight after the new packages from today have been uploaded to the server.
Btw: I'm seeing more devices from Chinese manufacturers probably experiencing the same problem:

https://twitter.com/Nini1704/status/1295345655028776964 (Huawei Mate 20 Pro)
https://twitter.com/carsimoto/status/1295339690602770436  (Honor View 10 mit Android 10. 0.0.117)

Hi, @daimpi ,

you maybe check tomorrow afternoon (24h + 12h)
you leave the device plugged to charge when checking
you turn on screen, and maybe at first start a browser, surfing internet for some minutes, just to be sure, all components run at full speed (sounds a little paranoid, I know)
> > * you then check from Google Covid-notificatons, if the update was performed

Just in case, there was no automatic update, and if, for sure, your family member allows it, could you then wait to open CWA at past midnight? Because we don't know, what time the background task is scheduled to, so, theoretically it still could run in the rest of the day...
See you :)

Phone was plugged most of the time since yesterday evening.
I was out and forgot to re-plug (~1 hour missing
until half an hour ago). Last background update still yesterday 09:46.
Must end test for today (and start cwa manually now), but will test tomorrow and Wednesday.

@vaubaehn I checked now after almost 48h of not opening CWA since its last sync and still no update has been performed even though I was keeping the phone connected to power and I also ran the phone for a few minutes (browsing etc…) before checking the Google ENF settings. After opening CWA I was greeted  with a green/low risk status screen telling me that the last update had been performed two days ago:

This screen persisted for >10s and after a while I took a screenshot and when switching back to the app it now told me that it just had performed an update.
Apart from the issue with background updates not working I think this is leads to a sub-optimal UX, as it confuses users who only see this info and don't know what is going on. Tbh I'm not so sure myself what finally led to the update being displayed/performed: maybe it was switching out of the app and back in again, or maybe it was just the time which passed 🤷 .

Strange behavior:

Phone was plugged most of the time since yesterday evening.
I was out and forgot to re-plug (~1 hour missing
until half an hour ago). Last background update still yesterday 09:46.
Must end test for today (and start cwa manually now), but will test tomorrow and Wednesday.

I startet cwa manually yersterday at 17:00.
In the morning I had to restart the mobile (because it didn't connect to my wifi) -  first restart since a month or more.
A few hours later I realized that there was an update at 08:24. Exactly the time the mobile booted!
So it looks like background update may be able to work...
I will keep watching...

Apart from the issue with background updates not working I think this is leads to a sub-optimal UX, as it confuses users who only see this info and don't know what is going on. Tbh I'm not so sure myself what finally led to the update being displayed/performed: maybe it was switching out of the app and back in again, or maybe it was just the time which passed shrug .

I can reproduce this behavior, for me it's an new Bug in 1.2x, see https://github.com/corona-warn-app/cwa-app-android/issues/933#issuecomment-674414313
The timestamp is correct after switching apps or choosing something from the 3-dot-menu, e.g. "Überblick" or "Einstellungen"  and go back.

Hi @daimpi ,

I just checked (after 24 + 12h) w/o opening CWA
Unfortunately, still no update has been performed.
I checked now after almost 48h of not opening CWA since its last sync and still no update has been performed

and @heinosahling ,

Last background update still yesterday 09:46

that was not unexpected, but very frustrating, though :(
Thanks for your feedback anyway! <3
I guess, you also had already double checked settings provided by @ub6x in above comments here: https://github.com/corona-warn-app/cwa-app-android/issues/933#issuecomment-674530162 ,
and maybe, as the very last resort, also checked that CWA as well as Google Play Services have set notifications to '(high) priority' via settings > notifications > apps (or different pathway, depending on OS), if this might help in any way...
So, as I expect that CWA-Android-devs here also follow the (recently updated) best practices for background work, one can only tell:
Device manufacturers did a good job in preserving energy consumption by killing nescessary background activity...
I'm going out now. If someone asks, I'm on the way, gonna by me an iPhone...

Anyway, let's hope 1.2.0 has something so say about this :)

Since I gave quite a bit negative feedback before, here's some good news. My Huawei P30 shows the following checks, without me having opened the app in the last few days:

Aug 13, 8:33
Aug 14, 11:34
Aug 15, 11:38
Aug 16, 11:37
Aug 17, 11:39
Aug 18, 11:43
Aug 19, 11:41

So that seems to be working very nicely. Let's hope the notifications work as well once the risk status is not "low" ;)

I guess, you also had already double checked settings provided by @ub6x in above comments here: #933 (comment) ,
and maybe, as the very last resort, also checked that CWA as well as Google Play Services have set notifications to '(high) priority' via settings > notifications > apps (or different pathway, depending on OS), if this might help in any way...

@vaubaehn No: I intentionally didn't change any energy settings except for enabling PBA and confirming this via following the link in CWA to the energy settings (cf. my screenshot above). My idea was to replicate the experience a user who is not very technically inclined would have when using CWA.
But after finishing the last test I now installed a system update on the Redmi Note 7 and I now also checked more energy settings, and gave CWA permission for everything I could find. I then restarted the phone, and upon reboot it actually performed an update, w/o manually opening CWA or being connected to power. I will keep an eye on this and report back tomorrow whether this works reliably now 🙂.

Google improved the wakeUpService. It will take 3-14days until this change arrives on your phone. Unfortunately you cannot check whether your received this update. Please check again in the next days if the background task is more stable also without deactivating battery optimization

@thomasaugsten That's good to know and I will keep an eye on the other Xiaomi device which currently has "only" PBA enabled.
Given that there is no way to find out whether the update has been rolled out (ENF version is not indicative I guess), I would suggest that I run a dedicated test again, once the likelihood of rollout is reasonably high (maybe in a week or so). If you want me to run this test with any specific settings (e.g. PBA disabled) lemme know 🙂.

Hi @bersbersbers ,

Huawei P30 here. App version is 1.1.1, recommended settings applied in the app after the latest update. Never manually tinkered with battery settings anywhere. [...]
I have now applied the setting from #933 (comment) and will wait and see if that resolves the issue without having to open the app.

did the automatic updates magically start to work for you without 'tinkering' with any settings, except above mentioned?
Was there any update of CWA to version 1.2.x for you (either automatic or manually)?
Could you provide your ENF version number, please?
Do you remember if you restarted/booted your phone on Aug 14, aroubnd 11:30?

@daimpi

@vaubaehn No: I intentionally didn't change any energy settings except for enabling PBA and confirming this via following the link in CWA to the energy settings (cf. my screenshot above). My idea was to replicate the experience a user who is not very technically inclined would have when using CWA.

ok, I see :) :+1:

But after finishing the last test I now installed a system update on the Redmi Note 7 and I now also checked more energy settings, and gave CWA permission for everything I could find. I then restarted the phone, and upon reboot it actually performed an update, w/o manually opening CWA or being connected to power. I will keep an eye on this and report back tomorrow whether this works reliably now slightly_smiling_face.

:+1:

Here's the result of another test I was interested in that just has been finished.
I switched from (regular) background updates to a foreground update (by manually opening CWA) and then noticed what's happening with the background task. Would it
a) run in the next regular time slot ?
b) run in a new time slot calculated on the time of the previous foreground update + ~24 hours ?
c) forget to run ?
Good news : Everything happened as expected. The background update took place in the regular time slot.
The timeline now looks as follows :
15.08.2020 - 15:16 update by background start of CWA
16.08.2020 - 15:16 update by background start of CWA
17.08.2020 - 15:20 update by background start of CWA
18.08.2020 - 08:09 update by manually/foreground start of CWA
19.08.2020 - 15:21 update by background start of CWA
So in case you open CWA on a regular base (perhaps always in the morning) and then forget it for example during the holidays the background update will take over the task by next 48 hours.

@thomasaugsten

Google improved the wakeUpService. It will take 3-14days until this change arrives on your phone.

Would you say it's nevertheless worth to compile some positive/succeeding user reports for some devices from this issue as a kind of walkthrough for the websites FAQ? Or would it be strictly for the birds now? If you think it'll be helpful anyway, we could try and hand it over to you.

@vaubaehn

Huawei P30 here. App version is 1.1.1, recommended settings applied in the app after the latest update. Never manually tinkered with battery settings anywhere. [...]
I have now applied the setting from #933 (comment) and will wait and see if that resolves the issue without having to open the app.

did the automatic updates magically start to work for you without 'tinkering' with any settings, except above mentioned?

Yes, correct. I believe I remember that 1.2.0 came and did not immediately resolve it, but apparently it did in the meantime.

Was there any update of CWA to version 1.2.x for you (either automatic or manually)?

Yes, I have been getting 1.2.0/1.2.1 within 2-3 business days after they were tagged here.

Could you provide your ENF version number, please?

Sure:<PHONE_NUMBER>4

Do you remember if you restarted/booted your phone on Aug 14, around 11:30?

I don't remember, but current Android uptime is 169h56, which brings me to August 12, 2020, 03:06:38 PM. So I'd say I did not restart on Aug 14.

@vaubaehn

Huawei P30 here. App version is 1.1.1, recommended settings applied in the app after the latest update. Never manually tinkered with battery settings anywhere. [...]
I have now applied the setting from #933 (comment) and will wait and see if that resolves the issue without having to open the app.

did the automatic updates magically start to work for you without 'tinkering' with any settings, except above mentioned?

Yes, correct. I believe I remember that 1.2.0 came and did not immediately resolve it, but apparently it did in the meantime. (Also, #860 - I might have missed a check in that long list.)

Was there any update of CWA to version 1.2.x for you (either automatic or manually)?

Yes, I have been getting 1.2.0/1.2.1 within 2-3 business days after they were tagged here.

My guess : It's version 1.2.1 that caused the change.
I've installed Total Commander on my Huawei P20. The app can show you the installation date & time of the current CWA version. With this information you can check in detail which version of CWA was running at the time of the update.

@ub6x good guess!

My guess : It's version 1.2.1 that caused the change.
I've installed Total Commander on my Huawei P20. The app can show you the installation date & time of the current CWA version. With this information you can check in detail which version of CWA was running at the time of the update.

CWA 1.2.1 was installed on Aug 13, 19:51 - that is compatible with the hypothesis that installing 1.2.1. was the final ingredient to make daily background updates work.

With 1.2.1 we add the support of the wakeUpService from Google side. This should improve the background service on most of the devices. Google improved the wakeUpService yesterday to catch all devices. I would say if you have in 7 days still device with non working background exposure check you can report this devices here.

Hi Thomas @thomasaugsten

With 1.2.1 we add the support of the wakeUpService from Google side. This should improve the background service on most of the devices. Google improved the wakeUpService yesterday to catch all devices.

Is there some place to check on a particular mobile device if the Google improvement you mention is rolled out? Is there a certain minimum version of the Google Exposure Notification System or Google Play services to check for?

@MikeMcC399 There is no way because the improvement doesn't change any version number.

Strange behavior:

Phone was plugged most of the time since yesterday evening.
I was out and forgot to re-plug (~1 hour missing
until half an hour ago). Last background update still yesterday 09:46.
Must end test for today (and start cwa manually now), but will test tomorrow and Wednesday.

I startet cwa manually yersterday at 17:00.
In the morning I had to restart the mobile (because it didn't connect to my wifi) - first restart since a month or more.
A few hours later I realized that there was an update at 08:24. Exactly the time the mobile booted!
So it looks like background update may be able to work...
I will keep watching...

Today at 08:26 again background update!
Don't know what's the reason.
From a technical view: a LOT of testcases at the same time...
I will report what happens tomorrow, but I think for whatever reason the Honor View 20 ist fine now!

Strange behavior:

Phone was plugged most of the time since yesterday evening.
I was out and forgot to re-plug (~1 hour missing
until half an hour ago). Last background update still yesterday 09:46.
Must end test for today (and start cwa manually now), but will test tomorrow and Wednesday.

I startet cwa manually yersterday at 17:00.
In the morning I had to restart the mobile (because it didn't connect to my wifi) - first restart since a month or more.
A few hours later I realized that there was an update at 08:24. Exactly the time the mobile booted!
So it looks like background update may be able to work...
I will keep watching...

Today at 08:26 again background update!
Don't know what's the reason.

...
I think, you're using CWA 1.2.1 and - my guess - installation time of this version on your Honor View 20 is somewhere between 07:00 and 09:00 in the morning ?
@thomasaugsten
Seems that CWA 1.2.1 solves all open issues ;-)  . Well Done !

Strange behavior:

Phone was plugged most of the time since yesterday evening.
I was out and forgot to re-plug (~1 hour missing
until half an hour ago). Last background update still yesterday 09:46.
Must end test for today (and start cwa manually now), but will test tomorrow and Wednesday.

I startet cwa manually yersterday at 17:00.
In the morning I had to restart the mobile (because it didn't connect to my wifi) - first restart since a month or more.
A few hours later I realized that there was an update at 08:24. Exactly the time the mobile booted!
So it looks like background update may be able to work...
I will keep watching...

Today at 08:26 again background update!
Don't know what's the reason.

...
I think, you're using CWA 1.2.1 and - my guess - installation time of this version on your Honor View 20 is somewhere between 07:00 and 09:00 in the morning ?
@thomasaugsten
Seems that CWA 1.2.1 solves all open issues ;-) . Well Done !

I think it is yesterday's reboot, see quote above and not CWA 1.2.1.
But (you forgot to quote 😎)

From a technical view: a LOT of testcases at the same time...
I would bei glad to know what's the reason, but is it worth it?

¯_(ツ)_/¯

@thomasaugsten
Seems that CWA 1.2.1 solves all open issues ;-) . Well Done !

No it doesn't. It still DOES NOT work on my Xiaomi. I just opened the App manually, because the last risk Update that was made was on Monday. And I also have the 1.2.1 Version installed.

We know there are still issues on Xiaomi device this will be resolved in the next days without any user interaction because of the improvement of the wakeUpService.

@thomasaugsten

With 1.2.1 we add the support of the wakeUpService from Google side.

Just out of curiosity, is that a change in the build system? Because from the GitHub tags (and also the Play-Store release notes, by the way), that change is not visible. Compare 1.2.1 vs. 1.2.0
https://github.com/corona-warn-app/cwa-app-android/compare/1.2.0...1.2.1
and see the Play-Store text:

This update provides improved texts.

The adaption of the wakeUpService was implemented in 1.2.0. The current version is 1.2.1. Which include the adaption as well.

@thomasaugsten

The adaption of the wakeUpService was implemented in 1.2.0. The current version is 1.2.1. Which include the adaption as well.

Oh, I see. I was asking because the installation time of 1.2.1 coincided perfectly with the onset of near-exact 24h intervals between update checks on my P30. But I had installed 1.2.0 earlier, I want to say a day or two, so maybe it was just a coincidence with the ENF being updated around the same time as I upgraded to 1.2.1. So, sorry for the noise and thanks for your hard work - problems seem to be fixed for me apparently :)

Hi Thomas @thomasaugsten

There is no way because the improvement doesn't change any version number.

Firstly, my apologies for asking a question which you had already answered!
Secondly, great news that Google is making improvements!
Thirdly, I'm surprised that Google is making functional changes without changing a visible version number. This is detrimental to good solution support. (See for instance https://en.wikipedia.org/wiki/Software_versioning#Significance_in_technical_support). Did Google explain why they didn't change the version number?

Because is a configuration change not an implementation change. This means when no code is changed there is no change in the version number possible.

Update: On the Xiaomi Redmi Note 7 (with Android 10 now) - which is the device where I manually exempted CWA from all energy savings - an automatic background update was performed today at approximately 14:30.
On the Xiaomi Redmi 5 Plus (Android 8.1) which has "only" PBA enabled, no update has been performed for the last two days, but I will keep an eye on this :)

i have the xiaomi mi 8 android 10. and it was patchy. now i know what buttons what. there is an app to show hidden "pixel" settings.
hidden settings for miui
xiaomi battery settings exemt CWA, first switch all options on.
battery optimization off and in app settings , also hidden miui, there is the original battery optimization and PBA i guess. had the same issue with strava.
thx will watch updates +24h

@thomasaugsten

With 1.2.1 we add the support of the wakeUpService from Google side. This should improve the background service on most of the devices. Google improved the wakeUpService yesterday to catch all devices. I would say if you have in 7 days still device with non working background exposure check you can report this devices here.

Report:
7 further days, still no improvement, so frustrating....
Device: HUAWEI P30 lite - Android 10 - CWA 1.2.1 - ENF<PHONE_NUMBER>4

Update: On the Xiaomi Redmi Note 7 (Android 10) - which is the device where I manually exempted CWA from all energy savings - automatic background updates are working smoothly.
On the Xiaomi Redmi 5 Plus (Android 8.1) which has "only" PBA enabled, updates still only work when manually opening the app, but I will keep an eye on this :)

I just checked again and the situation hasn't changed: On the Xiaomi Redmi Note 7 (Android 10) - which is the device where I manually exempted CWA from all energy savings - automatic background updates are working smoothly.
On the Xiaomi Redmi 5 Plus (Android 8.1) which has "only" PBA enabled, updates still only work when manually opening the app, but I will keep an eye on this :)

Thanks @daimpi for the update
Sascha
Corona-Warn-App Open Source Team

checked again, still shows updates older than 2 days but i noticed newer files in Android/data/de..warnapp/cache directory, so it is running? (user accessible ssd  path)

checked again, still shows updates older than 2 days but i noticed newer files in Android/data/de..warnapp/cache directory, so it is running? (user accessible ssd path)

hi @msagebiel , that may indicate, that diagnosis keys from server are downloaded (if the new files are actually diagnosis keys), but then they're not matched / matching failed. Could you provide the names of the newer files?

checked again, still shows updates older than 2 days but i noticed newer files in Android/data/de..warnapp/cache directory, so it is running? (user accessible ssd path)

hi @msagebiel , that may indicate, that diagnosis keys from server are downloaded (if the new files are actually diagnosis keys), but then they're not matched / matching failed. Could you provide the names of the newer files?

need to check in 2 days. one folder in cache /ubq cache.db cache.db-journal
app id user and everybody group. three hash named files 25k 1.1k 320 byte
all 5 files were new. check folder and start app on wed.

@jakobmoellersap and @thomasaugsten
Case numbers are increasing seriously, there is still only manual update, no automatic update on Huawei devices.
When will this be fixed?
Device: HUAWEI P30 lite - Android 10 - CWA 1.3 - ENF<PHONE_NUMBER>4

Serveral tech portals write about a small update for some huawei devices.
e.g.: https://www.teltarif.de/huawei-corona-warn-app-update/news/81874.html
The p30 lite isn't listed there - but it seems to be an issue which needs to be solved due the manufactor

@speedy-1702 @gusowski1 thanks for your additional feedback. I have taken a look at your blog article and added this information to the existing Jira Ticket. The issues with Huawei P30 are known by our development team and they are working on resolving the issues related to this device.
Best regards,
SG
Corona-Warn-App Open Source Team

I just checked again and the situation has changed: On the Xiaomi Redmi 5 Plus (Android 8.1) which has "only" PBA enabled (no other energy settings changed), updates now work flawlessly at least since the 7th September and maybe even before that (6th September was missing from the log, but other than that all checks have been performed since August 31st).
It seems the issue has been resolved there 😊.

ENF log: log-13.zip

@daimpi,
thats good news, thanks for letting us know :thumbsup:
Best regards,
ABB
Corona-Warn-App Open Source Team

Good news also from my side for Huawei users.
Since a couple of days, Huawei published update <IP_ADDRESS>0.
Since this installation, there is a daily background update on my P30 Lite.
I am not sure if this was the knot loosener. It would be good to know, if other Huawei user are experiencing the same.
Another point would be to check, when exactly CWA is starting or stopping in background and whether the wake up service has caused the start. Who can help to find out?

Problem with Huawei p20 lite since yesterday

@speedy-1702

Since a couple of days, Huawei published update <IP_ADDRESS>0.
Since this installation, there is a daily background update on my P30 Lite.

After Huawei white listed CWA to be allowed being ignored from battery optimizations, it now should run most likely without problems.
Sad, that the system update seems to be availale for EMUI 10 and devices for European market only.

Another point would be to check, when exactly CWA is starting or stopping in background and whether the wake up service has caused the start. Who can help to find out?

If you check the Exposure Matching History via Android > settings > Google > Covid-19-notifications > Exposure history, you will easily see, if the background update is reliably done (started) always at the same time.
If you force stop CWA via Android > apps > CWA > force stop, you will notice from the exposure history, that CWA was started again by the wake up service the next day. If it's the same time like the days before, it's more likely that wake up service started background update also before.

After a day by day update streak, today the background update failed.
It seems, that the problem is not yet solved.

@vaubaehn are you testing with Huawei devices in your test lab?

Hi @speedy-1702 ,
I'm very sorry to tell, but neither I'm a developer for SAP/T-Systems, nor associated with any of the stakeholders in any way.
I'm just a little bit overidentified user, who believes in the idea of digital contact tracing (knowing its limitations, though), and who has quite fair skills in IT and health assessment. By volunteering here, I'm feeling to 'give back' something to the community, that we all live in.
However, I'm careful about my statements, and they're usually based on facts.
That Huawei white listed CWA is taken from -> here  . The blog owners obviously have a direct connection to Huawei, and have been informed by Huawei about the reason for the system update (you can find some detailed information of blog owners reading in the comments below the announcement).
Other information I gave here is compiled by many user reports (that could have been validated in most cases), or is based on my own experiences arising from some problems and/or experiments.
Much of my motivation and engagement here is also related to the many problems of the Android version of CWA that became visible after its first release. It's a pity that many people facing sometimes severe flaws are giving up on using CWA, hence not being able anymore to fight the pandemia by digital contact tracing. In my opinion the developers are not to blame, because most of the problems have not been forseeable at the start of this large scale contact tracing expriment using a quite new technological approach.
So I'm trying to compile as much information as possible regarding to bugs and flaws, condense them, and try to deliver them (directly or indirectly) to the persons assigned with an issue or to developers who seem to work on a special problem, in order to speed up the process of fixing as much as possible, taking into account that they sometimes may feel a bit annoyed. Every single day, a fix may be provided more early, is a day that prevents frustrated users to uninstall CWA, thus increasing the likelihood to see a positive effect with regard to digital contact tracing.
That being said, let's get back to work:

After a day by day update streak, today the background update failed.
It seems, that the problem is not yet solved.

It's hard to tell, if your problem is originated in battery optimization, or if 'something went wrong' in any other way.
To analyze the problem, would you like to provide your Exposure Matching History here? You can export it via
Android > settings > Google > Covid-19-notifications > Exposure history > 3-dot menu up-right > export.
Then we would need to know, how was your phone usage during the last day(s) -> Do you shut down your phone during the night time? If not, was it connected to a power charge (to prevent doze mode, that prevents CWA to run immediately after called by wake up service -> own experiment)? How often was your phone on charge during day time? If you shut down your phone during the night (or daytime), at what time did you start again (that information would help in analysis of exposure matching history)?

@GeoCha84 and before it worked well, without issues.
Including background update?

Hello speedy,
After forcing the CWA to stop in the smartphone settings and restarting the smartphone, the daily updates runs smoothly. I have changed nothig else.
It has been 5 days now. Thank you all fir the help.
To answer your question, yes before it had been working well sincw day 1.

A similar issue was reported for the OnePlus 5T: https://github.com/corona-warn-app/cwa-app-android/issues/1241

Corona-Warn-App Open Source Team

Unfortunately, when opening the app an error ("Ursache 3") pops up, saying that the determination of risk is fully functional but the state of risk cannot be refreshed (last time yesterday, 6:05AM)
Background updates etc are enabled.
I usually open the app at least every two days, this is the first time the error popped up.
Smartphone: Samsung Galaxy A41 (Android 10)
App-Version: 1.3.1
Thanks for checking in!

@az1-cell
It sounds like you have the issue CAUSE: 3 Something went wrong. ApiException: 39508 https://github.com/corona-warn-app/cwa-app-android/issues/1021 which has been inadvertently closed. Hopefully @GPclips will get it re-opened, and you can follow the progress there.

Good news: the app is fully functional again without further measures!

@az1-cell

Good news: the app is fully functional again without further measures!

That's nice! If you were encountering the error 39508 FAILED_RATE_LIMITED it happens if the quota is exceeded.
Google API modes documentation says
provideDiagnosisKeys quota  20 per day over all tokens (counter resets at 00:00 UTC) for V1 mode
i.e. it resets at 02:00 CEST local German summer time.
The FAQ gives some additional background information about error 39508.
Your problem could occur again depending on the underlying reason for the failure. Issue https://github.com/corona-warn-app/cwa-app-android/issues/1021 has been re-opened to follow the resolution of this problem (hopefully very soon in the planned version 1.4.0)!

🔥 Hot Topic Update 🔥
We are discussing this issue on regular basis as its currently one of our high priority tasks.
The latest feedback is:

ForegroundService is being implemented with the CWA release 1.4
Other Tickets might depend on ForegroundService

Developer Notes:

Subtask #1 & #2 (Dev / DeviceTests) have shown that the use of POC/ForegroundService is clearly recommended, especially for problematic devices. The usage improves background reliability even for the "worst devices" (like Huawei P20). Different testscenarios have been executed on 7 different devices. To have higher guarantees more device test from all manufactures would be neccessary, but the results are sufficient in principle.
The usage of ForegroundServices wakes the CWA App and gives higher priorization to the CWA BackgroundWorker, what can be desginated as welcome.
Note 1: The usage of ForegroundServices requires a short notification (mandatory), but only as long as the backroundjob (key retrieval) is done.
In every day life this means a short notification will appear (and disappear after 1-4 seconds automatically) approximately 4-5 times a day (on current code base).
This notification is not essentially a disadvantage and can be used to keep the App-User updated (e.g. "Daten werden aktualisiert").
Note 2: An example (picture) how this notification could look like is attached in the comments (to be discussed with UI/UX team).

Best regards,
SG
Corona-Warn-App Open Source Team

@svengabr

Subtask #1 & #2 (Dev / DeviceTests) ...

The links to the subtasks don't seem to be relevant to the topic. Perhaps something went wrong when pasting the text in?
It will be great in any case to see the background update issue solved for the difficult devices. For me it's already working reliably on my Samsung Galaxy A50 for quite some time.

Dear @svengabr ,

:fire: Hot Topic Update :fire:
The latest feedback is:
Developer Notes:

giving these kind of information is really, really nice and very appreciated! Transparency helps very much for motivation and increasing the acceptance of the app, imho. Even if things aren't going too well or there are some delays for whatever reasons, being informed helps to stay patient and eases us to support the devs emotionally ;)
Thank you!
@MikeMcC399

Subtask #1 & #2 (Dev / DeviceTests) ...

I think it's an github issue, trying to make a link out of everything that is a hashtag followed by any number :)

@vaubaehn

Subtask #1 & #2 (Dev / DeviceTests) ...

I think it's an github issue, trying to make a link out of everything that is a hashtag followed by any number :)

I'm sure you're right. So # needs to be escaped with \ character i.e. \# instead of just # to stop an automatic link being generated.

@MikeMcC399

So # needs to be escaped with \ character

Didn't know that yet - thanks for the hint!

@daimpi we see some progress on Xiaomi device can you confirm this that Xiaomi device without prio background starts a background task?

@thomasaugsten I currently have no Xiaomi device around as I'm staying at my gf's place, but I will see whether I can investigate… I'd ask the Xiaomi Redmi 5 Plus owner to disable PBA and report back in a few days… would this test be helpful to you?

@daimpi yes this sounds good

@thomasaugsten I already got some potentially interesting information:
I enabled PBA on their device (Xiaomi Redmi 5 Plus) over a month back but when they checked today, PBA was disabled again w/o any action from the owners side (dunno when or by what it got disabled).
This is how their ENF log looked like today:

Timestamp
Sum of Checks

02.10.2020 11:52
14

29.09.2020 18:48
14

28.09.2020 16:40
14

27.09.2020 12:53
14

24.09.2020 07:52
14

23.09.2020 14:46
14

21.09.2020 10:16
14

20.09.2020 14:47
14

19.09.2020 14:12
14

17.09.2020 07:16
14

Total
140

The good news is that the checks today were performed without opening CWA manually, the phone was only used for some other tasks at some point today.
They also said that they manually opened CWA ~2 times this week. Given the large gaps in their ENF log, I'd say CWA without PBA hasn't been working reliably in the background for them during the timeframe of their log…
I told them to leave PBA disabled and not to open CWA till Monday at which point I'll get back to you with an updated log 🙂.

ENF v.<PHONE_NUMBER>5
Log file: log-02.zip

Sony Xperia e5 same Problem since 26th September. Tried to restart and everything Else recommended in the FAQ. Version 1.3.1

@thomasaugsten I today received an update and I'm cautiously optimistic that the background checks are now working on the Xiaomi Redmi 5 Plus even without PBA. The last time CWA was opened on this device was on Friday, Oct 2nd and I received a new log file today (05.10.2020 20:20) which shows that automatic background checks were actually performed on Saturday & Sunday:

Timestamp
Sum of Checks

04.10.2020 22:55
14

03.10.2020 11:27
14

02.10.2020 11:52
14

I'll keep an eye on this and report back at the end of the week whether this trend turns out to be reliable.

Log file: log-05.txt

@thomasaugsten I received another update today (07.10.2020 22:30) and there is one set of checks missing over the past few days: on Monday 05.10.2020 no checks were performed:

Timestamp
Sum of Checks

02.10.2020 11:52
14

03.10.2020 11:27
14

04.10.2020 22:55
14

06.10.2020 19:55
14

07.10.2020 10:01
14

Other than that all checks were performed even though CWA was never opened and PBA is disabled. I'll keep an eye on this and will report back at the end of the week.

Log file: log-07.txt

Keine Aktualisierung des Risikostatus:
Samsung S5mini, Android 6.0.1, corona-warn-app 1.3.1, kein Energiesparmodus, Akku-Freigabe.
Trotzdem keine Aktualisierung des Risikostatus möglich seit 7 Tagen.
Fehlermeldung:
"URSACHE: 3
Etwas ist schiefgelaufen.
Ursache:
com.google.android.gms.common.api.ApiException:
39508:
at
android.support.v4.media.MediaDescriptionCompatApi21$Builder.
setResultOrApiException(MediaDescriptionCompatApi21.java:3)
at
com.google.android.gms.internal.
nearby.zzaf.onResult(com.google.
android.gms:play-services-nearby@@18.0.3-eap:5)
at
com.google.android.gms.common
.api.internal.IStatusCallback
$Stub.zaa(com.google.android.gms:play-services-base@@17.3.0:2)
at
com.google.android.gms.internal.base.zaa.onTransact
(com.google.android.gms:play-services-base@@17.3.0:3)
at
android.os.Binder.execTransact(Binder.java:453)
"
Was kann ich tun?

@jochsch Das Github Issue für das Problem das bei dir auftritt, findet sich hier: https://github.com/corona-warn-app/cwa-app-android/issues/1021
Da das Problem bei dir bereits über mehrere Tage hinweg besteht, kannst du vll. mal ausprobieren was ich hier geschrieben habe und schauen ob das hilft.

@thomasaugsten I received another update today (11.10.2020 23:10) from the Xiaomi Redmi 5 Plus (without PBA) and more checks have been missed since then:

Timestamp
Sum of Checks

02.10.2020   11:52
14

03.10.2020 11:27
14

04.10.2020 22:55
14

06.10.2020 19:55
14

07.10.2020 10:01
14

08.10.2020 10:05
14

09.10.2020 15:08
14

No checks were performed on Saturday or Sunday additionally to the ones missing from Monday. It seems WakeUpService on it's own is not working fully reliable yet.

Log file: log-11.txt

Background update doesn't work
Sony Xperia F3311
Screenshot error message (type 3): https://we.tl/t-CxC8SJ2ijt
Version 1.3.1

@mandinga90  the problem you're experiencing (Ursache 3: API 39508) is being tracked in this issue: https://github.com/corona-warn-app/cwa-app-android/issues/1021.

Could you please update the app to the latest version 1.5 and check if the problems are gone for you?

Just a short info concerning my Huawei P20.
For two days background update works fine again. Prioritized Background Activity (PBA) is activated but no additional setting related to Huawei's method to reduce energy consumption has been made.
Huawei P20
Android-version 10
EMUI-version 10.0.0
CWA version 1.5.0
ENF version<PHONE_NUMBER>0
CWA 1.5.0 was installed on Tuesday (20.10.2020). I don't know the exact update time of the new ENF version. but it must have been after updating to CWA 1.5.0 .
The device was not restarted for 63 days.
It would be interesting which update is responsible for the change - CWA or ENF or both of them.

@traut21 is reporting that the problem is still present on Redmi 9 with PBA enabled:

Android 10
CWA 1.5.0
ENF<PHONE_NUMBER>0

Could you please update the app to the latest version 1.5 and check if the problems are gone for you?

Does that mean the ForegroundService method mentioned in https://github.com/corona-warn-app/cwa-app-android/issues/933#issuecomment-702158318 is landed in version 1.5? Couldn't find the required permission in the manifest.
Thank you.

I'm on 1.5.0, setup named above.

Just a short info concerning my Huawei P30 lite.
Since Oct, 20th, the background update works fine again. Prioritized Background Activity (PBA) is activated but no additional settings regarding energy options have been made.
Android-version 10
EMUI-version 10.0.0
CWA version 1.5.0
ENF version<PHONE_NUMBER>0
However, interesting is, that the update is not always performed within the mentioned 24hrs (+4)
span of time. Sometimes after 24(+6) or even after (24+17), but always within the following day.
IMAO this is not critical.
All in all, the issue seems to be solved. Many thanks to the developers from SAP and Google for this tremendous effort.
What about the other devices reported here?
Best regards

Dear community,
In order to follow up and monitor the issue: Are there any new reports regarding this issue with the actual CWA version?
Best wishes,
DS
Corona-Warn-App Open Source Team

Still not working on my Redmi 9

Dear @traut21, thanks for your post. Please confirm, that you refer to this specific problem: https://github.com/corona-warn-app/cwa-app-android/issues/1081#issuecomment-716178131 and that you ave updated to Version 1.6.0. Thanks

I wouldn't know how to seperate those issues from each other. Both seem to apply.
Yes, I'm on CWA 1.6.0

Updates are not processed automatically, but only when I do check manually.

Hi @traut21,
in an upcoming version of the CWA, the updates should be performed several times per day. This should then solve the issue you are experiencing.
Best wishes,
DS

Corona-Warn-App Open Source Team

I hope so. I do not see any improvement with CWA 1.6.1 yet.
Several Times per Day was also named by Minister Spahn in
https://www.spiegel.de/politik/deutschland/corona-krise-jens-spahn-will-corona-warn-app-nachbessern-a-597693ee-0a5b-4763-89cb-01f5e376ebbe
This article names, that only about 2200 people per day confirmed their positive test, which would be about 10 % of the daily infections.
There have been about 22.4 Mio downloads, the article claims. Does the server accesses permit a tracking, how many different installations actually are in use, or do work at all? Personally, I downloaded the app at least 10 times, always hoping for a working version.
Many people have uninstalled the app again because it does not work as desired:
"In einer aktuellen Umfrage von infratest dimap sagten 44 Prozent der Befragten, dass sie die App nicht heruntergeladen hätten und dies auch nicht planten. Fünf Prozent erklärten, sie habe bei ihnen nicht funktioniert. Vier Prozent gab an, sie hätten sie wieder gelöscht."
The app is based on the knowledge of this years spring, but not on the currently known status - and no one seems to know whether and when Apple, Google or the manufacturers' android versions will receive necessary updates.

@traut21

Does the server accesses permit a tracking, how many different installations actually are in use, or do work at all?

Here you can find some estimations from August:

80% of downloaded CWA are active

Also: feel free to upvote https://github.com/corona-warn-app/cwa-wishlist/issues/236 🙂.

Here you can find some estimations from August:

80% of downloaded CWA are active

But these are just random estimations? Server accesses might provide much more detailed numbers - not only for august, but for this and any other week.

I do not see version 1.7.0 yet.
So there's still the problem with 1.6.1:

when starting the app, it tells me it will check the status. This will tak only a few seconds

After that, it will show the status of yesterday - or the last time I checked. Why that? It should have the current status!

When I click the green area, it will show me the actual lookup status

Only then, after I go back, or when I do restart the app, it then will show me the actual (or soon to be outdated) status

So

the shown status is still wrong
and apart from that the background update still does not work

Dear community,
Thanks for contributing here. Regarding the update to CWA 1.7.1 (for both iOS and Android): Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.
We would appreciate very much your feedback regarding this issue over the next few days!
Best wishes,
DS

Corona-Warn-App Open Source Team

@dsarkar

Regarding the update to CWA 1.7.1 (for both iOS and Android)

Isn't the new version of CWA Android 1.7.0 not 1.7.1?
I think it is only CWA iOS which has a version 1.7.1.

Regarding the update to CWA 1.7.1 (for both iOS and Android): Please note that it is a staged rollout. Over the next two days, 100% of the users should have received the update.

What's a staged rollout - there's a 1.7.1 before there's a 1.7.0 around?

1.7.1 for Android will be available very soon
Best wishes,
DS

Corona-Warn-App Open Source Team

@dsarkar

Version 1.7.1 for Android will be available very soon.

I'm surprised then that there is no 1.7.1 release candidate in https://github.com/corona-warn-app/cwa-app-android/releases . Do let us know if you have any more concrete news about an Android 1.7.1 release.

For the moment 1.7.1 finally seems to work, as it always should have been.
Automatic update is shown directly when I open the CWA.
Android 10 on Redmi 9

Dear @traut21 and community, thanks for the feedback. We monitor a few more days this issue, and if appropriate, we will finally close it.
Best wishes,
DS

Corona-Warn-App Open Source Team

I'm not sure to follow this issue or to create a new one. Please let me know if I'm doing wrong.
My app stopped updating and the last update occurred more than 48 hours ago. Android10 on Samsung Galaxy A6 with app V1.7.1. It's complaning "Risiko-Ermittlung nicht möglich" but "Risiko-Ermittlung" is active. I didn't change any settings, but I can'T remember when the app was updated.

I'm not sure to follow this issue or to create a new one. Please let me know if I'm doing wrong.
My app stopped updating and the last update occurred more than 48 hours ago. Android10 on Samsung Galaxy A6 with app V1.7.1. It's complaning "Risiko-Ermittlung nicht möglich" but "Risiko-Ermittlung" is active. I didn't change any settings, but I can'T remember when the app was updated.

Check for issues #1081 or #1304. Bluetooth is active? Battery optimization for this app is off?

Bluetooth is active. Batterie optimization for the app is off.
Today it looks different: It looks as usual means "Risiko-Ermittlung nicht möglich" is gone as well as "Risiko-Ermittlung einschalten". Only the hint "Aktualisiert: 30. Nov. 12:26" still indicates an issue.

I just forced to stop the app again and after restarting it has updated.

Dear @R-Sommer,
Thanks for reporting. Are you able to reproduce this issue? Please, send some feedback over the next few days. Thanks.
Best wishes,
DS

Corona-Warn-App Open Source Team

After getting positive feedback from all channels I will consider this issue as resolved. If there are any follow up topics appearing, please create a new issue.

Dear @R-Sommer,
Thanks for reporting. Are you able to reproduce this issue? Please, send some feedback over the next few days. Thanks.
Best wishes,
DS
Corona-Warn-App Open Source Team

I wasn't able to reproduce this issue. Everything fine since then.

Hi @R-Sommer! Thanks for the feedback! Best regards, DS

Corona-Warn-App Open Source Team