blocking: add processing of gregors about block buttons

Still needs dismissing to work, but I think it should get a look, especially since I'm not entirely clear on the best way to do dismissing.
Also waiting on https://github.com/keybase/keybase/pull/4735
cc @keybase/y2ksquad

@keybase/react-hackers this is ready for review.

bump @keybase/react-hackers @joshblum

(I thought I'd had some go changes here, but apparently I didn't)

Needs new storyshots, but I don't know which stories to look at to confirm that it works well.


Support CODE_SIGN_STYLE on automatic_code_signing action.

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context
Since Xcode 9, CODE_SIGN_STYLE parameters are added to each build configurations.
https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW876

Currently, automatic_code_signing action will only modify ProvisioningStyle.
In case, each values are different between CODE_SIGN_STYLE and ProvisioningStyle, folliwing error would be raised.
[14:13:53]: ▸ Code Signing Error: XXXX has conflicting provisioning settings. XXXX is automatically signed, but provisioning profile XXXX has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the project editor.
[14:13:53]: ▸ Code Signing Error: Code signing is required for product type 'Application' in SDK 'iOS 11.1'

Description
This patch will also set CODE_SIGN_STYLE for all build configurations when automatic_code_signing action is called.

Have you tested this locally for your Xcode projects?

Of course 👍
I tried following situations:

✅ Create new Project on Xcode 9 and toggle code sign styles.
✅ Create new Project on Xcode 8 and toggle code sign styles.

On project files on Xcode 8 don't know CODE_SIGN_STYLE property. However, it will be ignored, so works well.


ARM64 container for seq-input-gelf

A seq-input-gelf container that supports the ARM architecture would be great, to run within a Minikube environment on an M1 Mac.

Thanks for the suggestion 👍

This would be great to do. We need to get https://github.com/datalust/seqcli/issues/227 sorted first.

Awesome. I'm trying to replicate the k8s -> fluent-bit -> seq-input-gelf -> seq story on my local machine but not having much luck with k8s logs pumping through, trying to establish if its is something in the 'best effort' x86 emulation that Docker Desktop does via QEMU that is getting in the way.

Ah that sounds... Fun 🙃 Unfortunately there are a lot of moving parts in that story so it's hard to point the finger at any one piece.

Just an update on this one, we've done some work in https://github.com/datalust/seqcli/pull/228 to produce ARM-based containers for seqcli. Once we've got those published we'll be able to start using them as base images for the GELF input here too.

Thanks for your patience on this one @jimmcslim! I've opened #99 to finish off ARM support for the GELF input here. It's probably far too late for your original need but should now make it possible to run the GELF input on M1-based dev machines or Graviton.

As of datalust/seq-input-gelf:2.0.343 we have an ARM build of the container available.


AdBuddiz supports AdMob + MoPub mediation

@erugeri thanks for the updated info in the PR.  Last time I offered you to join our code samples initiative, never heard back.  This is an easy opportunity for you to reach our developer community with your product.  Shoot me a line to<EMAIL_ADDRESS>and I'll tell you more.


gcc6.2 has -Wunused-result  by default. Is this really a must?

Issue description
Compiling anything causes lots of warnings i have to turn of flag. Not a huge problem but caused little chaos. in the end you guys will decide should it stay or not. is there way to turn it out by your self (without  giving each time gcc -Wno-unused-result.
Steps to reproduce
gcc this.c -o this. Silly warning pops out.
int main( void )  {
int i = 0;
scanf( "%i", &i );
return 0;
}
Technical details
Linux huenix 4.4.56 #1-NixOS SMP Wed Mar 22 11:17:51 UTC 2017 x86_64 GNU/Linux

System: 16.09.1904.4da11d7 (Flounder)
Nix version: nix-env (Nix) 1.11.8
Nixpkgs version: "16.09.1904.4da11d7"

gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/8f4rnl7x43vnxgj1ik76i1nazfigdzha-gcc-6.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/8f4rnl7x43vnxgj1ik76i1nazfigdzha-gcc-6.2.0/libexec/gcc/x86_64-pc-linux-gnu/6.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
Thread model: posix
gcc version 6.2.0 (GCC)
thx for answers.

I don't think this is a silly warning, as this should be fixed in upstream projects and we normally never change defaults that upstream GCC or other compilers provide.
Warnings should also never be turned off in package builds in nixpkgs except for not making them errors to still allow building projects (-Wno-error=whatever)


consistent usage of logs directory

I've generated app, and ran server and tests in it -- logs get written to ./logs/*.log

Thanks again for this, @andriytyurnikov. I've pulled #23 instead, since the intention was to have a singular log directory all along, I just miswrote the .gitignore.


chef_client_config is not rendering a correct client.rb

Description
It seems that the client_config template is inserting an = sign in-between properties and values.
This does not seem to be valid config causing the chef-client binary to ignore the config values.
Chef Version
16.6.14
Platform Version
CentOS 7.9
Windows 2019
Replication Case
Create a recipe with:
chef_client_config 'create client.rb' do
    chef_server_url  Chef::Config[:chef_server_url]
    ssl_verify_mode :verify_none
end

run chef-client on a node with that cookbook and recipe
inspect the content of /etc/chef/client.rb
[root@ip-10-0-1-34 ~]# cat /etc/chef/client.rb
node_name = "linux-client-0"
chef_server_url = "https://<IP_ADDRESS>/organizations/acmecorp"
ssl_verify_mode = :verify_none

log output from running chef client
[root@ip-10-0-1-34 ~]# chef-client -c /etc/chef/client.rb
Starting Chef Infra Client, version 16.6.14
Patents: https://www.chef.io/patents
[2020-11-08T11:06:23+00:00] ERROR: Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, retry 1/5
[2020-11-08T11:06:28+00:00] ERROR: Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, retry 2/5
[2020-11-08T11:06:33+00:00] ERROR: Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, retry 3/5
[2020-11-08T11:06:38+00:00] ERROR: Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, retry 4/5
[2020-11-08T11:06:43+00:00] ERROR: Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, retry 5/5

================================================================================
Chef encountered an error attempting to load the node data for "ip-10-0-1-34.eu-west-1.compute.internal"
================================================================================

Networking Error:
-----------------
Connection refused - Connection refused connecting to https://localhost/nodes/ip-10-0-1-34.eu-west-1.compute.internal, giving up

Your chef_server_url may be misconfigured, or the network could be down.

Relevant Config Settings:
-------------------------
chef_server_url  "https://localhost:443"

System Info:
------------
chef_version=16.6.14
ruby=ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-linux]                                                                                program_name=/bin/chef-client
executable=/opt/chef/bin/chef-client

the template that renders this is in resource/support/client.rb
I am assuming we just need to remove the = from lines 24, 29 and 31
https://github.com/chef/chef/blob/master/lib/chef/resource/support/client.erb#L24-L31

Fixed in master


Not working for me :/

I have done everything you described in the readme file, but it schows only the title of the module but no Tasks.

Fixed it for me, got the wrong project id's from the Todoist Website.
While debugging found typo in log #45


Major data usage (2,25GB mobile data in one month)

Avoid duplicates

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

Technical details

Device name: Samsung Galaxy A3 2016
Android version: Android 7.0
App version: 2.16.2

Describe the bug
The CWA used 2.25 GB (!) of mobile data in 28 days. Usage in WiFi is unknown.
Steps to reproduce the issue
Expected behaviour
The data usage should not be this high.
Possible Fix
Additional context

Internal Tracking ID: EXPOSUREAPP-11611

How often are you connected to the internet via Mobile Data?

The phone is connected to the mobile network every workday 10-17 Uhr, the other times to a regular wifi

@dadosch
Okay, FYI: In general the app is doing exposure checks on mobile data only once a day, see https://www.coronawarn.app/en/faq/#risk_update_24.
It should be investigated if a usage that high is plausible.

@dadosch
In case your concern is about charging for the data volume, there is an FAQ article specifically about this point
https://www.coronawarn.app/en/faq/#mobile_data_costs
It is referred to in the link above given by @Ein-Tim.

@MikeMcC399 @Ein-Tim very interesting. The data usage definitely counted towards the data cap, as the cap was reached and the person had to buy a additional data plan.
I queried the mobile data usage of the app, as reported by dumpsys netstats package de.rki.coronawarnapp (removed all WiFi usages from the output) and made a quick graph showing the data usages and packet numbers.
Beforehand a few things I've noticed: The bytes sent and received are equal, probably an Android issue. The data usage according to the output of dumpsys for the CWA is 3590 MB, so higher than what the system tools says. Might be because of a different method of counting, might be because RX and TX is included, I don't know.

Only since 15th January:

@MikeMcC399 the provider is AldiTalk, so E-Plus/Telefonica.
Just one additional note: the storage of the phone is nearly full, this might have something to do with the issue 🤷

There definitely seems to be an issue.
I'm on wify nearly 24/7. I made a rough check:
mobile data - 200 MB used in the past month. Hi data usage started at Jan 20. On 26th alone >80MB have been used, since then only a small amount of KB.  The data usage of CWA obviously did not count against my mobile quota (provider vodafone).
wifi data - usage of ~7.2GB in the past month, compared to 171MB in December...
I'm also very low on internal storage, currently around 400-600MB free.
One idea could be, that CWA can't complete some (download) tasks (due to lack of internal space?) and in consequence repeats the downloads of diagnosis keys.
@dadosch for the phone you're taking care of I'd suggest to activate 'mobile Hintergrunddaten einschränken' for CWA until the problem is solved - updates for risk matching via wifi could be enough.

Maybe also associated with #4732 ?

Hi @dadosch and everybody! Thanks for report and analysis. Internal Tracking ID: EXPOSUREAPP-11611
Best wishes, DS

Corona-Warn-App Open Source Team

A error report would be helpful to confirm the theory of redownloads of failed downloads because not enough space is left.

