[upcoming bug] exceeded quota when using with future versions of GMS

Avoid duplicates

• Bug is not mentioned in the FAQ
• Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
• Bug is not already reported in another issue

Describe the bug

I’ve reached out to Google to make documentation more precise as to when quota on provideDiagnosisKeys is set to zero (related to a bug described in https://github.com/corona-warn-app/cwa-app-android/issues/822), and was expecting description to simply state that quota is nullified at midnight UTC as it is done currently, but it was updated to:

Days are 24-hour windows that begin at the time the method is first called.

It looks like this change will be simply triggered by GMS update, regardless of whether original or v1.5 API is used, which would result in exceeded quota in the following scenario:

• user updates Diagnosis Keys at 15:00 UTC
• user opens CWA at 02:00 UTC and update of Diagnosis Keys is triggered again
• quota is exceeded, as it was already at 14 at 15:00 UTC, and will go past 20 at 02:00 UTC update (quota is nullified only at 15:00 UTC next day)

Possible Fix

One option is to track when Diagnosis Keys were last updated, and allow update only after 24 hours from the time this method was first called. But it would revert some progress in the efforts of reducing exposure notification delay as discussed in https://github.com/corona-warn-app/cwa-backlog/issues/2 . Following scenario would be possible:

• user updated Diagnosis Keys at 23:00
• next update is only possible next day at 23:00, despite fresh Diagnosis Keys being available already since 23 hours
• total delay in exposure notification (including delay due to consuming only daily bundles of Diagnosis Keys) is up to 48 hours, and cannot be reduced by the user in any way (currently it can be reduced to around 24 hours by opening CWA early in the morning)

Proper solution here is probably to quickly migrate to v1.5, then it would be possible to update Diagnosis Keys every 4 hours and the timing of when exactly quota is nullified would be introducing 4 hours additional delay in the worst case (even less if hourly bundles would be consumed), not 24 hours.

---

Internal Tracking ID: EXPOSUREAPP-1910

[kbobrowski]

Google fixed docs - count resets at midnight UTC

[kbobrowski]

Google changed it again to:

Days are defined as midnight to midnight of a device’s local time zone.

So it seems the way of defining “day” is still being established. This change would also break CWA on all Android devices, as currently “day” is midnight to midnight UTC in both GMS and CWA, so agree with @w-flo that this issue should be high priority right now.

My feeling is that at this point it is necessary to make CWA robust w.r.t. how Google defines “day”, as it may be difficult / impossible to synchronize CWA update with GMS update, unless there is a way to determine programmatically what is the definition of “day”.

Possible way to get rid of any issues related to definition of “day” is to implement mechanism of retrying provideDiagnosisKeys let’s say every 1 hour after it failed with 39508 (or maybe even any other error), and only after if has been failing consistently for 24 hours raise exception to the user, so it can be reported. This is not very elegant but has good potential of averting this and future unexpected issues with provideDiagnosisKeys (this mechanism would have made previous issues with error 10 / 39508 less severe).

Another option (assuming that Google will settle on resetting quota at midnight local time) is to make sure that the app can only update Diagnosis Keys if the date has changed in both UTC and local time zone - as an interim implementation to support both mechanisms