Closed nilsalex closed 4 years ago
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?
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.
Exact same issue with Android 6.0.1 running on Sony Xperia Z3.
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.
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.
Android 8.1.0 does not have the button "Überprüfung auf mögliche Begegnungen". The user cannot see the number of keys exchanged.
We are investigating and will update here once we analysed the subject accordingly.
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.
Moto One
Android 10
1. Juni 2020 Patch
1. Mai 2020 Google Play
Same issue here
Xiaomi Mi 8
MIUI 11.0.4.0
Android 10
1. April 2020 Patch
Play Services 20.21.17 (120400-316502805)
Is there anyone that has the menu on the phone, and where there the "number of keys" is more than 0 for any check?
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.
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.
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.
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)
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 ?
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 :)
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
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.
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 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.
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...
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?
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.
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'.
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
6.0.1
(stock Android of device, not rooted)20.21.17
(040308-316502805)
3.4.0-14131106 from 06 Aug 2018
, Build number: MMB29M.G900FXXU1CRH1
com.google.android.gms [202117018] [20.21.17 (040308-316502805)] [Container]
com.google.android.gms.nearby_en [v202304013]
Android settings
> Google
> (loads web view of my Google account on Android)Benachrichtigungen zu möglicher Begegnung mit COVID-19-Infizierten
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.
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.
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)
Ok, so Google will have to fix this... Can only be a matter of days. Thx for all the testing on your end @mh-
I will keep updating the discussion once I have more information on the issue solution on Google side. Thanks for your patience, everyone.
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').
Thanks for updating. When some more people have confirmed the Update, we will close the issue.
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 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.
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.
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.
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.
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?
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).
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 .
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.
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.
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?
"Ü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".
"Ü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.
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.
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.
The Update is delivered via GMS which is automatically updated on your device independent from the Play Store Version.
Avoid duplicates
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