@thomasaugsten in my (and probably all other case it's problematic, as for good reasons the log-file is stored inside CWA's cache directory which gets wiped when the OS has the feeling it should free some space.
The past error reports that I started where hence 'killed' after a couple of hours.
I'll try to time error report with the expected downloading window, maybe this can work.

There may also be a timeout problem in the download task, that is connected to the lack of internal storage: my observation is that the whole mobile gets  into a state of laggy to unfunctional responsitivity the more free internal storage decreases, possibly because of operations to free memory.
So we should look not only to directly memory related hints in error logs, but also download timeouts.

Just for info:
A quick look at my data usage (Samsung Galaxy Note 10, SM-N970F/DS; Android 12 (One UI 4.0) with Android security update: January 01, 2022 (since 3 days); CWA Version: 2.16.2; ENF:<PHONE_NUMBER>0) shows for the period from 01/01/2022 to 01/29/2022 (today):
Mobile data usage: 0 B
WiFi data usage (Corona-Warn-App): 224 MB.

@thomasaugsten
Are the DiagnosisKeys files downloaded also stored in a cache directory? Because this would mean, CWA is downloading everytime all files instead of just hourly packages when cache is cleared by OS on a regular basis due to low memory.

Just for info:
A quick look at my data usage (Samsung Galaxy Note 10, SM-N970F/DS; Android 12 (One UI 4.0) with Android security update: January 01, 2022 (since 3 days); CWA Version: 2.16.2; ENF:<PHONE_NUMBER>0) shows for the period from 01/01/2022 to 01/29/2022 (today):
Mobile data usage: 0 B
WiFi data usage (Corona-Warn-App): 224 MB.
178 GB of 256 GB storage free;
3.8 GB of 8 GB RAM free.

My data usage is nearly the same (Android 8, Galaxy A5 (2017).
So this is not a general problem.

@thomasaugsten
error log started somewhat after 12:00 UTC, download should have happened around 12:22 UTC, CWA received EW and did risk calculation around 12:33 UTC.
Looks like everything worked fine, so I'm not sure if you can find something. Did some disk cleaning last night, since then there's 600-700MB internal storage free. I assume the threshold when OS jumps in to do cache wiping is around 500MB free memory.
Error log:
2022.01.29 - 14:44:28
ID B3FB247BF67E4D7C90FC

Additional note: before the last risk check, the wifi data usage counter for CWA in January was 7.311MB, now it's 7.312... Don't know how much in size is an hourly DK package currently.

@thomasaugsten
After I sent the error log for the successful risk check in background, meanwhile there had been another one. This time 58MB of data had been downloaded, what looks suspicious to me.
However, I can't send an error log now, because obviously OS again purged the cache directories, so error logging had been stopped. Free internal storage is 580MB currently.
Looks like, it's hard to impossible to log memory issues.
I was once discussing with @d4rken , whether the error log could be stored, but he explained good reasons not to do so: when something goes wrong with error logging (continous crashes of CWA) and the error log is inside the app's data directory, there's no way to recover than erasing CWA's data via system settings what may be hard for some users.
Beside this, erasing CWA data also Coward collected RPIs due to Google's data privacy policy.
Third reason is, that when users enable error log and forget to disable it after a while, internal storage can run full and OS can't do anything about it (i.e. free storage by clearing cache).
So I think there's not much that can be done to clearly diagnose the root cause. It would need a fix by altering the download logic (and in parallel maybe changing the logic of providing DKs to ENS like I proposed elsewhere) just by relying on the symptoms.

Since my last comment 2 days ago, 600MB have been downloaded by CWA. That would sum up to 9GB per month.

Just for info: A quick look at my data usage (Samsung Galaxy Note 10, SM-N970F/DS; Android 12 (One UI 4.0) with Android security update: January 01, 2022 (since 3 days); CWA Version: 2.16.2; ENF:<PHONE_NUMBER>0) shows for the period from 01/01/2022 to 01/29/2022 (today):
Mobile data usage: 0 B
WiFi data usage (Corona-Warn-App): 224 MB.
178 GB of 256 GB storage free;
3.8 GB of 8 GB RAM free.

Today (01/31/2022):
Mobile data: 0 B
WLAN (Corona-Warn-App): 234 MB.
176 GB of 256 GB storage free;
3.7 GB of 8 GB RAM free.
Note: with very few contacts to outside.

@vaubaehn
Are you running Android 7.0 (API24) like @dadosch? The issue may be API level dependent. My oldest compatible device is Android 8.0 (API26) (same device as @DerVogel2020) and I am not seeing any high network usage on that device.

@MikeMcC399
Thanks for your good idea. I'm running on Android 6. My thought is, that it's indirectly independent from API level: the lower the API level, the older the mobile, the slower the system, the more limited the storage. System speed and free storage might contribute to this issue, but for sure I would not exclude anything that is directly related to API level. If we could break it clearly down by API level, then it would need to be API level <=24.
@Jo-Achim
Thanks for your feedback - did I get it right, in the past two days your CWA downloaded 10MB? Then the issue contributes by factor 60 to increased traffic.

@mlenkeit and @thomasaugsten
In case that can get fixed somehow, this might probably also justify a forced-update like suggested in https://github.com/corona-warn-app/cwa-documentation/issues/732, as this like reduces substantial costs for bandwidth and traffic.

@Jo-Achim Thanks for your feedback - did I get it right, in the past two days your CWA downloaded 10MB? Then the issue contributes by factor 60 to increased traffic.

Yes, that's right: 10 MB in the last two days.
(Or 234 MB from 01/01/2022 until 01/31/2022.)

@vaubaehn
The module DeviceStorage.kt treats anything older than API26 (8.0 Oreo) as legacy and runs differently.  That is to say API25 (7.x Nougat) and earlier are handled as legacy. You have said that you are running Android 6, which is API 23 (Marshmallow) and therefore is also handled as legacy.

@MikeMcC399
Good catch! Just from a fast screening I'd say it's about how APIs allocate necessary storage. Maybe in allocation something doesn't work as expected? Definetly something the devs should have a look into.
I'll try to find something in my error logs with keyword "requestStorage".

@vaubaehn
Have you updated to the latest version 2.16.2 or are you still on an old version?

I'm still on 2.6.1 for some reasons... Still waiting for the forced-update.
Have the storage allocation functions been introduced in a later version?

A question for the people operating the backend: Do you see any increased traffic size? Depending on the amount of legacy devices out there this should probably be visible…

@vaubaehn
The 2.6 version you are using was released in July 2021 and your test results may not be representative of the current version. (The one module which I mentioned was last changed in April 2021, however so far there is no proof that this module is involved in the root cause of the high data volume issue.)

@dadosch I pinged one dev from the server department 30 minutes before you asked, let's see if he responds.
@MikeMcC399 What do you mean by test results? The amount of data downloaded in one month (>7GB)? This fits perfectly with results observed by @dadosch for WiFi data - although the two of us are a small sample size and not representative for the proportion of possibly affected devices.
By the way, the log message in this block seems to be wrong,
https://github.com/corona-warn-app/cwa-app-android/blob/658f702021dfce94278be40fdf9c43f386574ec3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/storage/DeviceStorage.kt#L70-#L75
it should be             "requestStorageLegacy(path=%s, requiredBytes=%d)",

A question for the people operating the backend: Do you see any increased traffic size? Depending on the amount of legacy devices out there this should probably be visible…

@dadosch related parties are working on the issue: https://github.com/corona-warn-app/cwa-server/pull/1703#discussion_r795977457

@vaubaehn

By the way, the log message in this block seems to be wrong,
https://github.com/corona-warn-app/cwa-app-android/blob/658f702021dfce94278be40fdf9c43f386574ec3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/storage/DeviceStorage.kt#L70-#L75
it should be "requestStorageLegacy(path=%s, requiredBytes=%d)",

Will you open an new issue and / or submit a PR to correct the text of the log message?

Shifting discussion from there (https://github.com/corona-warn-app/cwa-server/pull/1703#discussion_r798318349) to here:

@mlenkeit

@vaubaehn there are ways to download files only if they are different from what the client downloaded last time (i.e. e-tag, if-none-match header, etc.).

That was actually a way what I was thinking about and thus pointing my question to @hilmarf . Logging the hashes into a CWA-internal db as a control mechanism could then prevent superflous downloads of keys as well as non-necessary key provisions to ENF (as they're obviously not matched anymore by ENF due to a kind of suspected logging mechanism - but the inspection/file operations on provided key files need much time on older phones like mine thus contributing to timeouts in the workflow).

However, CWA is using other mechanisms that ensure that files are not repeatedly downloaded.

If you have time, in one sentence, could you elaborate?

We are stills struggling to understand why these repeated downloads happen on some devices and I'm not yet convinced that changing the caching approach in CWA will fix it.

I can share my observations: on older phones with less internal storage, the OS is wiping all app caches frequently to free some space. Hence DiagnosisKey-files are deleted (was confirmed by Fynn Godau in an internal chat, you might confirm by performing your own simple experiments), and if CWA's mechanism to prevent repeated downloads is not functionally here, it may lead to the observed problem. What might contribute to the problem of low memory is, that there might be a bug in ENF (https://github.com/corona-warn-app/cwa-app-android/issues/4732), but that's a weak suspect currently. Other observations indicate that former DK-RPI matches ("risk contacts") are cached by ENF and always returned by getExposureWindows() during the 14/15-day validity period. So it was a win on performance to only provide DKs to ENF that not have been submitted before. To confirm this behaviour, it would need more effort to experiment, as it either needs a whitelisted account or a rooted OS to inject crafted RPIs with matching TEKs (DKs) into ENF.
If my theory applies to reality, this possibly also mitigates issues where risk detection stops on older phomes (due to CWA and ENF timeouts) when incidence rates are high (resp. larger DK packages).

Anyway, this PR here was not motivated by the repeated downloads but rather by the size of recent diagnosis key packages in general.

Yes, I got this from the beginning, but I wanted to share and exchange my thoughts also with @hilmarf , as I assumed he may contribute to a solution with his professional expertise. I hope everyone is fine with that, but we may also shift further discussion to the related Android issue.
PS: error logging/report is not effective to detect/confirm this issue here, as the error log itself is stored in the app's cache directory, hence purged together with DK-files when OS wipes all app caches - I was already explaining this problem to Thomas. This might be the reason why it's diffcult to find out the root cause, as no error log may detect the problem...

@vaubaehn

By the way, the log message in this block seems to be wrong,
https://github.com/corona-warn-app/cwa-app-android/blob/658f702021dfce94278be40fdf9c43f386574ec3/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/storage/DeviceStorage.kt#L70-#L75
it should be "requestStorageLegacy(path=%s, requiredBytes=%d)",

Will you open an new issue and / or submit a PR to correct the text of the log message?

@MikeMcC399 I will do at a later time.

@dsarkar
The WiFi data usage for the time frame Januar 10 to February 7 is now approx 13 GB for my phone due to repeated downloads.
Please investigate.

@vaubaehn Forwarded ...

@dsarkar Thanks...

Good morning @mlenkeit , @thomasaugsten and @hilmarf ,
I now have an indirect proof, that the high mobile/wifi data usage is caused due to intaction between low storage on device, Google's ENS data storing policy and an unfortunate handling of processing Diagnosis Keys packages by CWA.
As written above, CWA submits all available Diagnosis Keys packages (past daily packages and current hourly packages) via provideDiagnosisKeys() to ENS in each API call. ENS is storing all provided Diagnosis Keys for each call in a system folder for the ENS for about 3-4 days. As each API call provides packages up to 100MB (sizes from 6 days ago), with up to 6 calls per day, the persisted data in ENS could reach between 1.8 and 2.4GB internal storage (e.g., https://github.com/corona-warn-app/cwa-app-android/issues/4732#issuecomment-1040081787). Todays's sizes may be smaller due to decreasing incidence rates (didn't measure today).
As many old phones have very limited storage capacities, the internal storage may run full quite fast due to that mechanisms. In case Android OS detects free internal storage <500MB, it automatically purges caches of all apps. For CWA it means, that already downloaded Diagnosis Keys packages that have been stored inside the app's cache directory get cleared, and so that packages are completely downloaded again before the next ENS API call. About one week ago, that could mean a download volume of 600MB per day, when the cache had been cleared multiple times per day. In my case, the download volume was about 13GB per one month.
As my phone was rendered nearly unfunctional due to lack of free internal storage, I decided to give CWA's fork CCTG a trial. From discussions with @fynngodau and from a short peek into the microG code, and also after some information of @Ein-Tim it was clear, that microG does not store all provided Diagnosis Keys packages in their .bin files. Instead, after each API call with provideDiagnosisKeys() the TEKs are inserted into a sql db and stored there for further processing. There are no redundant doublettes what keeps necessary storage space in a minimum.
I turned off ENS but did not clear data in Google Play Services, and then installed CCTG. In the first day, I still had low storage (as DK packages are still stored in ENS), so Android OS was still clearing all app caches regularly. As CCTG also stores DK packages into the app's cache directory and uses the same provideDiagnosisKeys() call like CWA, the clearing of app cache caused CCTG to download Diagnosis Keys packages repeatedly, which caused a download volume of >300MB for that day.
During the next night, ENS cleared some storage of older Diagnosis Keys .bin files what released ~500MB. That was enough free space to stop automatic cache clearing by Andorid OS. Since then, CCTG is only downloading the hourly Diagnosis Keys packages, what contributes to <10MB of daily download volume.
As written in another comment, it's unfortunately not possible to capture these problems in an error log, because the error log is stored inside CWA's cache directory. Because of this, the error log gets deleted every time Android OS is purging the app caches. And if there is continously enough free space in the system (>500MB) the problem wouldn't occur.
Possible solution to decrease TSI's bandwidth for Diagnosis Keys downloads:

ask Google to quit on storing .bin files for 3-4 days inside ENS. It does not seem to make sense, as TEKs are stored in a LevelDB (for up to 14 days, see below) anyway, or
download from server and provide each .bin file to ENS only once. This would mean that CWA needs to log the eTag of the .bin file (stored in a db inside CWA's data directory, not cache directory), and only download and provide .bin files that not have been downloaded and provided before. This has several advantages: a) .bin files do not need to be stored by CWA. Provided once, they can be "forgotten". b) ENS only stores a minimum amount of .bin files what keeps internal storage consumption low. c) file processing is much faster hence causing less system load thus saving some power. d) because of faster file processing there will be less time outs, hence provideDiagnosisKeys() and risk calculation works much more reliable -> less users complaining about "stopped risk detection".

=> the only question is: will it be enough to provide each .bin file only once? Google says:
Description of provideDiagnosisKeys():

[...] When using the ExposureWindow mode, all provided keys are accumulated under the ExposureWindows. [...]

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#methods
and
Description of getDialySummaries() (ExposureWindow mode):

[...] This function returns a list of DailySummary objects for the last 14 days (or less, if specified in the DailySummariesConfig). [..]

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#methods
If taken these to descriptions together, we may assume that all exposures are stored for 14 days in ENS and can be retrieved by CWA for that time period.
Unfortunately there is no clear statement, whether exposures of 14 days are also returned by getExposureWindows(). But logically, when there is no token used (like recommended!) in provideDiagnosisKeys(), or the token stays the same which each call, it can be assumed that the list of retrieved Exposure Windows contains all exposure windows from the last 14 days.
So, validating assumptions above by experiments (or simply asking Google directly) and a small refactoring of the DK provisioning can solve many different problems.
These are the moments, when I'm missing passionate team members like @d4rken with who I was discussing many of these aspects on GitHub in the last year. But maybe you can convince the POs to put this issue with high priority into the backlog and someone else can take care of it.
--
Thanks to @fynngodau , @mh- and @Ein-Tim for discussions, and to @darkmattercoder ,  @reinob , @6e6e58c4 , @klic , and @kille for providing valuable information by looking into root:/data/data/com.google.android.gms/app_en_diagnosis_keys on their rooted phones.
FYI: @dsarkar

... for the proposed solution

download from server and provide each .bin file to ENS only once. This would mean that CWA needs to log the eTag of the .bin file (stored in a db inside CWA's data directory, not cache directory), and only download and provide .bin files that not have been downloaded and provided before.

I forgot one thing: to make this work smoothly, we would need to make hourly Diagnosis Keys packages available for all the past period (currently 10 days), not only for today and yesterday. So in case a phone was off internet for a longer time, the single missing packages can be picked and downloaded. Daily packages then are necessary for backwards compatibility only.
As far as I remember, persisting hourly packages on the server for a longer period than 2 days only needs a change of one parameter in the server config file, so it should be minimum effort at that place.

P.S.: @mlenkeit
To cite you from above:

We are stills struggling to understand why these repeated downloads happen on some devices and I'm not yet convinced that changing the caching approach in CWA will fix it.

To reproduce the problem/to find out how low storage/caching affects repeated downloads you may try the following steps:

Take a phone with plenty of free internal storage where CWA is active for at least a week.
Go to settings and check how much wifi/mobile data was used by CWA until today, calculate the daily average. Write down both numbers.
Now fill up the internal storage of your phone with arbitrary files, until there is only 400-500MB free storage left.
Leave CWA/the phone alone for 24 hours.
Go back to settings and check how much wifi/mobile data has been used during the last 24hrs. Compare to the daily average in step 2.

To reproduce how much CWA's provideDiagnosisKeys() mechanism effects internal storage in ENS, you may try the following:

Take the same phone in the state of step 5 from the previous experiment.
Go to settings > apps > Google Play Services and check how much storage is reserved for "data".
Disable ENS via CWA or Google Account settings.
Leave phone alone for 24 hrs.
Repeat step 2.
Repeat step 4.
Repeat step 2.
Re-Enable ENS.
If you now check data usage of mobile/wifi, you should be able to observe the same quota like in the previous experiment step 2.
Repeat step 2 (in this experiment).
Repeat step 4.
Repeat step 2.
Repeat step 4.
Repeat step 2. Now the free internal storage should be somewhere be between 450 to 700MB - as Android OS tries to wipe app caches as often as possible...
If you now leave the phone again alone for some time (>24hrs) you will notice, that the mobile/wifi data usage has increased again, probably around factor 60.

Hope that helps.

@vaubaehn Many thanks for the analysis, all forwarded to the internal ticket.

Hi @thomasaugsten , @GisoSchroederSAP and @dsarkar ,
in this issue here it was reported that CWA causes a very high internet data usage on single devices, mobile data (>2.2GB) as well as wifi (>13GB), and in some cases CWA's mobile quota counted agains the users' data plans. I just found a recent report in Google Play Store, where the data usage lead to limited connection speed after the data plan had finished:

In this issue, we analized, that an interaction between CWA's mechanism of caching Diagnosis Keys packages, low internal storage on the phone and Android's automatic cache cleaning may cause repeated downloads of Diagnosis Keys from TSI's servers. The risk of low storage (hence repeated downloads of Diagnosis Keys) is increased due to the way how CWA provides Diagnosis Keys to the ENS (with each call, all available packages of the past 10 days plus the hourly packages of today are provided) and ENS storing policy of provided .bin files (for each call, all provided .bin files are stored for 3-4 days), as the storage consumption can currently contribute with ~1.5GB.
We provided a guide on how to reproduce the problematic behavior, and we proposed some ways on how to mitigate the issue.
What we forgot is to discuss some legal aspects:
https://www.coronawarn.app/en/faq/#mobile_data_costs claims that

[...] Mobile data that is transmitted via the Corona-Warn-App when diagnosis keys are uploaded or when the server notifies you in case of exposure is free of charge and will not be deducted from your data plan.
The zero rating applies to all SIM cards that are distributed by German network providers. [...]

According to the report in the issue here and on Google Play Store, that claim is not completely true. Obviously, there may be some exceptions from some providers in general, or the providers did not guarantee a "full flatrate for CWA data", but they technically implemented a limited zero-rating for the IP addresses used by CWA per device. The limitation might have been set on base of practical estimations (e.g., 1GB per month per device or even less) some time ago.
The problem is, that the publisher of the CWA likely does not know that at least CWA's FAQ does claim characteristics about the zero-rating that are not true in their completeness due to the unfortunate interaction between CWA, Android and ENS. There may have been similar statements published in other places as well. I would not dare to exclude that this issue may have some legal implications.
I therefore strongly recommend to inform the publisher accordingly and change the FAQ temporarily until the issue has been fixed/enhanced. The FAQ could state that exceptions from the zero-rating might occur currently for some devices and that steps are taken to ensure a full zero-rating again. The paragraph of https://www.coronawarn.app/en/faq/#mobile_data_costs could state that, "as long as more than 500MB internal storage is continously available on your device 4 days after the installation of CWA, the zero-rating most likely will be in effect entirely".
I also recommend to supplement paragraphs about the pre-requisites of the installation of CWA accordingly:
https://www.coronawarn.app/en/faq/#in_short

How do I ensure error-free use?
To ensure error-free use of the Corona-Warn-App as part of contact tracking, always use the latest version of the app and keep your device's operating system up to date. In the settings of your device, activate the background update, Bluetooth and for Android devices up to and including Android 10 also the location detection. Then, within the Corona-Warn-App, enable risk detection and carry your device with you when you leave the house! Open the app once a day to check for regular risk status updates. To limit downloads of data for risk detection to the minimum necessary, we kindly ask you to ensure that after the installation of Corona-Warn-App the internal storage of your **Android device** continously provides significantly more than 500MB free space.

https://www.coronawarn.app/en/faq/#minimum_requirements

What are the minimum operating system requirements for my phone?
UPDATE February 10, 2021
iOS - Minimum operating system requirements
The minimum operating system level for iPhone 5s, iPhone 6 and iPhone 6 Plus devices is iOS 12.5. For iPhone SE (1st generation), iPhone 6s, iPhone 6s Plus and newer iOS devices the minimum is iOS 13.7. These versions of the iOS operating system include the necessary v2 version of the Apple Exposure Notification Framework.
See also [Apple/iOS]: Why is iOS 13.7 a minimum requirement? and the blog articles Telekom and SAP to make Corona-Warn-App available for iOS 12.5. and Corona-Warn-App version 1.12 comes with two new features
Android - Minimum operating system requirements
The minimum operating system level for all Android devices is version 6 of Android. In addition, the device must have Google Play services installed, with a minimum version 1.5 of the Google Exposure Notification System (ENS). See [Google/Android]: Which version of the COVID-19 Exposure Notification System is currently installed? for instructions about how to find out which version of ENS is installed. Before the installation, please ensure that there is at least 2GB free internal storage left.

The suggested 2GB calculate as follows: ~100MB for CWA including all data downloaded subsequently and stored inside CWA's data directory and cache directory + 1.4GB for temporarily stored .bin files inside the ENS provided via provideDiagnosisKeys() + 500MB buffer necessary to prevent Android OS from automatic app cache clearing.
Please provide information until the end of the week, on how you will further proceed on this issue, in terms of

fixing/enhancing the caching behavior
informing the publisher
adapting the FAQ

If we won't hear anything from you until Friday evening, it may be the best, that community informs publisher directly next week. as well as public media, to prevent users to get in trouble with their mobile data plans.
Thank you in advance!

@vaubaehn Thanks, we will have a look at this

Impact commented also in https://github.com/corona-warn-app/cwa-website/issues/2385#issuecomment-1048748060

The app gives no choice about using shared European diagnosis keys. Would it help users to be able to choose between German-only and European exposure checks, if their device is low on free storage space?

The app gives no choice about using shared European diagnosis keys. Would it help users to be able to choose between German-only and European exposure checks, if their device is low on free storage space?

That is an interesting idea. I calculated some data:
DK packages from 2022-02-14 to 2022-02-13 sum up to 46.1MB for EUR and 39.9MB for DE. With all hourly packages of today until midnight, we may estimate a data load of 50.71MB for EUR and 43.89MB for DE.
When for 3 days there are 18 calls (6 per day) for provideDiagnosisKeys(), .bin files would sum up to 913MB for EUR and 790MB for DE. For some devices the difference of ~120MB may already make a difference, but 120MB is not that much in all.
The avarage proportion of DE Diagnosis Keys to EUR DKs in the past 10 days is ~86%. I don't know how much is the impact of Austria that will stop their service end of this month, and whether there are other countries quitting contact tracing which could decrease the number of DKs additionally.
However, the app would need to be adapted to leave the user the choice to download the type of DK packages (EUR/DE). For some portion of the user population it may not be easy to take a decision about it. Also, when changing between EUR and DE, there will be a delay of up to 3 days (storage time in ENS) until an effect could be visible, but the effect will be under the radar of most of the users likely. But for TSI it could be a gain of overall bandwidth for their servers, hence reduced costs for TSI and mobile providers.

But for TSI it could be a gain of overall bandwidth for their servers, hence reduced costs for TSI and mobile providers.

Even if it were a gain for TSI in overall bandwidth for their servers and lower costs for wireless carriers, I don't think the idea is viable. At least as long as the savings are not actually quantified.
In addition, the CWA represents a European solution in the sense that diagnosis keys are also exchanged across borders, which I think is very important given the increasing amount of travel. (I myself recently brought a red warning from Italy.)
And explaining to a CWA user that he should think about changing his CWA configuration before and after traveling abroad, ... if this cannot be automated, I do not think it is very realistic or practicable.
Of course it would be nice if we didn't need an app like the CWA anymore, but I'm not sure yet - next winter will definitely come. And the virus still has plenty of time and opportunities to mutate.

Hi @hilmarf ,
there are some not so good news with impact on bandwidth of your servers that I'd like to share with you.
According to this simulation study: https://depositonce.tu-berlin.de/bitstream/11303/16461/4/2022-02-23_MODUS-COVID_Bericht.pdf we can expect a rise of incidence rates again starting from end of February due to the spread of Omicron subtype BA.2.
From the modeled data, the best case scenario predicts incidence rates that will stay somewhat below the rates that we had two to three weeks before, or they will be similar. Hence, the server infrastructure should handle this case well, as it did in the past weeks.
But now for the worst case secenario: this model predicts incidence rates of factor 2.5 within a few weeks.
What does this mean for the server resources?
With Omicron subtype BA.1 we had Dialy Diagnosis Keys packages up to a size of 10MB. With factor 2.5 for BA.2 worst case scenario, Dialy Diagnosis Keys package size would increase to 25MB. With the current storage policy of Google's ENS and CWA's caching/providing mechanism, the storage for .bin files in ENS may increase to 3 days x 6 calls/day x 25MB per daily packages x 10 daily packages per call = 4.5GB.
To prevent Android from automatic cache cleaning, Android mobiles would need free internal storage of >5GB. If the storage with the predicted incidence rates is less, it would mean that a single Android device will download Diagnosis Keys packages up to 6 times per day (on wifi), with 250MB per download and an overall download size of 1.5GB per day. Calculated for the whole month, a single affected device then would download 45GB per month. For a device that is solely on mobile, it would just be 250MB per day and hence 7.5GB per month.
A critical question is now, how many devices could be affected? Let's assume, that the free internal storage on all Android devices follows the normal distribution (Gauss...). We don't know what is the average free internal storage of all Android devices out there, so we can only guess, what proportion of devices has less than 5GB free internal storage left. What it be ok to estimate, that around 20% of Android devices have less than 5GB free?
Then we may estimate that CWA currently has 15.000.000 active Android users. That result in ~3.000.000 Android devices with less than 5GB free internal storage. If they were all on wifi, in a whole month in the worst case scenario, they would download 3.000.000 x 45GB per month which is roughly 130 Petabyte/month. The real life sizes would be smaller, as many devices are also running on mobile data, thus downloading less often.
All other devices with >5GB free internal storage would only download 25MB per day, which is 750MB per month. Means, 12.000.000 devices x 0,75GB per month are roughly downloading 8.6 Petabyte/month on wifi. If there was no issue with Android devices with <5GB internal storage, monthly downloads were about 11 Petabyte for all Android devices.
So if the worst case scenario of increasing incidence rates due to Omicorn BA.2 came true, and the issue reported here was not fixed before, there is a chance that you would need to prepare servers for download rates of ~140 Petabytes for the Android devices, plus what is necessary for the iOS devices.
Hope that estimations can help you for your planning and preparations.

Good morning @GisoSchroederSAP  and @dsarkar ,

Please provide information until the end of the week, on how you will further proceed on this issue, in terms of

fixing/enhancing the caching behavior
informing the publisher
adapting the FAQ
If we won't hear anything from you until Friday evening, it may be the best, that community informs publisher directly next week. as well as public media, to prevent users to get in trouble with their mobile data plans.

I hope you can provide some information during the course of the day, on how are your plans with this issue?
If we won't hear anything, we would need to assume that this issue has no priority for the stakeholders or has been considered to be a "won't fix", and that it is tacitly accepted by the stakeholders that a reasonable proportion of Android users has a financial or functional impact on their internet data plans despite publicly published claims. In that case, it we would need to consider further escalation as described above.
Thank you!

We have no direct influence on the OS behavior of Android we can only report the issue.
Traffic of the CWA are free of charge on mobile data plans.

@thomasaugsten
Like described above

Traffic of the CWA are free of charge on mobile data plans.

this is not true for everybody. Reason could be, that there are some limits that providers configured. I think providers did not plan for download rates of >13GB per user like in January/February.
May I interpret your answer that this issue is a won't fix?

@thomasaugsten
Also I described above what you can do to mitigate the issue with impact on OS behavior.
Your answer shows that you did not intend to follow this issue further?

@vaubaehn, I really feel why you are insisting so hard. However, as the cwa already suffers from way too little acceptance and a ton of communication, marketing and development mistakes already have been made, shitty commercial crap apps by some disgustingly acting HipHop artist habe been more accepted than the cwa, I doubt that it would help the project, if the community makes more noise that leads to even less acceptance. Just a thought. How many users would suffer from less than 5gb free memory in 2022? Is that really a thing? I have put shitloads of data on my phone since 2017 and still have about 100 gb left from the original 256gib.....

The zero rating is valid for all german mobile provider user.
Please provide reports where the zero rating is not active we will check this.
We are monitoring the issue but at the moment no immediate actions are planned.

@thomasaugsten there was at least one person reporting that somewhere here in the issue, or has been linked from Twitter or something like that. If you read the discussion you will find it. And: do you really expect that anyone of the real user base will report this who is no techie?

@thomasaugsten
Like described above

Traffic of the CWA are free of charge on mobile data plans.

this is not true for everybody. Reason could be, that there are some limits that providers configured. I think providers did not plan for download rates of >13GB per user like in January/February.
May I interpret your answer that this issue is a won't fix?

The example from the app store doesn't really tell us anything. Zero rating from the provider doesn't affect Android and its telemetry on how much data has been transferred.

@darkmattercoder
I understand your thoughts. Usually, escalating things in such a way is not what I like to do, with rare exceptions. Exceptions are issues with impact on security (and we had also such issues, which are still not completely closed...) or when there is a direct impact on users (financially or practically) that they are possibly not aware about, especially when there are different public claims. And: there does not seem to be any will to at least try out (further) measures to mitigate the issue.
I'm following here for nearly two years, and I think I contributed quite much. In all the time I experienced a good collaboration between stakeholders and community. But in the case here, I am convinced that a wrong decision has been taken that is to the disadvantage for a proportion of Android users.
I had discussions with one of the best community representatives before in regard to public disclosure of issues. We agreed that there is a risk of harming the public acceptance of the app in general. But in the case here, I am convinced that the harm could be much bigger when at a later point in time it becomes public, that stakeholders tacitly accepted financial impact on users because there are not enough resources to solve an issue with higher priority.
So for a public disclosure I tried to be as differentiated as possible. As you correctly wrote, there are just "a few" users affected, and we don't know how many in general. Around one year ago I found a source of marketing research, that estimated Android 6 phones still with ~10% on the market (meaning: old phones with low storage). Meanwhile, there will be less, likely. But still there may be many more with less than 5GB free space...
Let's see.

So you know, that no hard limits for the zero rating are hard coded in any of the German carrier infrastructure? Is that a statement that you got from them and which is reliable? I think that I formation would even be easier to get from the carrier people than by debugging, wouldn't it?

The zero rating is valid for all german mobile provider user. Please provide reports where the zero rating is not active we will check this. We are monitoring the issue but at the moment no immediate actions are planned.

I did this earlier:

The data usage definitely counted towards the data cap, as the cap was reached and the person had to buy a additional data plan.

I want to add that the cap was definitely reached because of the CWA. The person in question normally used only very little cellular data, thats why I can tell.
I also want to point out that while there probably not that many people affected by this, this does cost some people real money (!) and some who are not technicall savvy, don't know about it or that it is caused by the CWA. There should be at least some press info/addition the FAQ etc!

@6e6e58c4

Zero rating from the provider doesn't affect Android and its telemetry on how much data has been transferred.

That is correct, but the example from app store tells us, that his connection rate has been decreased after hitting a limit.
@dsarkar I would suggest to prepare the store support teams to try to get in contact with the users and ask for the provider.
Also we still have our opening post here:
@dadosch reported:

@MikeMcC399 @Ein-Tim very interesting. The data usage definitely counted towards the data cap, as the cap was reached and the person had to buy a additional data plan.

and

@MikeMcC399 the provider is AldiTalk, so E-Plus/Telefonica.

For me it is not acceptable to not actively trying to do more to mitigate this issue.

@thomasaugsten @GisoSchroederSAP
I would be happy if you reevaluated this issue again until tonight.

@vaubaehn

...but the example from app store tells us, that his connection rate has been decreased after hitting a limit

Yes, that's how it works O.o
But we don't know the actual reason. That one user claims that it was caused by the CWA.
Zero rating works otherwise the outcry would be way bigger than just one or two (questionable) reports in the app store.
 That's not how software development works - at least not with such a diverse userbase and complex hardware and software options.

@dadosch
Can you please provide me the provider and the carrier and what kind of contract normale contract or prepaid via mail
<EMAIL_ADDRESS>

@6e6e58c4

@vaubaehn

...but the example from app store tells us, that his connection rate has been decreased after hitting a limit

Yes, that's how it works O.o But we don't know the actual reason. That one user claims that it was caused by the CWA.

Yes, that's true. There still can be other data usage the user was not aware about. This is why I asked @dsarkar to have a better follow up with users in this issue in the app stores.

Zero rating works otherwise the outcry would be way bigger than just one or two (questionable) reports in the app store.

Yes, in general zero rating works. After the issue here was opened, I also found my CWA to have used >300MB mobile quota, but vodafone did not account for it in my case (validating via Android OS data meter vs. charged quota from vodafone).
My observation is, that reports in the app stores are just the "small drop on the hot stone", when you compare against the high numbers of users. Only a very small percentage of people actively report problems or issues via app stores, even less via GitHub. This is a claim I can't prove, but it may have enough face validity.
There is at least the possibility that providers did not configure a "full flatrate" for IPs used by CWA, but set an unknown monthly limit per device, to protect themselves for unexpected costs, in case something goes wrong... And now something went wrong. So it's shared cost with the user. But this is speculation, currently.

 That's not how software development works - at least not with such a diverse userbase and complex hardware and software options.

You are really true, and I'm agreeing. But the case here is situated differently:
We analized what happend, how it happens, how it can be reproduced, what impact it has - and: how it can be mitigated. We know that there is a problem, and we can be sure it can be solved.
My estimations of necessary resources to practically analize and solve the problem:
For reproduction/analizing:

1 phone
1 person setting phone up: 30 min
1 person monitoring the issue over 3 days and documening: 3x 10min.
2 emails to Google: 2x 30min.

For fixing/testing

2 persons refactoring caching/providing Diagnosis Keys to ENS: 2x 5 working days or less
2 persons testing/monitoring phones with fixed app for 3 days/documentation: 2x persons x3 days x20min.

I think that's somehow not that much money/resources/effort.

@6e6e58c4
What I forgot: The above proposed solution would mitigate the issue here. But it would also have even more positive side affects for all Android users: Interaction between CWA and ENS would speed up significantly, thus with high incidence rates we have less timeouts in CWA and ENS, thus risk matching works much more reliably. That could affect other open issues positively (i.e., "stopped risk calculation" where timeouts are the root cause).

Whitelisting happens on the carrier level of the 3 carriers in Germany not on provider level. They all whitelisted the IP and there is no limitation applied. We need more details on the his exact case.
What is the data plan limit what means low mobile data usage. Because I see 1.3 GB on firefox in the screenshot.

Hi @thomasaugsten
just send you an email with the requested details. The data cap limit is 3 GB. The person has never reached the data cap in the previous months and their usage is quite constant, that's why I noticed the bug in the first place at all.

@vaubaehn Thanks for the hint, will forward it to app stores, mailbox and hotline, that they should ask for the provider.

Hi @dadosch, @vaubaehn and community, thanks again everybody for reporting and the detailed analysis. I got feedback, that this issue is being investigated, and someone from the dev team or from Corona-Warn-App Open Source Team will come back here to report the findings once we know more.
Best wishes, and a nice weekend, Dipankar Sarkar

Corona-Warn-App Open Source Team

Hi @dsarkar , this is good news! Thank you.
To make it easier for the investigator, here are some links:

how to reproduce: https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1047162078
more detailed problem description and proposed solution: https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1046771660

When your message came into my mailbox, I was about to write down a possible text for online editorial offices that could be interested into the subject. My intention was to share it here for discussion before submission. We can keep it into the waiting queue for now.
However, for transparency, it could look like this:
Corona-Warn-App: Extrem hoher Datenverbrauch bei Android Geräten mit wenig freiem internen Speicherplatz
Einzelne Nutzer haben den Entwicklern der Corona-Warn-App auf GitHub gemeldet, dass die Corona-Warn-App innerhalb eines Monats einen ungewöhnlich hohen Datenverbrauch durch Downloads aufweist. So wurden in einem Fall Downloads von 2.25GB über eine mobile Datenverbindung, und in einem anderen Fall mehr als 13GB über eine WLAN-Verbindung berichtet.  Die Entwickler weisen in ihren FAQ (https://www.coronawarn.app/de/faq/?search=zero#mobile_data_costs) darauf hin, dass alle Datenverbindungen der Corona-Warn-App von den Mobilfunk-Netzbetreibern nicht auf den Datentarif angerechnet werden. So ist derzeit unklar, warum betroffene Nutzer entsprechende Einschränkungen erfuhren. SAP bemüht sich hier um Klärung.
 Diese Diagnoseschlüssel werden in einem Zwischenspeicher der App abgelegt. Hat das betroffene Gerät aber weniger als 500MB internen Speicher frei, löscht das Android-Betriebssystem automatisch alle Zwischenspeicher, um freien Speicherplatz zu schaffen.  Die Größe der Datenpakete ist abhängig von der Anzahl der erkrankten Nutzer in Deutschland und den angebundenen europäischen Ländern. So wurden auf dem Höhepunkt der Omikronwelle im Februar von einem betroffenen Gerät bis zu 600MB Daten täglich über WLAN heruntergeladen.
Mitglieder der Corona-Warn-App-Community stellen auf GitHub eine Anleitung zur Reproduktion des Problems zur Verfügung und schlagen auch mögliche Verbesserungen der App vor, um das Downloadvolumen massiv zu senken.
Zwar sinken augenblicklich die Infektionsraten in Deutschland stark, so dass sich alleine dadurch das Downloadvolumen in der kommenden Zeit deutlich reduzieren dürfte. Allerdings weisen Forscher der TU Berlin auf der Grundlage ihrer Simulationsstudien (https://depositonce.tu-berlin.de/bitstream/11303/16461/4/2022-02-23_MODUS-COVID_Bericht.pdf) darauf hin, dass in den kommenden Wochen durch eine stärkere Verbreitung der Variante Omikron BA.2 mit einem Wiederanstieg der Infektionszahlen zu rechnen ist.   Auch wenn sich die Mobilfunk-Netzbetreiber verpflichtet haben, das Datenvolumen nicht zu berechnen, empfehlen wir vorsichtshalber darauf zu achten, dass auf Ihrem Android-Gerät bei der Nutzung der Corona-Warn-App ständig deutlich mehr als 500MB interner Speicherplatz zur Verfügung stehen, um keine unliebsamen Überraschungen zu erleben.
So let's see how things are developing in the course of next week.
Dear @dsarkar , thanks a lot for your engagement, too! Have a nice week-end!

@vaubaehn thank you for your thorough analysis, this is very helpful! As @dsarkar mentioned, the team is looking into this and we'll discuss what options we can realize short team and which ones would require more time to realize. The suggestions that were made here in this thread will definitely be considered.
We have also reached out to Google but are yet waiting for reply, however, any fix on ENF side would probably take some time.

Hi @mlenkeit , thanks for sharing your considered measures.
Storing the Diagnosis Keys packages inside the data space could be a temporary emergency solution. As it looks like, we might soon reach a plateau wrt to incidence rates, meaning it could be good to have a fast action on changing the storing regime.
Do you see any chance to get that into 2.19? That would probably help a lot.
However, for me it's not clear how you assessed possible downsides:
In the case of corrupt data of Diagnosis Keys files (hardware or corrupt file structure) there is a low but existing risk of an unrecoverable crash when calling provideDiagnosisKeys(). In that case users would need to re-install CWA or clear all app data to recover CWA in a functional state, meaning loss of user TEKs/contact RPIs (due to Google's data privacy policy and automatic clearing processes), loss of stored certificates, diary information, check-ins,...
That is the reason why @d4rken was careful with Error Log and decided to place it into the cache .
I would be happy, if @d4rken or @mtwalli could comment on that risks.
So, for a long term solution I still favor to log downloaded and provided DK packages, to only provide packages once to ENS and to not store downloaded DK packages after provision anymore. Again, that would also speed up the process of provideDiagnosisKeys() and most likely solve all other problems that are connected with CWA/ENS timeouts.
The log db would also need to be stored inside the data directory. But the difference compared to the Diagnosis Keys packages is, for the db you have full control, for DK packages we would need to rely on TSI mostly.
@d4rken @mtwalli could you please also share a short feedback?

So, given that you're now going to filter ExposureWindows by age - what only makes sense when ENS is storing and providing EWs with risk contacts up to 14 days and longer than the current period of 10-days-TEKs that are provided to ENS -
https://github.com/corona-warn-app/cwa-app-android/blob/df3ae837202874cdb79b16af4f3e69267923b57d/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/risk/RiskLevelTask.kt#L158-#L166
That would mean that

Description of provideDiagnosisKeys():

[...] When using the ExposureWindow mode, all provided keys are accumulated under the ExposureWindows. [...]

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#methods
and
Description of getDialySummaries() (ExposureWindow mode):

[...] This function returns a list of DailySummary objects for the last 14 days (or less, if specified in the DailySummariesConfig). [..]

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#methods
If taken these two descriptions together, we may assume that all exposures are stored for 14 days in ENS and can be retrieved by CWA for that time period.

is true, and provision of each DK package only once is possible?

[...] what only makes sense when ENS is storing and providing EWs with risk contacts up to 14 days and longer than the current period of 10-days-TEKs that are provided to ENS [...]

@vaubaehn the conclusion is not quite correct. Strictly speaking, we are not providing a "period of 10-days-TEKs" to ENF but key packages of TEKs that were submitted in the last 10 days. A key package for day t can contain TEKs for any of the days between t-0 and t-14.
Example:

the youngest key package t-1 contains TEKs [t-1; t-15]
the oldest key package t-11 contains TEKs [t-11; t-25]

A new requirement for CWA is to show exposures for the timeframe of the past 10 days only. As CWA still submits keys outside of this period (as illustrated above) and as ENF always returns exposures for the past 14 days, the app-level filtering is required regardless of any caching in ENF.
Changing this so that CWA would not submit keys outside of the 10-day period would require modifying already published key packages every day to remove the newly outdated keys from those packages. This would be a major architectural change across client and server, as published packages wouldn't be immutable anymore. As this would also require apps to regularly re-download these modified packages, this is something that we are currently not pursuing 😉
See also the related discussion in:

https://github.com/corona-warn-app/cwa-documentation/issues/848

Regarding provisioning each DK package only once:
For all we know, ENF (on Android) maintains an internal cache but ENF the documentation seems to be incomplete regarding how this cache works exactly and how durable it is (as opposed to the iOS documentation where this is pretty clear). Additionally, the ENF cache can be reset on Android devices (as opposed to iOS) by the user through the ENF settings. Most users probably won't do that but it would be an event that CWA wouldn't be able to notice and could cause users to miss exposures.
These are some of the reasons why we are hesitant to make this change.

In the case of corrupt data of Diagnosis Keys files (hardware or corrupt file structure) there is a low but existing risk of an unrecoverable crash when calling provideDiagnosisKeys().

This is pretty interesting and indeed something we did not consider, thanks for bringing this up again 👍 (I now saw that you made the same point earlier in this thread already).
Interestingly, the ENF documentation seems to encourage persisting the files rather than keeping them in the cache:

Note: When downloading the files from the internet-accessible server, store them inside the app-specific directory on internal storage. Optionally, you can create a subdirectory under the filesDir and delete the subdirectory after you've finish processing.

Source: https://developers.google.com/android/exposure-notifications/exposure-notifications-api#providediagnosiskeys
Anyway, we will revisit the aspect of dealing with file corruption.

Hi @mlenkeit , thanks a lot for the detailed response. That facilitates discussion by far, imho.

[...] what only makes sense when ENS is storing and providing EWs with risk contacts up to 14 days and longer than the current period of 10-days-TEKs that are provided to ENS [...]

@vaubaehn the conclusion is not quite correct. Strictly speaking, we are not providing a "period of 10-days-TEKs" to ENF but key packages of TEKs that were submitted in the last 10 days. A key package for day t can contain TEKs for any of the days between t-0 and t-14. [...]

True. I had been aware of it actually, as you can see in your linked discussion: https://github.com/corona-warn-app/cwa-documentation/issues/848#issuecomment-1032537557, but I lost it somehow in the moment when writing above comment. I guess it's not easy for everyone involved to recall the hierachical encapsulated conditions at all the time 😉 .
And yes, that limits my drawn conclusion, unfortunately.

A new requirement for CWA is to show exposures for the timeframe of the past 10 days only. As CWA still submits keys outside of this period (as illustrated above) and as ENF always returns exposures for the past 14 days, the app-level filtering is required regardless of any caching in ENF.

Independently from everything else already stated in this issue, it's good to know that app-level filtering of ExposureWindows by contact date is possible at all, as the is one important prerequisit to implement a different Diagnosis Keys privisioning as proposed here before. For me it's good to know, as I only could speculate on this before (don't neither have sufficient time nor necessary "material" (i.e., Android IDE) to directly investigate).

Changing this so that CWA would not submit keys outside of the 10-day period would require modifying already published key packages every day to remove the newly outdated keys from those packages. This would be a major architectural change across client and server, as published packages wouldn't be immutable anymore. As this would also require apps to regularly re-download these modified packages, this is something that we are currently not pursuing 😉

I didn't think of something like this at all, and I'm fully agreeing. That would be a horrible scenario, if I may speak so.
Now to the ENF:

Regarding provisioning each DK package only once:
For all we know, ENF (on Android) maintains an internal cache but ENF the documentation seems to be incomplete regarding how this cache works exactly and how durable it is (as opposed to the iOS documentation where this is pretty clear).

Could you be so kind and describe in some words, how iOS is handling it?
It's not only to stop my curiosity about that issue, but there's a high likelihood that Google and Apple aligned their handling here for full compatibility/feature parity. But as you refered to the documentation, it's only an indicator that Google's ENF works the same, and not a proof unless Google responds to you with more information or enhances their public documentation.

Additionally, the ENF cache can be reset on Android devices (as opposed to iOS) by the user through the ENF settings.

Ha. No feature parity.

Most users probably won't do that but it would be an event that CWA wouldn't be able to notice and could cause users to miss exposures.

This actually does not have any impact on the proposed solution to provide any Diagnosis Keys package only once for the following reason:
Resetting the ENF cache means resetting all ENS data. There is no way to choose between "just the RPIs I collected" or "all the TEKs that have been created for me". This happens on reinstall of CWA, uninstalling of CWA, simply clearing CWA's data directory (that point is really bad implementend by Google, imho), clearing data of Google Plays Services in all, or when user selects "delete data" via the ENF UI.
So, in this case, there are neither any data for Exposure Windows stored inside ENF anymore, nor any collected RPIs that could be matched with downloaded TEKs that you provide with the Diagnosis Keys packages. You will just start collecting RPIs again, and only the latest DK packages have a chance to contain TEKs that could match with a risk contact. You see, providing any DK package only once is sufficient, because either older EWs are cached in ENS, or you would start right from the beginning anyway.

In the case of corrupt data of Diagnosis Keys files (hardware or corrupt file structure) there is a low but existing risk of an unrecoverable crash when calling provideDiagnosisKeys().

This is pretty interesting and indeed something we did not consider, thanks for bringing this up again 👍 (I now saw that you made the same point earlier in this thread already).

On this particular point, I'd like to add, that the risk of a crash should exactly be the same, no matter whether data is stored in cache or data. I know that @d4rken already assessed this risk at least for himself when implementing Error Log, that's why I'm still encouraging him to comment here about his thoughts 😉 I hope, you're ok with my repeated calls, dear Matthias ❤ .
The difference is, that app is easily recoverable when corrupt data is persisted in cache from a technical point of view. However, from an UX perspective, it's still difficult to support/assist the biggest proportion of the users to clear their caches in case something goes wrong, so probably it does not make such a difference whether corrupted data are in cache or data...

Interestingly, the ENF documentation seems to encourage persisting the files rather than keeping them in the cache:

Note: When downloading the files from the internet-accessible server, store them inside the app-specific directory on internal storage. Optionally, you can create a subdirectory under the filesDir and delete the subdirectory after you've finish processing.

Source: https://developers.google.com/android/exposure-notifications/exposure-notifications-api#providediagnosiskeys

Yes, that's interesting, Max. But from my understanding that's even more interesting:

Optionally, you can create a subdirectory under the filesDir and delete the subdirectory after you've finish processing.

It's not an evidence that it's enough to provide any DK package only once, but an indicator that it might be sufficient, when Google suggests to clear already provided data after.

Anyway, we will revisit the aspect of dealing with file corruption and @mtwalli is of course involved in the discussion 😉

I didn't have any doubt 😉
So in result, I would encourage you to store DK packages in data until a better solution can be implemented, and take action as soon as possible (2.19?)- unless @mtwalli or @d4rken have good argumentation not to do so.

I didn't read every post in this thread (sorry :sweat_smile:), but regarding data vs cache:
The decision to place DK pkgs in cache/ was based on offering edge case resilience and providing user & system flexibility.
The DK packages can be redownloaded at will, without harm, the only cost being network traffic (which is supposed to be null-rated). Putting them in cache/ give the user (and system) the option to recover space if needed without harming the CWA's functionality. It also gives a data loss free option to wipe all packages without loosing any actual data (though this edge-case has luckily not been necessary yet).
What may have been underestimated is the aggressiveness of the cache purges.

So in result, I would encourage you to store DK packages in data until a better solution can be implemented

This would prevent redownload, and reduce (null-rated?) traffic, but the phone will still fill up. What then?
In the best case (newer Android versions) the system will tell the app there is not enough space before actually running out of space, in the worst case the system is honest and all free space is consumed. At that point the phone and many apps will malfunction. What now? Can't clear the CWA data without actually loosing data. To be able to make the phone usable, the user needs space, will they delete their latest TikToks?
Having no free space will also move the user into a dead-lock. Let's say CWA stores all DK pkgs in data/, now the packages grow unexpectedly large, something needs to be done about issue XY, an update is needed, but the user can't update the CWA because Google Play doesn't allow it, there is not enough free space.
TL;DR
I think moving DK packages from cache to data has more downsides than upsides and the amount of affected users don't warrant this change.
Short term:

The user could be informed that this happening, e.g. write file into cache, check if deleted, count up, at y=x, show the user a message with a link to an FAQ or something.
Long term options:
Evaluate whether all DK pkgs need to be kept.
Evaluate storage on external devices (sdcards)

Interestingly, the ENF documentation seems to encourage persisting the files rather than keeping them in the cache:

Note: When downloading the files from the internet-accessible server, store them inside the app-specific directory on internal storage. Optionally, you can create a subdirectory under the filesDir and delete the subdirectory after you've finish processing.

This is less about cache vs files, but more about storing it in private internal storage for reliability reasons. To discourage devs from storing on external public storage, e.g. removable sdcards, which can it's own caveats.

@d4rken
Dear Matthias, thanks for your valuable input!
Just as a short info (which you may kindly ignore when you're busy), as you couldn't read all comments - the situation is quite complex. In key words:

ENS stores ALL Diagnosis Keys .bin files that are provided via each call of provideDiagnosisKeys() by CWA for 3-4 days.
CWA always provides ALL accessible .bin files to ENS
With Omicron and large .bin Files, this led to huge consumed storage inside ENS (up to 2GB and more). CWA's storage space wasn't actually of concern.
Because old phones are low on free storage, this ENS storing regime led to an increased number of devices that ran under 500MB free storage, where app caches then are purged by Android automatically.
Because on these devices cache was empty, CWA repeatedly downloaded ALL available Diagnosis Keys packages from server, up to 6 times per day. That could lead to download volumes of more than 13GB via Wifi or more than 2Gb via mobile per month. It looks like, zero rating didn't work everywhere and people have been charged because of this, but this is not 100% confirmed also from network carrier's/developer's side.

So, my proposal was: Log downloads via eTag, download and provide each package only once. That keeps storage in ENS as low as possible, doesn't affect CWA's app cache (or other storage) in any way, reduces the downloads from TSI servers to a minumum. And, as a side effect: this also likely reduces timesouts in CWA and ENS due to the reduced number of DK packages that need to be handled.
Storing DK packages in data instead of cache was Android dev team's proposal for a short term solution.

@mlenkeit
There are some small details in Matthias' reply that are different from my understanding, but I consider his thoughts as a whole as valid arguments against shifting DK packages into data.
This would mean, for short term we would end up with

Short term:

The user could be informed that this happening, e.g. write file into cache, check if deleted, count up, at y=x, show the user a message with a link to an FAQ or something.

Edit:

If the null-rating and using all data is the biggest issue, the above edge-case detection mechanism could be used to further restrict downloads to WiFi only.

With regard to user notifications/FAQ, some suggestions have already been made in this comment: https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1048684723
I think that could also be a way to go, although it takes more effort to implement than just changing the storing path.

Long term options:

Evaluate whether all DK pkgs need to be kept.

Evaluate storage on external devices (sdcards)

Here it looks like Matthias understood, that the size of DK packages stored by CWA matters most, while the size of DK packages stored by ENS is actually a bigger problem. And as the storing in ENS is directly associated with the way how CWA provides DKs to ENS (everytime all), I'm still convinced, the long-term solution is to change that processing like described many times above (every package only once).

I try to keep it short:
I think:

We should be prevent unnecessary downloads when there is no sufficient space

either by saving the downloaded keys somewhere that is not cleared by Android OS
or even if clearing them is OK, can we use the sync settings - which saves meta-data about the downloaded files - to     avoid downloading them again ?

Be transparent to the user ,maybe with a notification that opens a newly introduced FAQ link or https://support.google.com/android/answer/7431795

I agree with @d4rken  that moving to filesDir won't fix the root cause and just save the downloaded keys from being deleted by Android OS , however I wouldn't exclude this option entirely now.
Both directories are not meant to be used to store large file and it is highly recommended to check the available free space before storing to them which should be done by DeviceStorage.
Few things I found while looking into this

ExposureKeys and TraceWarning are saved in the cacheDir while DeviceStorage checks for filesDir
At first I thought that is might be the issue, but after some testing specially on an emulator running Android 6 I found out         that  StatsFs(cacheDir) = StatsFs(filesDir) probably because both of them are hosted on the same volume. (I see it as an inconsistency more than an issue)

We always assume that the key size is ~512KB, which will lead to wrong allocations ,if the actual size is way bigger than that (at least that what In understood form the analysis above).

KeyCacheDatabase is saved in db (which is persisted) ,but the files themselves are in the cache

should the files be persisted too? or should they be cached ? and until when ? until CWA decide it is not needed anymore or is it OK that Android OS clears them (even though that is also not recommended to rely on)

we could use getCacheQuotaBytes to keep the App cache under the quota which make CWA one of the last Apps to be cleared when space is about to be eaten by Android OS (unfortunately this available from Android 8 , from the reports devices running versions before that are facing this issue)

Any solution that requires Keys evaluation, needs a Google feedback - which it does not seem to be in the near future.
Anyway we started looking into this issue, we will keep you updated.

Hi @mtwalli ,
thanks for your detailed feedback!
I think we still have different understandings, what has most impact on this issue:

The Diagnosis Keys files stored by CWA (in the cache dir) some weeks ago was about 100-120MB: 10 days x 10MB daily DK packages + 10-20MB hourly key packages for devices with repeated downloads.
The Diagnosis Keys files stored by ENS (in the system dir) at the same time was about >2GB. This is due to the way how ENS stores Diagnosis Keys files provided by CWA (all available DK packages (120MB) x 6 times per day x stored for 3-4 days).

So, the biggest impact had and the best solution would be to change the way how CWA provides Diagnosis Keys files, like described in many comments above. I understand that the biggest problem is, that it is not clear whether changing the provision of Diagnosis Keys to ENS still results in the same result in the age/amount of ExposureWindows with risk contacts submitted from ENS to CWA? Yes, Google could clarify on this, but I believe it is not necessary to wait for a response: All others functions (GetDailySummary() and provideDiagnosisKeys() clearly state that exposures/risk contacts are accumulated for 14 days according to the documentation. In worst case, you could do an experiment: You would need to craft a TEK/RPI manually and inject the RPI as risk contact to ENS (via bluetooth or other method), and then join the TEK to a DK package that is provided to ENS and matched with RPIs. That sounds hard, but @kbobrowski (who also solved a big problem with Google that was preventing ENS to work on Android 6 phones in June/July 2020) was doing this. Maybe he can assist here? In this way it could be evaluated whether providing every single DK package only once is sufficient for valid results in ExposureWindows for the past 10/14 days.
Solving this would reduce the amount of storage needed on the volume drastically, hence reducing the risk that Diagnosis Keys are deleted (automatically by Android OS), hence reducing repeated downloads.
Also, do I remember right, that you're already persisting ExposureWindows in a CWA-internal db? Then the above problem would also be solved: even ENS would submit only the risk contacts of the last provided batch of Diagnosis Keys, you can persist them in a db and evaluate them for risk calculation until they expire (currently: 10 days). So, to be on the save side, persisting EWs in CWA could also help, and providing DK packages only once is clearly possible.
So, in the end, everything could be solved without Google's support.
Queyring the free space on the volume to assess whether there is enough space to save Diagnosis Keys files for CWA is unreliable, depending on the threshold: If you set 700MB as a threshold, that wouldn't be enough, because that is the state of free space (on my phone) directly after Android cleared all caches. Even after downloading and storing DK files there is still more than 500MB free, just some user activity with other apps is enough to fill up that caches again (e.g., internet browsing with chrome, opening Google Maps, receiving a video in WhatsApp), and to run out of enough free space soon after again.
Also, due to ENS storing regime of DK files, the DK files size affects free volume space exponentially. On a "fresh" system, you would lose >2GB within 3 days. Or more, when DK file sizes increases even more in the next weeks.
So, the threshold needed to let CWA/ENS work reliably without repeated downloads is difficult to determine and associated to incidence rates. To be on the safe side, I'd propose at least 4GB to 5GB currently. And that is that much that it would need to be communicated to the user carefully.
Anyway, user should be notified about the storage problems that can lead to repeated downloads.

I agree with @d4rken that moving to filesDir won't fix the root cause and just save the downloaded keys from being deleted by Android OS , however I wouldn't exclude this option entirely now.

The worst downside Matthias was mentioning is, if anything goes wrong and an CWA update was needed after a non recoverable problem, Android/Google Play Store would prevent you from an app update when there is less than 500/600MB free, unless you free enough storage manually. Otherwise the user is lost.

We always assume that the key size is ~512KB, which will lead to wrong allocations ,if the actual size is way bigger than that (at least that what In understood form the analysis above).

The size of the packages was already 120MB for 10 days and can increase even more in the future. But relying of the storage to allocate with less than 4-5GB is unreliable according to the problems that I tried to describe above.

Anyway we started looking into this issue, we will keep you updated.

@mlenkeit @mtwalli Could you give information about the time horizon for any kind of solution?
The incidence rates are already rising again, so in the next weeks we will see increased DK package sizes and the problem will get worse again.

@vaubaehn  Thanks for your feedback, What I proposed it is not obviously a FIX, it just to prevent unnecessary work and be transparent about it (Quick Fix), but I agree a proper fix would require:

Reduce the keys size
Change the way how CWA provide them to ENF framework "(if actually feasible)"

I think you would agree that this would be a MAJOR change that needs carefulness, thoroughly tested , and more time to deliver
at the moment we did not settle on a specific solution, I will update the issue once I have an update

@vaubaehn Thanks for your feedback, What I proposed it is not obviously a FIX, it just to prevent unnecessary work and be transparent about it (Quick Solution ), but I agree a proper fix would require:
* Reduce the keys size

* Change the way how CWA provide them to ENF framework `"(if actually feasible)"`

I think you would agree that this would be a MAJOR change that needs carefulness, thoroughly tested , and more time to deliver
at the moment we did not settle on a specific solution, I will update the issue once I have an update

Hi @mtwalli , thanks for your reply also.
Yes, I'm agreeing fully, and I see now we have congruency on Quick Fix and proper fix.
I'm curious how you will decide on changing the storing path (changing or not).
It's clear now, that any fix on app side will come with 2.20 earliest, as 2.19 is already closed for testing.

@dsarkar @GisoSchroederSAP
We're now in the situation that RKI reported a record high on new infections. It looks like, that size of Diagnosis Keys packages will exceed even the sizes that we saw in January/February soon. 14 days ago I was reporting a study that predicted the situation that we're now running into: https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1049865622.
What I understood from previous discussions/comments with @mtwalli (and @d4rken ), there seems to be a common sense that users should be informed about the possibility of repeated downloads.
15 days ago, I made some proposals for the FAQ: https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1048684723
Eventhough there is obviously an exceptionnel risk that people are not falling into the zero rating and are charged for the repeated downloads by CWA (but what has quite an impact in these cases), maybe you agree that it is worthy of the app and due to the situation to provide users with comprehensive information, perhaps with a statement that goes beyond the FAQ.
What are your plans according to this?
Or should the community get active asap?
Thanks in advance for your reply!

@Ein-Tim
I saw that you're in touch with Nico E., who is associated with a wide-perceived online medium. Did you talk with him about this issue before? Could he be a good addressee for a prepared statement coming from the community? Or should a prepared statement go to the editorial office's inbox directly?
You may point him to https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1051308965, but some details need to be changed as the devs are already looking into it. But it's unlikely that we'll see any kind of fix until the 6th infection wave is over.

@vaubaehn
Yes, I'm in contact with @NicoErnst and will talk to him because of this issue.
I'll let you know what he says.

Dear community, this is a text from https://github.com/corona-warn-app/cwa-app-android/issues/4753#issuecomment-1051308965 adapted to the current situation that could be good for a statement. Feel free to share your thoughts.

 So wurden in einem Fall Downloads von 2.25GB über eine mobile Datenverbindung, und in einem anderen Fall mehr als 13GB über eine WLAN-Verbindung berichtet.  Die Entwickler weisen in ihren FAQ (https://www.coronawarn.app/de/faq/?search=zero#mobile_data_costs) darauf hin, dass alle Datenverbindungen der Corona-Warn-App von den Mobilfunk-Netzbetreibern nicht auf den Datentarif angerechnet werden. So ist derzeit unklar, warum betroffene Nutzer entsprechende Einschränkungen erfuhren. SAP bemüht sich hier um Klärung.
 Diese Diagnoseschlüssel werden in einem Zwischenspeicher der App abgelegt. Hat das betroffene Gerät aber weniger als 500MB internen Speicher frei, löscht das Android-Betriebssystem automatisch alle Zwischenspeicher, um freien Speicherplatz zu schaffen.  Die Größe der Datenpakete ist abhängig von der Anzahl der erkrankten Nutzer in Deutschland und den angebundenen europäischen Ländern. So wurden auf dem Höhepunkt der Omikronwelle im Februar von einem betroffenen Gerät bis zu 600MB Daten täglich über WLAN heruntergeladen.
Mitglieder der Corona-Warn-App-Community stellen auf GitHub eine Anleitung zur Reproduktion des Problems zur Verfügung und schlagen auch mögliche Verbesserungen der App vor, um das Downloadvolumen massiv zu senken. Nach Angaben beteiligter Entwickler wird an einer Lösung des Problems gearbeitet. Wann aber eine verbesserte Version der Corona-Warn-App zur Verfügung gestellt werden kann, ist augenblicklich nicht absehbar.
 Auch wenn sich die Mobilfunk-Netzbetreiber verpflichtet haben, das Datenvolumen nicht zu berechnen, empfehlen wir vorsichtshalber darauf zu achten, dass vor der Installation der Corona-Warn-App auf Ihrem Android-Gerät mindestens 3GB und während der Nutzung der App ständig deutlich mehr als 500MB interner Speicherplatz zur Verfügung stehen, um keine unliebsamen Überraschungen zu erleben.

Thanks for tagging me, I´ve been following this issue for a while.
Although Tim, Dan, myself et al are putting some effort into more adoption of CWA and offer direct user-support I still have to follow journalistic principles.
In this case it means: I´d be very happy to receive a statement on this problem ASAP or in advance under NDA (this is a completly normal process) but can only suggest filing a story on this to the editors-in-chief. They know what I´m doing here and on Twitter, it´s all transparent.
However, it´s their decision if they run the story then. I´m very hopefull they will do, but there has to be some real news value, i.e.:  a solution to the problem.
In parallel, I think it´s a good idea to file a normal press release through the usual channels of RKI, BMG etc.
Let me add a little detail: Many users of (older) Android devices struggle with low internal memory anyways. If CWA makes this worse it´s a very bad signal for more adoption and/or use of the app.

@thomasaugsten
Do network carriers also apply zero rating for data tariffs (with limited quota) that are bound to home use, like Congstar Homespot 200  or Giga Cube?
Are landline DSL tariffs with quota included in zero rating, too, like O2-DSL-fairuse?

@vaubaehn , I wanted to share the good news for you and the community.
In short: we wont't change the directory where the key files are currently stored ,but we will provide the diagnosis keys files delta to ENF. In other words after providing the files to ENF successfully we will mark them for deletion and they are excluded from the download again.

@mtwalli
That's actually great news!

but we will provide the diagnosis keys files delta to ENF

I'm convinced that this will solve many other timeout related problems, too!

In other words after providing the files to ENF successfully ...

Without any timeout, there should be a reliable return value from ENF, finally

we will mark them for deletion and they are excluded from the download again.

No more repeated downloads 🎉
What milestone are you addressing?

Most probably, it will be published as a hotfix for 2.19

Most probably, it will be published as a hotfix for 2.19

@mtwalli If you can manage this, that would be awesome.
@NicoErnst @Ein-Tim
Under this circumstances, would it be justified to wait until next week to see how things develop?

Under this circumstances, would it be justified to wait until next week to see how things develop?

@vaubaehn Definitely!

What Tim says - thank you! As all of this is public we´ll share the good news in #CWAweekly , of course, without setting hopes for next week too high. Happy implementing ;)

I can see that the PR #4929 is included in https://github.com/corona-warn-app/cwa-app-android/releases/tag/v2.19.1-rc.0.

Hi @mlenkeit , @thomasaugsten , @chiljamgossow , @mtwalli , @dsarkar , @Ein-Tim & @MikeMcC399 !
The hot fix has been released just some minutes ago. 🎉  As you can think, I'm very happy!
Dear Chilja, thanks for taking over that challenging refactoring!
To all others - FYI:
I'm convinced the change of ENF downloading and providing to a delta instead of a "full package" will show many improvements in several places: The internal storage that is used by Google Play Services will decrease drastically within 3-4 days after installation of 2.19.1. Repeated downloads of DK packages should only be a part of past history then. But I also expect that "stopped risk calculation" and similar (timeout dependent) issues will occur rather less often.
However, we need to prepare for another change due to the fix that can lead to many users raising questions:
I'm expecting that the exposure checking history accessible via Google's UI will reflect the decrease of provided Diagnosis Keys to ENF by displaying a significant lower number of matched diagnosis keys. More advanced users that like to monitor their CWA might stumble upon that change and ask whether their CWA is still working. The answer is: "Yes, better than before".
Dear Dipankar, please have an eye on Google Play Store reviews, whether such questions will come. In case, could be good to prepare the support team (and technical hotline) for adequate answers.
Hey Tim and Mike, you now also know why Google UI may change the numbers, so you may respond to users with these questions accordingly.
Thanks to everyone ❤

@dsarkar

Dear Dipankar, please have an eye on Google Play Store reviews, whether such questions will come. In case, could be good to prepare the support team (and technical hotline) for adequate answers.

See Google Play Store Review https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&reviewId=gp%3AAOqpTOFoxzyLqrS7NVdrj98sNpOtUL7V0XN6A5veCJOup5zwT--jZprw2uCcne8wiYOEI0iH5qanELslTnLKrg
Thank you ❤

I think it's time to say a special thank you to everyone who found, described, experimented with, etc. this problem and finally found and implemented a solution. Especially to @vaubaehn.

@vaubaehn Thanks, we have seen that one actually, preparing FAQ.

I think it's time to say a special thank you to everyone who found, described, experimented with, etc. this problem and finally found and implemented a solution. Especially to @vaubaehn.

I can only second that, thanks a lot from the team to you all of you for the thorough analysis and relentlessly pushing this topic!

@vaubaehn  FYI - PR https://github.com/corona-warn-app/cwa-website/pull/2581

@dadosch
Could you please check whether this issue has been fixed for you, and if yes, close this issue?

Yes, I can confirm it no longer seems to appear. Thank you all for analysing, identifying, insisting on and finally solving this issue 🎉

Hi @mtwalli ,
there are some reports in Google Play Store reviews, that "Risiko-Ermittlung" is not working since "a couple of days", even when hotfixes 2.19.1/2.19.2 are installed.
My idea is, that a slow device that already had problems to finish provideDiagnosisKeys() with ENF-returned success before the hotfix, still has the problem to achieve a success even with hotfix 2.19.1, as for the very first provision with delta-functionality one last time all available DK packages need to be provided (to then be able to create the delta).
That would mean, as soon as DK packages are small enough that the "device gets them through to ENF once" there shouldn't be any problem anymore in the future.
Here is one example review:
https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&reviewId=gp%3AAOqpTOE7RrVyj1aL2e1d7yz9-ruEvgrqc-MKVrlYtWA8kQ2F0ZTlRWsXG5FWHbcLPkEXET8qc42adtGX8F0WzA
Could you kindly look into the error report with ID 9641A3BE1579D4DE0F95 and confirm, that due to timeout ENF does not return success after provision of DK packages?
If this is the case, Google Play Store support team could respond that a fix is already installed and the device will recover itself in "some days".

Thanks @thomasaugsten .
Looks like the user was on "mobile mode", with only one provision per day. And yes, since this morning he should be able to see an updated risk tile.
@dsarkar , do you have the possibility to initiate a communication in some way (e.g., via Play Store) whether the risk tile is now updated? If the response is "yes", then due to the hotfix 2.19.1 the issue should be solved for him in the future.