Cwa-app-ios: Background Actualization of IDs only when App is started

[gigiCom]

Background Actualization of IDs only when App is started.zip

Avoid duplicates

• [X] Bug is not mentioned in the FAQ
• [X] Bug is not already reported in another issue

Describe the bug

The actualization of the risk, i.e. of the IDs that are present on the server, does only happen if the app is started and not if the app is closed.

This contradicts the published statement that the app does actualize in background.

This behavior means that persons who have installed the app, closed it and don't open it anymore, will never get informed about potential critical Corona contacts in the past, because the system does not download the risky IDs at all.

Only if the app gets started or if the app remains started (in the background), the IDs get downloaded. But not if the app is closed.

I have the background actualization switched on (see attachment), and I attached a video that shows (in slow motion) that I have actualized my IDs yesterday at 8:59. Today, I start the app at 10:40 and see immediately that the time stamp in the green risk panel switches from 8:59 to 10:40. I reproduced that behavior on my iOS phone 2 times in the last days and also 1 time on another iOS phone. On Android phones, this all seems not to occur.

If one lets the app open in background, this behavior does not occur, the IDs get updated in the background as expected, e.g. every day at 8:59.

Expected behaviour

The app should do the ID update in the background even if the app is closed, this is the expected and communicated behavior to the public, and it is the behavior on Android phones.

Steps to reproduce the issue

• start the app and verify the latest actualization time stamp in the (green) risk panel, e.g. _today, 8:59_
• close the app, don't send it in in the background, close it completely
• wait until the next day after 8:59, e.g. 10:40
• open the app
  -> one sees that the time stamp changes from _yesterday, 8:59_ to _today, 10:40_

see attached video.

If the app remains started (even in the background), and you bring it to the foreground the day after at 10:40, you see the time stamp shows _today, 8:59_.

Technical details

• iOS Version: 13.5.1
• Device: iPhone XS

---

Internal Tracking ID: EXPOSUREAPP-1832

[marcelkliemannel]

I am experiencing the same problem with iPhone 7 and iOS 13.5.1 and I checked that the app is allowed to run in background.

When I started the app yesterday at around 6 o'clock I got the message "Updated: Yesterday, 06:50". When I started it again at 7:20, the message changed to "Updated: Today, 7:20". Today the same: I started the app around 6 o'clock and I got the message "Updated: Yesterday 7:20". I started it at 10:08 again and then the message jumped to "Updated: Today: 10:08". This indicates that no automatic update has been performed.

This behavior also means that the check interval, which was supposed to be 24 hours, became longer and longer every day. If I don't open the app tomorrow at 10:08 but at 12:00, it can only be updated the following day after 12:00...

[danielburkard]

The problem is that the developer decided very early against pushing updates through silent notifications. Running background tasks on iOS is very limited. Especially if the user doesn’t use the app regularly.

[Gorilla89]

Same problem here (iOS 13.5.1) with new iPhone SE. It seems the risk is only updated once the app is started (which will happen only rarely...) I think this has to be fixed urgently as the whole concept doesn‘t work when there is no background update.
On my an iPhone X it’s even worse: risk calculation is active, however not possible as it couldn‘t be updated for more than 24 hours according to the message on the screen

[ay-kay]

Since yesterday the first diagnosis keys are available now, however, my app has not updated since yesterday morning and my exposure log has not been checked. So this is a whole day that I was not warned of possible exposures and could possibly have infected many more people. After the release of new keys the checks should be triggered as soon as possible, which is not possible with the fetch background mode that gives an app execution time at irregular intervals only, and only very rarely, if the app is not actively used.

Either Apple can make an exception for Corona Warn Apps and schedule the execution more often, or Silent Push Notifications would be appropriate. This would allow the checks to be carried out promptly, which I urgently consider necessary here.

As an interim solution, is there a way to trigger the exposure check each time the app is started, or at least manually?

[kamil98]

Since yesterday the first diagnosis keys are available now, however, my app has not updated since yesterday morning and my exposure log has not been checked. So this is a whole day that I was not warned of possible exposures and could possibly have infected many more people. After the release of new keys the checks should be triggered as soon as possible, which is not possible with the fetch background mode that gives an app execution time at irregular intervals only, and only very rarely, if the app is not actively used.

