Cwa-app-android: Google's log says "0 keys" after risk update
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
Describe the bug
Today at 00:01 the first check of keys via the API has been performed. The app indicates a successful risk update and says 'low risk'. What puzzles me is that the log in the Google settings says 'Anzahl der Schlüssel: 0'.
Expected behaviour
The log should say 'Anzahl der Schlüssel: n' with n being the number of keys pulled from the CDN. I expect the app to download keys and initiate a check via the API. If the log is correct, something went wrong. If the log is incorrect, this is another issue. But I can't know what is the case.
Steps to reproduce the issue
Open App, see that risk update has been made, check Google's log, see new (first) entry, check entry, see: 0 keys, 0 matches
Technical details
- Mobile device: Samsung Galaxy A50
- Android version: 10
- App version: 1.0.4
nilsalex
All 86 comments
nilsalex
on 25 Jun 2020
I'm trying to check this but I can't even find the "Details prüfen" screen you included. I can't find it in Settings->Google->COVID-19 Exposure Notifications. I'm using a Pixel 2 (fully updated) but would expect this to look the same for everybody as this is provided by Play Services.
@nilsalex - Can you let me know where in the menu you found this screen?
MikeJayDee
on 25 Jun 2020
It seems that the log is not available in every Android version. For me, with Android 10, it is. For my girlfriend, with Android 9, it isn't.
I can access it by clicking on "Überprüfung auf mögliche Begegnungen" in the first screen and then on the entry "00:01" in the list.
nilsalex
on 25 Jun 2020
Exact same issue with Android 6.0.1 running on Sony Xperia Z3.
jmbaldwin
on 25 Jun 2020
Thanks @nilsalex - I have Android 10; I guess that I may not have the current version of the API, which gets rolled out automatically but probably not simultaneously.
On the topic: note that iPhones appear to be showing that keys are being checked (since yesterday or so). So it is indeed odd that Android would show 0 keys being checked as the same files with keys to be checked is downloaded by Android and iPhone.
MikeJayDee
on 25 Jun 2020
Just 2 days ago, that button was missing from my "Google" phone settings. I have restarted my phone and a few hours later the button appeared, not sure if the reboot was related. Might just be an update rolling out to Android phones in phases these days.
In any case, I now have 3 updates in that log. One update yesterday, and 2 updates today.
There are 0 "Anzahl der Schlüssel" and 0 "Anzahl der Treffer" in all three of my log entries, just like in the screenshot above. I was wondering if "Anzahl der Schlüssel" refers to the number of "bluetooth contacts" registered by my phone, though it's unlikely since the API doesn't exchange the keys themselves via bluetooth as far as I know. I've noticed that calibrated RSSI values from logcat are in the -90 to -100 range even when I sit close to someone else while watching TV, and even when I put my phone on their desk for one hour and they keep their phone in their pocket while sitting at the desk, it's rarely "closer" than -80. So it's entirely possible that my phone has registered 0 "close enough" contacts even though I live with that person, since either my phone or their phone appears to have some calibration / hardware issues.
w-flo
on 25 Jun 2020
Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.
jmbaldwin
on 25 Jun 2020
We are investigating and will update here once we analysed the subject accordingly.
jakobmoellersap
on 25 Jun 2020
Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.
So doesn't my Android 6.0.1 - phone restart did not help.
Version of up-to-date Google Play Dienste is 20.12.17(040308-316502805)
Sorry for hijacking thread.
gizmo21
on 25 Jun 2020
Moto One
Android 10
1. Juni 2020 Patch
1. Mai 2020 Google Play
fdellwing
on 25 Jun 2020
Same issue here
Xiaomi Mi 8
MIUI 11.0.4.0
Android 10
1. April 2020 Patch
Play Services 20.21.17 (120400-316502805)
DooMMasteR
on 25 Jun 2020
Is there anyone that has the menu on the phone, and where there the "number of keys" is more than 0 for any check?
MikeJayDee
on 25 Jun 2020
I cannot check any other devices in my family, because none even have the menu to access the information. But they do all have the same Google Play Services installed.
DooMMasteR
on 25 Jun 2020
The menu is coming from a GMS Update which is still not fully deployed to all devices yet. Also, the assumption is that the 0 keys are only a display bug and the key retrieval and matching are in fact working properly. I will update once this can be finally confirmed from our side.
jakobmoellersap
on 25 Jun 2020
There were screenshots on twitter showing one person who has received warning after husband was tested positive. But it was on iPhone...Android still doesn't allow screenshots.
treysis
on 25 Jun 2020
Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.
So doesn't my Android 6.0.1 - phone restart did not help.
Version of up-to-date Google Play Dienste is 20.12.17(040308-316502805)
Other Android 6.0.1 and here the menu point is at least available
Version of Google Play Dienst is
20.21.17(040400-316502805)
So on this device it has at least been deployed, as @jakobmoellersap said (thx for mentioning)
gizmo21
on 26 Jun 2020
On my Android 6.0.1 device the button is also there, see my first comment, but the keys are at 0.
Does your device show the number of keys checked @gizmo21 ?
jmbaldwin
on 26 Jun 2020
Does your device show the number of keys checked @gizmo21 ?
On that button showing device there is no and won't be a CWA app, so just wanted to report the GPS version.
For that 0 key issue, the devs are on it so we'll just have to wait and perhaps Google has to fix that with an even newer service version :)
gizmo21
on 26 Jun 2020
BlackBerry KeyOne, Android 8.1.0
The past three days there have been several transfers per day (3 just today), and all of them show "Number of Keys = 0"
It seems unlikely to be 'just' a display issue: why would the system attempt a transfer so many times each day?
Our iPhone got just one update two days ago, and shows 503 keys.
UPDATE
https://github.com/corona-warn-app/cwa-app-ios/issues/778
From this iPhone thread I see that it is normal to have several requests every day. It is the expected behaviour, as each day the data of the past 14 days is retrieved again. This means the first day you have 1, then 2, then 3... onwards.
END OF UPDATE
juanaleon
on 26 Jun 2020
This is not a display of a "transfer". This is about the calls for "provideDiagnosisKeys" of the Google API, as can also be deduced from the UI description. The number of keys is likely just a display bug as if no key packages were there, we would not even call the specified function "provideDiagnosisKeys". Since we do call this function (which would correlate to one UI entry), and we do not tamper with the packages, we can be sure it is the same key file package that is also used by iOS.
jakobmoellersap
on 26 Jun 2020
Is there any open issue on Googles end so far?
My experience with issue tracking on that far end are not… good.
Do you have a link to an issue on Googles Issue tracker or is this still speculation.
So far it could also be a handling issue and nothing is ever checked, not really reassuring.
Also: was this never tested?
Would be bad to get an update and have X amount of positive matches suddenly popping up.
DooMMasteR
on 26 Jun 2020
@DooMMasteR I will recheck with Google to see if there is anything I can link to from here.
This was tested on our side and we were able to see the correct key packages being downloaded. Also on our Devices, we were able to see the correct key count with the productive setup while trying to replicate the behaviour. This could be related to some devices being whitelisted and showing up correct key counts while others do not, but we cannot fully guarantee this yet.
jakobmoellersap
on 26 Jun 2020
The fact that you can see the correct count, but many (I know no case that can) makes me wonder if the number 0 might be correct and there is nothing being checked on our devices.
Getting anything productive from Google alone is a privilege on your end, I guess, usually it feels like a dead end for many bugs and issues, that will eventually get fixed, but they offer about zero feedback down the road. Let us hope this gets sorted quickly because people might get the impression (might even be true) that the app is not working for them.
Also: I had one device, and for the lulz resetted it completely (factory) and set up the app again, but it now is not showing the insights anymore, so I guess the access to this feature is quite random at the moment and Google is using multiple versions, the devices had access to it before...
DooMMasteR
on 26 Jun 2020
Regarding your comment of resetting the device: As stated previously in this issue, the rollout is probably not yet completed, and the device reset means that you also reset GMS to a version prior to the rollout of the functionality. I would thus not call the observed behaviour random but in fact expected, wouldn't you agree?
jakobmoellersap
on 26 Jun 2020
It got the COVID functionality back, but not the insights into the API calls, the Corona-Warn works just fine, but I cannot see the checks anymore (I could see them before) the stock GMS has no COVID functionality at all, since it is an Android 9 device. (I guess any phone to date would not have the APIs without any update).
Basically: the way Google handles their rollouts is random... the phone previously got the version with insights, now got one without :-)
My other phones have always had the insight, I never even knew there was one without this feature until I asked a friend about it.
DooMMasteR
on 26 Jun 2020
Seeing the same behaviour on a OnePlus 7T, Android 10, Google Play services 20.21.17 (120400-316502805).
6 exposure checks so far, all of them showing 'Number of keys: 0'.
maurice-w
on 26 Jun 2020
Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.
So doesn't my Android 6.0.1 - phone restart did not help.
Version of up-to-date Google Play Dienste is 20.12.17(040308-316502805)Other Android 6.0.1 and here the menu point is at least available
Version of Google Play Dienst is
20.21.17(040400-316502805)
So on this device it has at least been deployed, as @jakobmoellersap said (thx for mentioning)
No button for details on checks available on my Android 6.0.1; restarted phone to be sure
Device
- Android Version:
6.0.1(stock Android of device, not rooted) - Google Play Services version:
20.21.17(040308-316502805) - Device Model and Manufacturer: Samsung S5 (SM-G900F)
- Latest OS Update: settings say all available updates installed, security patch level 1st Aug 2017 :(
- Kernel:
3.4.0-14131106 from 06 Aug 2018, Build number:MMB29M.G900FXXU1CRH1
- Kernel:
- Google Mobile Services (GMS) version:
com.google.android.gms [202117018] [20.21.17 (040308-316502805)] [Container]com.google.android.gms.nearby_en [v202304013]
Android settings
Android settings>Google> (loads web view of my Google account on Android)- click on
Benachrichtigungen zu möglicher Begegnung mit COVID-19-Infizierten - no button to check stats, see below (ignore the red and green comments in the image, screenshot was made for another issue)
aurisnoctis
on 26 Jun 2020
the assumption is that the 0 keys are only a display bug and the key retrieval and matching are in fact working properly.
I also believe that this is only a display bug, because during matching Android's log clearly shows
06-20 19:18:19.170 1275 16568 I ExposureNotificationJni: matchingNative get 720 keys
06-20 19:18:19.170 1275 16568 I ExposureNotificationJni: Matching with 720 diagnosis key
06-20 19:18:19.260 1275 16568 I ExposureNotificationJni: Matching done, no key matches
06-20 19:18:19.260 1275 16568 I ExposureNotification: ExposureMatchingTracer.traceWithNative() 0 keys matched, total 720 keys [CONTEXT service_id=236 ]
but the details in Exposure checks also show 0 / 0 on my device.
mh-
on 26 Jun 2020
Ahh ok, so adb holds more information after all.
Good to know. But also worrying how bad the testing mus be on Google's end that this stuff slipped through the loops.
DooMMasteR
on 26 Jun 2020
Ok, I think I can confirm that the V1.0.4 Corona Warn Android app
does warn when RPI/TEK matching was positive.
Tested on Android 7.0, Google Play service version 20.21.17 (040306-316502805).
I inserted a lot of RPIs matching 1 Diagnosis Key into the GMS database, and "Check details" shows this:
So apparently, instead of showing all keys that were used for matching, the screen shows the "Number of matches" twice.
Excerpt from logcat:
06-21 11:02:25.301 1270 9567 I ExposureNotificationJni: matchingNative get 1160 keys
06-21 11:02:25.301 1270 9567 I ExposureNotificationJni: Matching with 1160 diagnosis key
06-21 11:02:25.442 1270 9567 I ExposureNotificationJni: Matching done, find 1 keys match
06-21 11:02:25.442 1270 9567 I ExposureNotification: ExposureMatchingTracer.traceWithNative() 1 keys matched, total 1160 keys [CONTEXT service_id=236 ]
06-21 11:02:25.443 1270 9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Native pre-filter found 1 keys with sightings out of 74 scan records. Spent time: 0.180s [CONTEXT service_id=236 ]
06-21 11:02:25.443 1270 9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Java tracing started. [CONTEXT service_id=236 ]
06-21 11:02:25.446 1270 9567 I ExposureNotification: ThreadSafeLevelDbWrapper:contact-tracing-contact-record-db instance btz@bbfab4c created [CONTEXT service_id=236 ]
(...)
06-21 11:02:25.459 1270 9567 I ExposureNotification: ThreadSafeLevelDbWrapper: do open LevelDb en-exposure-result-storage-db [CONTEXT service_id=236 ]
06-21 11:02:25.460 1270 9567 I ExposureNotification: ThreadSafeLevelDbWrapper:en-exposure-result-storage-db instance btz@f954795 created [CONTEXT service_id=236 ]
(...)
06-21 11:02:25.498 1270 9567 I ExposureNotification: previous was null setting to -19 [CONTEXT service_id=236 ]
06-21 11:02:25.500 1270 9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
06-21 11:02:25.504 1270 9567 I ExposureNotification: previous was null setting to -19 [CONTEXT service_id=236 ]
06-21 11:02:25.505 1270 9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
06-21 11:02:25.507 1270 9567 I ExposureNotification: [MatchingTracer: requestId=1592730143785, package=...rki.coronawarnapp] Valid sighting found with TX Power=-14 [CONTEXT service_id=236 ]
(...)
The app shows this:
(note that I fiddled with the device's clock while doing this, so the "0 days since last encounter" is not necessarily a bug)
mh-
on 27 Jun 2020
Ok, so Google will have to fix this... Can only be a matter of days.
Thx for all the testing on your end @mh-
DooMMasteR
on 27 Jun 2020
I will keep updating the discussion once I have more information on the issue solution on Google side. Thanks for your patience, everyone.
jakobmoellersap
on 27 Jun 2020
Seems to be fixed in Google Play services 20.26.12 (120400-317812943). I updated to this version yesterday and today's exposure checks show the number of keys correctly. (Exposure checks performed before the update still show '0').
maurice-w
on 30 Jun 2020
Thanks for updating. When some more people have confirmed the Update, we will close the issue.
jakobmoellersap
on 30 Jun 2020
I also got the new play services, which seem to be marked as beta, but for me the issue still persists, which is 'weird'.
The dialog now shows the version in the bottom of the screen though, 202612000 is the displayed version as of now on my phones, which seems to reflect the play services version of 20.26.12.
DooMMasteR
on 30 Jun 2020
@DooMMasteR If the actual matching had been done with the "old" Play Services, the "new" Play Services would still show 0 (because they simply read the values from a database), so maybe wait for the next matching tomorrow.
mh-
on 30 Jun 2020
Seems to be fixed... Yay
You where correct, the checks are stored wrong, so the update just fixed newer entries...
This play service update ist marked as Beta for me, so rollout will probably still need some time, but this issue can or could be closed pretty soon now.
DooMMasteR
on 30 Jun 2020
Seems to be fixed... Yay
You where correct, the checks are stored wrong, so the update just fixed newer entries...
This play service update ist marked as Beta for me, so rollout will probably still need some time, but this issue can or could be closed pretty soon now.
It's fixed for me as well and I'm also using beta play services.
tomjschwanke
on 1 Jul 2020
Nothing on my Android 6.0.1 Sony Z3 device. Google Play Services still at ver. 20.21.17.
But the button "Überprüfung auf mögliche Begegnungen" has now disappeared.
Hoping for a speedy Google-update.
jmbaldwin
on 1 Jul 2020
Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?
dee8een0
on 1 Jul 2020
Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?
This issue is not about key-exchanges, they can be easily be confirmed with any other bluetooth device (yes, even a PC).
fdellwing
on 1 Jul 2020
At least you cannot be sure it worked :-( the situation is kind of sad in
itself and should have been covered by the simplest of test, but apparently
it was not.
This is the real worrying part here, Google released this API without any
suitable (at least apparent) kind of testing. The fact that it is not just
a view but also a controller/model issue, makes this really, "not good".
On Wed, Jul 1, 2020 at 9:55 AM dee8een0 notifications@github.com wrote:
Does this mean the key-exchange did not work for the last two weeks?
Is it possible for the user to verify this without logcat?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-652257411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABR7PJXOTXSAOA5JKCO6H3RZLTXFANCNFSM4OHNUP3Q
.
DooMMasteR
on 1 Jul 2020
the situation is kind of sad in itself and should have been covered by the simplest of test, but apparently it was not. This is the real worrying part here, Google released this API without any suitable (at least apparent) kind of testing. The fact that it is not just a view but also a controller/model issue, makes this really, "not good".
On my device, the list of verifications is unsorted (all meanwhile seven days are shown in random order), and when you scrolled down and opened a verification there and then go back, you are again on top of the list.
This observation strengthens the feeling that this UI has been developed under high pressure and with little testing.
jkrwdf
on 1 Jul 2020
This observation strengthens the feeling that this UI has been developed under high pressure and with little testing.
Also doesn't work well with dark mode/themes. I can't read anything inside the 'bars'. They're just white with white text.
treysis
on 1 Jul 2020
but the fact, that the checks done before, are not affected by the fix also shows, that even model and controller are or at least where somewhat flawed :-(
I guess Google failed on their part here, which does not enhance the trust in the APi as a whole.
Also: Does Google have any plans to open source the implementation on their end or is it to messy to publicize?
DooMMasteR
on 1 Jul 2020
"Überprüfung auf mögliche Begegnungen" is now available, after installation of google-play-service beta 20.26.13 (120408-319035724).
The history of exposure checks was not available to me before the update to beta version.
Also my history only goes back till 28. june. In contrast to that CWA states "14 von 14 Tagen aktiv".
dee8een0
on 1 Jul 2020
"Überprüfung auf mögliche Begegnungen" is now available, after installation of google-play-service beta 20.26.13 (120408-319035724).
For me, the appearance of this menu item was not related to a play services update.
Did not have it last week with 20.21.17, but have it since Monday with the same 20.21.17.
I assume this is controlled by a feature flag gradually rolled out to the accounts.
The history of exposure checks was not available to me before the update to beta version.
Also me history only goes back till 28. june. In contrast to that CWA says "14 von 14 Tagen aktiv".
Did you scroll through the entire list? As written, the list is not sorted by day but appears random (but stable), and as I just found out, the order even changes when switching the device language from DE to EN.
jkrwdf
on 1 Jul 2020
For me, the appearance of this menu item was not related to a play services update.
Did not have it last week with 20.21.17, but have it since Monday with the same 20.21.17.
Screenshot before update with 20.21.17 google-play-service:
Screenshot after update to beta 20.26.13 google-play-service:
Did you scroll through the entire list? As written, the list is not sorted by day but appears random (but stable), and as I just found out, the order even changes when switching the device language from DE to EN.
For me the list appears to be ordered by date:
Disclaimer:
This is not my daily driver. I have two phones. I use the one with the beta update for trying stuff.
dee8een0
on 1 Jul 2020
As I have stated before, this feature seems to be distributed on others paths or at least not exclusively with the Play Service updates.
For me just resetting the phone (Play Services stayed the same) made the menu disappear.
DooMMasteR
on 1 Jul 2020
The Update is delivered via GMS which is automatically updated on your device independent from the Play Store Version.
jakobmoellersap
on 1 Jul 2020
which makes the Version displayed at the bottom useless :-1:
I have 2 phones, both have the same version, as displayed at the bottom of the COVID-API screen, but one has the menu, the other does not have it (but had it before, on an older version).
DooMMasteR
on 1 Jul 2020
The Update is delivered via GMS which is automatically updated on your device independent from the Play Store Version.
Yes, but the appearance of the menu doesn't seem to be related to the PlayServices version, neither.
treysis
on 1 Jul 2020
I assume this is controlled by a feature flag gradually rolled out to the accounts.
This.
mh-
on 1 Jul 2020
in that case, it is buggy as hell because I use the same account on my devices...
but let's see where this goes, at least we now seem to have a paved road to useful information in the future.
P.S: some of my friends report that they just got the menu and the chaos ordering of the list is the there for everyone so far, so there is at least some consistency in it after all.
DooMMasteR
on 1 Jul 2020
Just a quick update. Sony Z3 Android 6.0.1 received an update to Google Play Services yesterday, now GPS is 20.24.14.
CWA threw a Google API (10) error, after restarting the mobile CWA threw a Google API (39508) error.
Still no keys visible.
jmbaldwin
on 4 Jul 2020
On my mother's phone, ist seems to have stopped working, since the last update of Google Play Services the phone does not send any beacons.
Rebooting the phone and such do not fix it.
The phone is a Xiaomi Mi A2 lite with Android One 10
DooMMasteR
on 4 Jul 2020
Same issue on Google Pixel 2 XL (0 keys) with the Android 11 Beta and latest Play Services
Here is the exported beautified log file: data.json.zip
1.) 0 Keys for every submission
2.) multiple calls to the API in the same minute every day...
Spacefish
on 5 Jul 2020
I may have found the issue:
There is a shared preference which stores the last time the app fetched keys from the server.. When fetching keys it tries to fetch the keys since the day stored in that variable up to now..
It is only set once via: LocalData.lastTimeDiagnosisKeysFromServerFetch(...);
here: https://github.com/corona-warn-app/cwa-app-android/blob/51f2c691794e6aa73a4cbc72be20b49068f56919/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/transaction/RetrieveDiagnosisKeysTransaction.kt#L188
it´s set to the value stored in "lastFetchDateForRollback"
however lastFetchDateForRollback is only initialized from LocalData.lastTimeDiagnosisKeysFromServerFetch(); here: https://github.com/corona-warn-app/cwa-app-android/blob/51f2c691794e6aa73a4cbc72be20b49068f56919/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/transaction/RetrieveDiagnosisKeysTransaction.kt#L206
so if LocalData.lastTimeDiagnosisKeysFromServerFetch() becomes 0 (which it is on default install or if one fetch fails).. The app always tries to fetch all keys for the past 14 days and submit them to the API, which fails due to rate limiting.. Thereby breaking the whole app..
This was probably introduced by the change that made the fetching more "failure tolerant"...
Maybe I missed something here, but this how it looks to me and it would explain the logs we see (0 keys, due to old packed being submitted which don´t contain keys and then aborting due to rate limit)...
Spacefish
on 5 Jul 2020
@Spacefish To confirm that this is caused by rate limiting, do you have access to logs?
This is how rate limiting shows up in the log on my device: https://github.com/kbobrowski/en-i13n/issues/1#issuecomment-653920278 (ApiException: 39508)
mh-
on 5 Jul 2020
I doubt this is rate limiting. The same 0 keys occurs with SwissCovid so they would have made the same mistake?
treysis
on 6 Jul 2020
I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".
So it seems a new version of "Google Play Services" might be a solution to this problem.
I attached a screenshot of "before" and "after" I installed the beta version of "Google Play Services".
I use Android 10 on a Pixel 3 device.
MartinKolbAtWork
on 7 Jul 2020
I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".So it seems a new version of "Google Play Services" might be a solution to this problem.
@MartinKolbAtWork
Which version do you have? I am also subscribed to Google Play Services Beta but still get the 0 keys every day.
Device: BQ Aquaris X2 Pro
Android Version: 10
Google Play Services Version: 20.24.13
App Version: 1.0.4
nichu42
on 7 Jul 2020
I also had "0" in "Anzahl der Schlüssel" every day since I installed the app.
Yesterday I switched to the beta version of "Google Play Services".
As of today a have the first time that "Anzahl der Schlüssel" is above "0".
So it seems a new version of "Google Play Services" might be a solution to this problem.@MartinKolbAtWork
Which version do you have? I am also subscribed to Google Play Services Beta but still get the 0 keys every day.
Device: BQ Aquaris X2 Pro
Android Version: 10
Google Play Services Version: 20.24.13
App Version: 1.0.4
I have:
Device: Pixel 3
Android Version: 10
Google Play Services Version: 20.26.13
App Version: 1.0.4
MartinKolbAtWork
on 7 Jul 2020
Seems to be fixed for me with version 15202902002. Sorting is still not correct. I've cleared the history, maybe sorting will work from now on. 
nilsalex
on 12 Jul 2020
Thanks for the update. As rollout of Play Service updates takes a couple of days (up to 14), the issue should be resolved over time for all users. And since it is now resolved for the issue creator, we'll close the issue. If it persists with the version mentioned in https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-657220680 , please open a separate issue.
tkowark
on 16 Jul 2020
Seems to be fixed for me with version 15202902002.
I couldn't find this version number for Google Play services and I also have a Samsung Galaxy A50.
I did however pull the 20.26.14 beta apk from https://www.apkmirror.com/apk/google-inc/google-play-services/google-play-services-20-26-14-release/ and installed it manually. For my device it is listed under 202614037 on apkmirror.
The version shown is 20.26.14 (120400-320008519).
I'm now seeing Number of keys 1960 for each entry of the server sync performed today (and Number of matches 0). I'm happy to see a non-zero value for the key count and a zero value for the count of matches!
For any previous days, the Number of keys is still showing 0. Hopefully this is just a display issue, but I am left wondering whether previous days actually did execute properly.
MikeMcC399
on 16 Jul 2020
@MikeMcC399 yes it did work correctly, see https://github.com/corona-warn-app/cwa-app-android/issues/744#issuecomment-650532041
mh-
on 16 Jul 2020
At the bottom of Exposure Notifications
(Settings -> Google -> COVID-19 exposure notifications)
I can see Version 15202902002 when Google Play services is at Version 20.24.14 (040408-319035315). On the same device, Samsung Galaxy A5, when Google Play services was still at Version 20.21.17 (040408-316502805) the exposure notifications screen was not displaying any version number.
Unfortunately the Google Play services release notes on https://developers.google.com/android/guides/releases don't mention COVID-19 exposure notifications at all so it's difficult to know exactly what the prerequisites are to get the Number of keys to display correctly. I re-read the whole of this thread and still couldn't work it out. Is a certain minimum version of Google Play services 20.nn.nn necessary for correct display of Number of keys? Is the version shown in COVID-19 exposure notifications e.g. Version 15202902002 directly tied to the version of Google Play services or can it change independently of the Google Play services version?
Edited:
My questions about versions are answered in part in https://github.com/corona-warn-app/cwa-app-android/issues/894 .
MikeMcC399
on 16 Jul 2020
As you can see in my log-file below the keycount is 0 for all days (exept 25/26.07.2020). The CWA was installed on the rollout day, What you can also see is that the logs do not cover all the past 14 days (please note: my phone was carried around a lot during all the 14 days and no logs for several days are very unlikely).
Question: The keycount should be the same number for everyone each day as the keycount number should be equal to the number of postive-reports each day. Can someone confirm?
jeschket
on 26 Jul 2020
@jeschket
As you can see in my log-file below the keycount is 0 for all days (exept 25/26.07.2020).
As you noted in your edited comment, the newest risk updates have non-zero values, and this closed thread is about the problem of zero values, so the thread is not really relevant to your question.
I'm sorry that I don't know the explanation about varying "Number of keys" for the same day. If you don't get an answer here, you might try starting a new issue.
MikeMcC399
on 27 Jul 2020
As you can see in my log-file below the keycount is 0 for all days (except 25/26.07.2020).
@jeschket
I think this means that you had old Google Play Services that would incorrectly record "0" until 24 July.
And now you have new Google Play Services, and everything is fine.
As explained here, searching for matches worked properly before as well. Only the recording of the number of keys was incorrect.
mh-
on 27 Jul 2020
@jeschket
Question: The keycount should be the same number for everyone each day as the keycount number should be equal to the number of postive-reports each day. Can someone confirm?
I went back and read some of the documentation
https://developers.google.com/android/exposure-notifications/exposure-notifications-api and
https://github.com/corona-warn-app/cwa-documentation/blob/master/solution_architecture.md
and my understanding is that the risks are calculated using historical data split up by days. So the number of keys depends on what keys were relevant for a risk calculation on a particular day. (If I got this wrong, please feel free to correct me!)
https://github.com/corona-warn-app/cwa-documentation/blob/master/cwa-risk-assessment.md explains it nicely with an example.
The Google Exposure Notifications UI shows only the timestamp that the keys were received from the server, but it doesn't display the historical time period that the keys apply to. That would perhaps be a good enhancement suggestion for Google to add the missing information.
Update
This is now described in the FAQs.
MikeMcC399
on 28 Jul 2020
The Problem "Anzahl der Schlüssel 0" is back.
App Version 1.2.1
COVID-19-Benachrichtigungen Version 15202902003
Google Play-Dienste Version 20.26.14
I checked the numbers every day since July 23. Until yesterday there were 14 different numbers but today (timestamp August 17, 2020 09:39) all 14 numbers are 0.
kereng5
on 17 Aug 2020
All systems green here.
Timestamp August 17, 2020, 3:30, shows lots of Keys checked, thankfully no match.
Specs:
Sony Xperia Z3 compact w/ Android 6.0.1
App Version 1.2.1
COVID-19-Benachrichtigungen Version 16203302004
Google Play-Dienste Version 20.26.14 (040306-320008519)
jmbaldwin
on 17 Aug 2020
@kereng5 could you export and share your exposure log? :)
daimpi
on 17 Aug 2020
I exported what I think is the "exposure log" and got a .json-File which is not accepted here, so I saved it as .txt.
I did not activate the "priorisierte Hintergrundaktivität" but trigger the exposure check every day by looking into the app.
My phone is Motorola G3 with Android 6.0.1.
kereng5
on 17 Aug 2020
BTW, this app (“Warn-App-Companion”) https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion might also be helpful for debugging, as it will show how many keys can be downloaded. (It needs root access, though.)
mh-
on 17 Aug 2020
Thank you, mh!
But granting root access seems too difficult for me.
kereng5
on 17 Aug 2020
@kereng5
This is indeed very weird… I just spot checked a few hashes from your August 17th entries and compared them with mine and they were identical, just for me keyCount was always greater than 0.
Could you maybe check if the same behavior occurs again tomorrow?
My device:
Samsung Galaxy S8 (Android 9)
CWA 1.2.1
ENF v. 15202902003
Google Play Services: 20.26.14
- My log: me-17.zip
daimpi
on 17 Aug 2020
@kereng5 I modified the WarnAppCompanion app https://play.google.com/store/apps/details?id=org.tosl.warnappcompanion - starting with version 1.1.1, it will always least try to download the Diagnosis Keys, also without root access.
This might help to check whether a firewall prevents downloading them.
mh-
on 18 Aug 2020
Could you maybe check if the same behavior occurs again tomorrow?
Same as yesterday.
all-exposure-checks-2.txt
kereng5
on 18 Aug 2020
version 1.1.1, it will always least try to download the Diagnosis Keys, also without root access.
I got the Diagnosis Keys. The numbers are 2500 for August 4, then 2325, 2095, 1935, 1820, 1780, 1575, 1450, 1190, 890, 680, 435, 285, 20, 0. The last one (0) for today.
How do I understand the 20 for August 17? I guess only 4 of yesterday's 56 reporters transferred their last Diagnosis Key to the server. And the 285? 56*5=280, so only one Diagnosis Key is from the 33 who reported positive on August 16, or some of the 56 had no old keys. (Data source https://micb25.github.io/dka/ )
kereng5
on 18 Aug 2020
@kereng5 Yesterday's keys (17 Aug 2020) can only be uploaded today. So they are part of the hourly packages that have been published today. As of right now I already see 50, so 50/5==10 users have already uploaded keys for yesterday.
mh-
on 18 Aug 2020
@mh- I'm not so sure that @kereng5 is missing any packages/downloads: when I was comparing hashes yesterday I found the same hashes as for my checks, even for the most recent package… I don't think that this would be possible w/o the package actually being downloaded. This seems to me to be a displaying error like we had before ENF 1.5…
daimpi
on 18 Aug 2020
I can see key numbers again. all-exposure-checks-3.txt
Yesterday I noticed that there was not much internal memory free in my phone, and I deleted some pictures from camera and WhatsApp. I am not convinced that this is the reason. I would expect an error message if there is no space for the Diagnosis Keys.
Do the Diagnosis Keys need less space in companion app? There seems to be less redundancy.
edit: there is a new Version: 16203302004
amatenki had it already 2 days ago. I found it now on my phone.
kereng5
on 19 Aug 2020
@kereng5 I really don't know, in Warn-App-Companion I just download the Diagnosis Keys to RAM. The data downloaded from the server is probably also cached somewhere, but I think that cached data might be deleted automatically in low-disk-memory situations.
One major difference is that Warn-App-Companion makes no effort to download anything in the background, it only works when you start the app in the foreground. An OS usually gives priority to the foreground application.
mh-
on 19 Aug 2020
Related issues
michaelwingender
·
3Comments
marceljay
·
3Comments
schuhmi2
·
3Comments
Magoli1
·
3Comments
Diapolo
·
3Comments
Most helpful comment
Ok, I think I can confirm that the V1.0.4 Corona Warn Android app
does warn when RPI/TEK matching was positive.
Tested on Android 7.0, Google Play service version 20.21.17 (040306-316502805).
I inserted a lot of RPIs matching 1 Diagnosis Key into the GMS database, and "Check details" shows this:
So apparently, instead of showing all keys that were used for matching, the screen shows the "Number of matches" twice.
Excerpt from logcat:
The app shows this:
(note that I fiddled with the device's clock while doing this, so the "0 days since last encounter" is not necessarily a bug)