Either Apple can make an exception for Corona Warn Apps and schedule the execution more often, or Silent Push Notifications would be appropriate. This would allow the checks to be carried out promptly, which I urgently consider necessary here.

As an interim solution, is there a way to trigger the exposure check each time the app is started, or at least manually?

Hi, I’m having the same issue.

I installed the app 8 days ago and and my exposure log wasn’t checked yet.

[JThoennes]

In addition, I tend to run my iPhone 11 Pro with iOS 13.5.1 mostly in power save mode. Therefore, I would guess that the app does not update in the background. Is that true? Could that be possibly be changed?

[BastianZim]

Is that true?

I checked it on my iPhone with no power-saving and the result is the same, so I don' think that it is related to that.

[crumbach]

Same problem here on a Pixel 4XL, Android 10. If app is opened after more than 24 hours since last opening, it first shows an "unknown risk status. You are not using the app long enough yet.". Then and only then, the update is performed and all information is correct again.
I was able to reproduce on a second device (OnePlus 3) and attach a video thereof.
unknownRisk.zip

Note: this only occurs since the last update of the app three days ago.

[sysfyg]

Same problem here on a Pixel 4XL, Android 10. If app is opened after more than 24 hours since last opening, it first shows an "unknown risk status. You are not using the app long enough yet.". Then and only then, the update is performed and all information is correct again.
I was able to reproduce on a second device (OnePlus 3) and attach a video thereof.
unknownRisk.zip

Note: this only occurs since the last update of the app three days ago.

Could it be related to CWA-server release 3 days ago?

[ferdinand]

Since I open the app regularly after 24 hours, I can’t tell if I‘m affected as well. But when I told somebody on Twitter that the Background App Refresh doesn’t work with activated Low Power Mode, I received several replies from people, who never use the Low Power Mode, complaining as well about the app not doing the check automatically.

I‘m aware that at some point iOS should run the background task and they‘re probably just not patient enough, but besides the fact that users should receive the warning as soon as possible it’s also an user experience issue if users don’t trust in the app working automatically.

[PalminX]

I can confirm this behaviour (background updates of exposure check not running unless the app is opened) on iOS 13.5.1.

This is unrelated to things like Low Power Mode. I am seeing this for other apps which use BGProcessingTaskRequest, even though the requests are scheduled, it is not guaranteed that iOS will honor them.

[danielburkard]

This years WWDC included some related session:
Background execution demystified

[mss1010]

I can also confirm this issue on an iPhone XS with iOS 13.5.1
On this screenshot from today you see, that the IDs were last downloaded the day before yesterday. So, yesterday, nothing was downloaded at all. Only when I started the app manually, it downloaded the IDs.

I had all background related settings active and also had no battery saving mode active. To me this seems like a really serious issue, because this will mean for most users who just install the app, and don´t open it again, the app will never download any IDs. So, the whole concept does not work at all!

Might be that this is due to the limitations by Apple related to background tasks, but I think this should be analyzed with a high priority. My guess is, that the whole concept does not work at all for the majority of users.

@tkowark Can someone from the developers please comment?

[tens0rfl0w]

Can confirm this behavior after several days of testing. Only worked once on the first day a data set was published. No visible log errors regarding background execution or time rule breaking.

13.5.0, iPX, no power saving mode activated

[Kljcjbjj]

I have the same Problem: only by starting the app the keys are downloaded and checked. They are not updated in the background.

I tried it with activated and deactivated power saving mode on several devices:

iPhone 6S
iPhone 7

iOS 13.5.1

[PalminX]

I don't consider myself an expert on this, but I have contributed to a project which also used BGProcessingTask, and looking at ENA/ENA/Source/Models/Task%20Scheduling/ENATaskScheduler.swift, I have some remarks. Hopefully, some devs could look into this:

• Usually, in BGTaskScheduler.shared.register(), the task is cast to the appropriate BGTask subclass, i.e. here BGProcessingTask

               BGTaskScheduler.shared.register(forTaskWithIdentifier: identifierString, using: .main) { task in
            taskHandler(task: task as! BGProcessingTask)
        }

• The BGProcessingTask should have an expirationHandler, in order to terminate/clean up as fast as possible once notified by the scheduler, see expirationHandler. Apps might be punished insofar as BGProcessingTaskRequests might be honored less often if they do not terminate the BGTasks fast enough.

As I said, I am not an expert, and I can't be sure that this is relevant, this is just what I noticed as odd

[pkreissel]

Ok I checked this Bug with several phones. Some people hadn't opened the app since they installed it on day 1, and they had NO "Kontaktüberprüfung" AT ALL in their logs. It only showed the current keys after they opened the App. This is really really bad.

[JThoennes]

    I  actually wonder whether the developers use this app on their own iPhones - eat your own dog food. If you watch carefully this could have been noted and reported shortly after launch. Still waiting for any official feedback - or did I miss anything? Time for a patch release...

On Mon, Jun 29, 2020 at 8:42 PM +0200, "Philip Kreißel" [e-mail] wrote:

Ok I checked this Bug with several phones. Some people hadn't opened the app since they installed it on day 1, and they had NO "Kontaktüberprüfung" AT ALL in their logs. It only showed the current keys after they opened the App. This is really really bad.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[mss1010]

If the developers will not react and comment within the next 2 days, I guess we should inform media sites that the app is basically disfunctional.

[inf2381]

If the developers will not react and comment within the next 2 days, I guess we should inform media sites that the app is basically disfunctional.

You are of course free to inform whoever you see fit about this issue. But keep in mind that the app is only facing issues in a small set of edge-cases, we are already investigating this issue (as visible by the assigned status) and we have other issues with higher priority (e.g., the unexpected error codes from the system which we have to investigate together with Apple).

[haosap]

Since yesterday the first diagnosis keys are available now, however, my app has not updated since yesterday morning and my exposure log has not been checked. So this is a whole day that I was not warned of possible exposures and could possibly have infected many more people. After the release of new keys the checks should be triggered as soon as possible, which is not possible with the fetch background mode that gives an app execution time at irregular intervals only, and only very rarely, if the app is not actively used.
Either Apple can make an exception for Corona Warn Apps and schedule the execution more often, or Silent Push Notifications would be appropriate. This would allow the checks to be carried out promptly, which I urgently consider necessary here.
As an interim solution, is there a way to trigger the exposure check each time the app is started, or at least manually?

Hi, I’m having the same issue.

I installed the app 8 days ago and and my exposure log wasn’t checked yet.

Hi @kamil98 ,
Thanks for reporting this bug. I guess your situation might be related to: https://github.com/corona-warn-app/cwa-app-ios/issues/759 and https://github.com/corona-warn-app/cwa-app-ios/issues/766. The background task got scheduled, but due to the bugs from #759 or #766 , the detection cannot be executed correctly, therefore, there's no detection logs appear in the system setting. My suggestion is, to switch to manual mode, and see if you can got the error messages from the system. Thanks.

[mss1010]

If the developers will not react and comment within the next 2 days, I guess we should inform media sites that the app is basically disfunctional.

You are of course free to inform whoever you see fit about this issue. But keep in mind that the app is only facing issues in a small set of edge-cases, we are already investigating this issue (as visible by the assigned status) and we have other issues with higher priority (e.g., the unexpected error codes from the system which we have to investigate together with Apple).

I think there is a misunderstanding about the scope of this bug. It is not only happening in a small number if edge cases, but for every single device I checked it. I think in the first days some users maybe opened the app sometimes manually because it’s something new and interesting. But most users just will install the app ans NOT check it regularly. For these (which we can guess is a BIG MAJORITY) the app DOES NOT WORK. They will not get a warning about any exposure.

[tkowark]

@mss1010 we do understand this issue, but for many devices it is working as expected while for others it was mostly matter of not activating background app refresh properly: https://www.coronawarn.app/de/faq/#no_risk_update_ios

We are not sure how many devices you have tested, but rest assured that we are also using the app ourselves and do not experience this issue on a large scale. Could you also try the manual update as suggested above to see whether an underlying Error 5, 11, or 13 might hinder proper updates?

[mss1010]

Hello @tkowark, thanks for your reply.

Ok I see that you are aware of the issue. Regarding the manual update, yes I did this and ir worked, and I did not get any error message in the app.

[haosap]

Hello @tkowark, thanks for your reply.

Ok I see that you are aware of the issue. Regarding the manual update, yes I did this and ir worked, and I did not get any error message in the app.

Hi @mss1010 ,
Thanks for testing it. Could you please share your screenshot of Kontaktüberprüfung here again? We want to see some pattern from the scheduled date.

[i336616]

Hi @mss1010 & @PalminX,

Thanks for your updates, they're much appreciated. Our team is looking into this at present, to determine the root cause of this issue.

Here's some more details on our implementation. It's based on the sample code provided by Apple (see the link below). I've been testing this on 4 devices locally, using the following methods:

1. Triggering simulated background tasks on device, to ensure our code for handling the exposure calculation is executed on receiving the background event, and
2. Running the application overnight, and logging the execution flow of the background task handling to a file (so that the application doesn't need to be opened to check the risk status, which would otherwise reschedule the background tasks again)

From the documentation below, Apple indicate that, by checking for the app's Exposure Notification entitlement, and using the specific background task identifier (i.e., with a .exposure-notification suffix), the operating system will automatically launch & guarantee more background processing time to the task.

From our logging, we've also verified that setTaskCompleted(success: Bool) is called on the background task when executed, ensuring that the background scheduler does not flag our task as a rogue process.

We've also noticed during our testing that background tasks execute more reliably when the device is plugged in. The tasks will still execute when unplugged, just adhering less strictly to the task's earliestBeginDate, which in any case is not a guaranteed execution time. In addition, we specify nil for the earliestBeginTime for the exposure-notification task. The ExposureNotification framework internally applies a earliest start time of 4 hrs to this task, regardless. From discussion with Apple, this is expected behaviour by design when using the BackgroundTasks framework.

https://developer.apple.com/documentation/exposurenotification/building_an_app_to_notify_users_of_covid-19_exposure
(See the section on Create a Background Task to Check for Exposure)

Again, thanks for your feedback on this. We'll also update here with the results of our testing, to keep you informed of our status of this issue.

[ay-kay]

Have you considered using Background Notifications to inform users when new diagnosis keys become available? This could grant the app execution time on demand, independent of any proprietary iOS scheduling algorithms and would allow users to be informed more quickly. When combined with the existing background tasks, this might improve the reliability and efficiency of background updates.

[JThoennes]

Thanks for the detailed update(s). Now I have got two questions:

1. What exactly means "manual update"? Just opening the app?
2. From the last comment I conclude that apps with the .exposure-notification suffix get privileged treatment by iOS. What happens in power saving mode? I usually have it switched on and notice that the app is not updated as if the background actualization is not properly switched on.

In addition, normal users are not even aware of these settings for background processing and also not aware of such funny things as FAQ... what is this? ;-) So the app should exercise some self-control and recommend the user to update and check is settings if it is not updated regularly. Ideally, the server could provide an expected next update time and if the app is consistently off schedule the user should be alerted and advised about remedies.

[mss1010]

Hello @tkowark, thanks for your reply.
Ok I see that you are aware of the issue. Regarding the manual update, yes I did this and ir worked, and I did not get any error message in the app.

Hi @mss1010 ,
Thanks for testing it. Could you please share your screenshot of Kontaktüberprüfung here again? We want to see some pattern from the scheduled date.

Yes, here is my screenshot from today. Today I waited for the exact time (11:49) and then opened the app several times until it got the update. A side-note: What I noticed today is, that the biggest package has 1450 keys, exactly the same number like the biggest package yesterday.

[gigiCom]

If the developers will not react and comment within the next 2 days, I guess we should inform media sites that the app is basically disfunctional.

You are of course free to inform whoever you see fit about this issue. But keep in mind that the app is only facing issues in a small set of edge-cases, we are already investigating this issue (as visible by the assigned status) and we have other issues with higher priority (e.g., the unexpected error codes from the system which we have to investigate together with Apple).

I strongly disagree!
This is not only a corner case, in contrary, this is a major case because if the app is never started, which I assume is THE major case, it won't inform users about potential health risks, if not this is a major case, what then?

[gigiCom]

If the developers will not react and comment within the next 2 days, I guess we should inform media sites that the app is basically disfunctional.

You are of course free to inform whoever you see fit about this issue. But keep in mind that the app is only facing issues in a small set of edge-cases, we are already investigating this issue (as visible by the assigned status) and we have other issues with higher priority (e.g., the unexpected error codes from the system which we have to investigate together with Apple).

I think there is a misunderstanding about the scope of this bug. It is not only happening in a small number if edge cases, but for every single device I checked it. I think in the first days some users maybe opened the app sometimes manually because it’s something new and interesting. But most users just will install the app ans NOT check it regularly. For these (which we can guess is a BIG MAJORITY) the app DOES NOT WORK. They will not get a warning about any exposure.

Let me clarify my original bug report. The IDs get updated if the app remains open, even in the ebackground, but they don't if the app remains closed, that's the point.

[gigiCom]

@mss1010 we do understand this issue, but for many devices it is working as expected while for others it was mostly matter of not activating background app refresh properly: https://www.coronawarn.app/de/faq/#no_risk_update_ios

We are not sure how many devices you have tested, but rest assured that we are also using the app ourselves and do not experience this issue on a large scale. Could you also try the manual update as suggested above to see whether an underlying Error 5, 11, or 13 might hinder proper updates?

All you are missing is mentioned in the original bug report and its attachments. To mention is again: YES, background tasks are enabled.

The bug happens when the app is closed, so manually update something is not related to the bug report.

[i336616]

@mss1010 we do understand this issue, but for many devices it is working as expected while for others it was mostly matter of not activating background app refresh properly: https://www.coronawarn.app/de/faq/#no_risk_update_ios
We are not sure how many devices you have tested, but rest assured that we are also using the app ourselves and do not experience this issue on a large scale. Could you also try the manual update as suggested above to see whether an underlying Error 5, 11, or 13 might hinder proper updates?

All you are missing is mentioned in the original bug report and its attachments. To mention is again: YES, background tasks are enabled.

The bug happens when the app is closed, so manually update something is not related to the bug report.

Thanks, @gigiCom. I've tested the background tasks today, & checked the logs. They are definitely being triggered by the operating system, & being rescheduled on completion. If, as you say, the exposure checks are not being carried out during the background task execution, then that helps us isolate the root cause of this issue.

[PalminX]

@i336616, thanks for the update, and for pointing out the relevant Apple documentation.

My experience is that these issues are really hard to debug, and that different devices can act extremely different due to overall system load, quite independent from background refresh settings.

The debugging approach that you mentioned makes a lot of sense, but as long as this isn't done on devices which exhibit this issue, it will be hard to find the root cause.

What I noticed in the Apple documentation example is that their task has an explicit expirationHandler, defined which cancels the running exposure detection process.

In the implementation in ENATaskScheduler.swift, I don't see an expirationHandler.

In my understanding, this means that when iOS decides that time has run out for the BGProcessingTask, it will just kill it, and the task will not be able to complete.

Can you comment on this?

[i336616]

@i336616, thanks for the update, and for pointing out the relevant Apple documentation.

My experience is that these issues are really hard to debug, and that different devices can act extremely different due to overall system load, quite independent from background refresh settings.

The debugging approach that you mentioned makes a lot of sense, but as long as this isn't done on devices which exhibit this issue, it will be hard to find the root cause.

What I noticed in the Apple documentation example is that their task has an explicit expirationHandler, defined which cancels the running exposure detection process.

In the implementation in ENATaskScheduler.swift, I don't see an expirationHandler.

In my understanding, this means that when iOS decides that time has run out for the BGProcessingTask, it will just kill it, and the task will not be able to complete.

Can you comment on this?

Sure, understood, I had concerns myself in relation to exactly that. We've brought this up with the team from Apple, and they have confirmed that for the .exposure-notification task, it is not necessary to implement the expirationHandler, if there is no cleanup required. Also, they have confirmed that even if the device is in low power mode, the operating system should still execute this task.

[PalminX]

Sure, understood, I had concerns myself in relation to exactly that. We've brought this up with the team from Apple, and they have confirmed that for the .exposure-notification task, it is not necessary to implement the expirationHandler, if there is no cleanup required. Also, they have confirmed that even if the device is in low power mode, the operating system should still execute this task.

If that's from the horse's (Apple's) mouth, then it could be that it's correct... I would not really bet on it though.
How long would executeExposureDetectionRequest() typically take?

[i336616]

Sure, understood, I had concerns myself in relation to exactly that. We've brought this up with the team from Apple, and they have confirmed that for the .exposure-notification task, it is not necessary to implement the expirationHandler, if there is no cleanup required. Also, they have confirmed that even if the device is in low power mode, the operating system should still execute this task.

If that's from the horse's (Apple's) mouth, then it could be that it's correct... I would not really bet on it though.
How long would executeExposureDetectionRequest() typically take?

It shouldn't take more than a couple of minutes, for the most part. Will check and verify that with the rest of the team.

[i336616]

Sure, understood, I had concerns myself in relation to exactly that. We've brought this up with the team from Apple, and they have confirmed that for the .exposure-notification task, it is not necessary to implement the expirationHandler, if there is no cleanup required. Also, they have confirmed that even if the device is in low power mode, the operating system should still execute this task.

If that's from the horse's (Apple's) mouth, then it could be that it's correct... I would not really bet on it though.
How long would executeExposureDetectionRequest() typically take?

It shouldn't take more than a couple of minutes, for the most part. Will check and verify that with the rest of the team.

We confirmed with our team this morning that the exposure notification background task should currently take at most 1 minute or thereabouts.
Also, in regards the background task behaviour for the exposure notification, yes, this was confirmed directly with Apple. Summarising a conversation we had yesterday afternoon with them, all background tasks for get a priority scoring that the operating system uses to determine whether or not it will be executed. The exposure notification task, as defined above, is automatically granted the highest priority possible, which allows it to bypass the device's low power mode setting, ensuring execution.

[gigiCom]

it seems that there were some findings.

@i336616 could you be so kind to answer to my bug report appropriately. Btw. the thing is still on status _open_, which is obviously not the case.

To sum my bug report up, I argued that the system does not do any ID actualization and therefore it does not do any ID matching if the app is closed, because the time stamp of the last ID actualization does not lie in the past, but it is always the time when the app gets started.

[PalminX]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

[i336616]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

@Palminx I agree with your assessment. I've been testing on my devices locally, and am seeing the same issues you describe. We know that the exposure-notification background task is not guaranteed, but (according to Apple), they should receive a higher priority than regular background tasks. Having inspected the logs for bgtask execution, there definitely appears to be some inconsistency with how this is executed, and they do not seem to be consistently getting the necessary priority to execute.

[i336616]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

@gigiCom Specifically in relation to the time of the last actualization displayed in the app, we added a fallback on re-entering the app, that if the device is automatic mode, bringing the app back to the foreground will automatically attempt to carry out a risk assessment. This will execute the API call if the last actualization occurred over 24 hours ago. This may explain why the app shows the most recent time, as opposed to the expected scheduled time, particularly if the background task is not running correctly on your device (see my comment to @PalminX in relation to the reliability of the bgtask execution)

[i336616]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

@PalminX I agree with your assessment. I've been testing on my devices locally, and am seeing the same issues you describe. We know that the exposure-notification background task is not guaranteed, but (according to Apple), they should receive a higher priority than regular background tasks. Having inspected the logs for bgtask execution, there definitely appears to be some inconsistency with how this is executed, and they do not seem to be consistently getting the necessary priority to execute.

Also, I'm in communication with Apple colleagues, and am forwarding on our logs and captured sysdiagnose files for their engineers to provide assistance with determining the issue.

[mkuhn]

Would it be possible to set a shorter interval, e.g. every 12 hours instead of 24 hours? Then a delay by an hour or two wouldn't matter too much, as the update frequency would still be higher than now.

[BastianZim]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

@i336616 Same here. The background check is being done but at an interval of 24h + _x_ with _x_ being around 2 hours, meaning that after 12 days a day is "skipped".

[gigiCom]

For the last few days, the updates were done in the background.
So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

@PalminX Could you briefly explain how one can verify that the updates were done in the background on iOS, how did you find this out?

[BastianZim]

@gigiCom On your iPhone: Settings > Privacy > Health > COVID-19 Exposure Logging > Exposure Checks

[gigiCom]

Would it be possible to set a shorter interval, e.g. every 12 hours instead of 24 hours? Then a delay by an hour or two wouldn't matter too much, as the update frequency would still be higher than now.

The next one comes and asks why not using 6 hours etc.

More interesting is the question why at all the development group decided to take these famous 24 hours and not another timeframe. Which server load estimation was the basis for that decision, for instance.

[gigiCom]

@gigiCom On your iPhone: Settings > Privacy > Health > COVID-19 Exposure Logging > Exposure Checks

10x!

[BastianZim]

The next one comes and asks why not using 6 hours etc.

@gigiCom I'm not from the development team so take this with a grain of salt but I think this is restricted by Apple as the API only allows calls at a certain rate.

[tkowark]

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: https://github.com/corona-warn-app/cwa-backlog/issues/2

Addition: if that rate limit is exceed, you get the infamous Error13

And the 10x entries your are seeing in your exposure logs are answered here: https://www.coronawarn.app/de/faq/#multiple_exposure_checks

[BastianZim]

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: corona-warn-app/cwa-backlog#2

Yes, that's what I was referring to but couldn't find anymore. Thanks for linking it! @tkowark

[sin-azucar]

I'm sure that has been considered, so I feel almost stupid asking: But have you thought about decoupling the background task's scheduling interval and the rate limit interval of the internal Apple API? For this to work, the app would record the timestamp when it last successfully submitted something to the API. Now, the job itself can be scheduled much more often than every 24 hours (e.g. every 2 hours, taking into account that in reality it will be more like 2-6 hours or even more...). On every invocation it would check whether the last API-call was >= 24h ago and return immediately if that's not the case.

This might also prevent some of the "Error 13" errors, because it's an additional safeguard against accessing the API more often than allowed.

[i336616]

The problem is not a server load issue, but also related to the rate limiting for doing exposure checks through the ENF. This is also discussed in detail here: corona-warn-app/cwa-backlog#2

Yes, that's what I was referring to but couldn't find anymore. Thanks for linking it! @tkowark

Hey @mkuhn & @gigiCom, @Lucurus is 100% correct in relation to the 24hr limit, this is a restriction placed by Apple & Google on their framework usage. It's my understanding that they're looking into reducing this time-limitation in a future update, but unfortunately it's not within our control to manage this, so for the moment, we're stuck with the 24hr limit on API calls.

[i336616]

I'm sure that has been considered, so I feel almost stupid asking: But have you thought about decoupling the background task's scheduling interval and the rate limit interval of the internal Apple API? For this to work, the app would record the timestamp when it last successfully submitted something to the API. Now, the job itself can be scheduled much more often than every 24 hours (e.g. every 2 hours, taking into account that in reality it will be more like 2-6 hours or even more...). On every invocation it would check whether the last API-call was >= 24h ago and return immediately if that's not the case.

This might also prevent some of the "Error 13" errors, because it's an additional safeguard against accessing the API more often than allowed.

@sin-azucar Not a stupid question at all, in fact that's exactly how we implement it in the app. The task scheduling occurs every 4 hrs, but we check the config every time just before we make the submission API call to determine if we can make the remote request, and returns straight away if it's still within the restricted period.

[BastianZim]

@i336616 Thanks for the confirmation, that makes sense as I've never had a bigger delay between calls than _24h + 4h_.

[mss1010]

The problem is that the developer decided very early against pushing updates through silent notifications. Running background tasks on iOS is very limited. Especially if the user doesn’t use the app regularly.

@i336616 Can you please comment on that? I´m not familar with how the background or other types of notifications work on iOS. But would this be an alternative to wake up the app more reliably?
As we see, both on iOS and Android it´s currently not possible to reliably run the app in background mode, so can you explain why or why not notifications are an option to achieve that?

[pkreissel]

So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

[mss1010]

So I think the assessment that this is not a hard "doesn't work", but that it is more of a transient delay (due to iOS note necessarily running the bg tasks with high enough priority), is valid.
This still means that for _some_ devices, the update could be delayed for an undetermined time.

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Yesterday the background update worked the first time for me. I changed the iOS settings for background update to „fully on“ and activated WiFi.
Before that, I had the background update only on for WiFi and had WiFi deactivated.

Sounds a bit weird, I will monitor it further with different settings the next days to narrow it down.

[PalminX]

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

[pkreissel]

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

this is terrible. I know a lot of people who power down their phones at night.

[i336616]

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

this is terrible. I know a lot of people who power down their phones at night.

@pkreissel @PalminX As this is a limitation on the OS, not sure this is an issue we can resolve. I'll raise this with our Apple colleagues to see if they can suggest a solution.

[mss1010]

I saw on multiple phones now, that this is in fact a "hard doesn't work". On those phones there were no updates for days. I restarted my phone 2 days ago and didn't receive any updates since (haven't opened the app). I think this could be the cause.

Well, in order to schedule the background tasks, the app has to be started at least once after a phone reboot, as far as I understand.

Oh really??? Oh my god! Then this probably explains the different behaviors of background updates working or not. I switch off my phone every night, and obviously I do NOT plan start the app every day manually. The last days I just did it in order to test things, but obviously that´s not the intended use of the app.

Ok, it´s a limitation of iOS, but that´s REALLY REALLY BAD. In the meanwhile I lost all my confidence in the benefit of this app. There are way too much stones in the way to make it a success. I will not mention the other fundamental issue here, but for this topic: Basically this means, that you need to start the app manually after each reboot. I´m quite sure, that nearly NO USER knows this.

Maybe this should be included in public information about the app.

Question to SAP and Telekom: Can you estimate from the server statistics, how many devices are getting the daily updates? Based on the number of active installations, you could anonymously analyze, how much installations are getting the daily updates, and how much don´t because of all this terrible mess here.

[diveflo]

I lost all my confidence in the benefit of this app. There are way too much stones in the way to make it a success. I will not mention the other fundamental issue here, but for this topic: Basically this means, that you need to start the app manually after each reboot. I´m quite sure, that nearly NO USER knows this.

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

[mss1010]

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

Might be. Maybe I‘m not the average user 😉

Offtopic:
However, the whole usage of the app way too low for several reasons. Currently, there are around 8000 confirmed active infections in germany, and just 300 of them used the app to get a code. This for sure does not consider demographics or familiy constellations, etc.

[sin-azucar]

I think you highly overestimate the percentage of people who even semi-regularly shutdown/reboot their phone.

While we can only speculate about that, I would say that almost everyone's phone gets turned off at some point. Maybe because you go to a place, where you more or less have to switch it off (movie theater, TV studio) or because you involuntarily run out of battery (happens to me all the time 😵). The bottom line is, even if this happens just once, the app will never again schedule a background task until the user decides to open it again.

I agree with @pkreissel and @mss1010: This is really a deal breaker. 😞

[PalminX]

I think the only way around this would be to schedule push notifications (in addition to the current background task scheduling). But I am also not an expert on iOS programming

[pkreissel]

While we can only speculate about that, I would say that almost everyone's phone gets turned off at some point. Maybe because you go to a place, where you more or less have to switch it off (movie theater, TV studio) or because you involuntarily run out of battery (happens to me all the time 😵). The bottom line is, even if this happens just once, the app will never again schedule a background task until the user decides to open it again.

I agree. I never power my phone down voluntarily, but its old and runs out of battery weekly. We are now at 18% usage in the German population. This is 3% higher than the 15% necessary for the app to have an effect according to Oxford Study. So if only 1 in 6 sometimes turn off their phones, then the App becomes useless for everyone else.

This should be the highest priority bug on here.

[tkowark]

Thank you all again for your input. As mentioned in one of the earlier comments, @i336616 is investigating the issue and also discussing with the colleagues at Apple how to best ensure that the background jobs are also triggered after a restart.

We understand both the issue itself and the urgency of it.

Since we currently also see now further technical input being required, we will lock the conversation and give an update as soon as we have finished our investigation and can provide a solution for it.

[SebastianWolf-SAP]

According to recent discussions (see e.g. #920) missing background updates also occur under iOS 13.5(.1) if the app was started once after restart. We clearly see that under iOS 13.6, but the bug might have already been there in iOS 13.5 (or was introduced in a recent CWA version).

[GPclips-zz]

Hello @gigiCom,

This issue has been fixed (Release 1.2) and will be closed now.
If you have additional questions or comments, please feel free to reach out :-)

Thanks,
LMM

Corona-Warn-App Open Source Team