Cwa-app-android: No beacons sent on Asus Nexus 7 (2013) / Android 6.0.1
I was curious about the data that is sent over the air, so I extended my test-app for receiving ble-data in order to be able to se the beacons sent by this app.
With the app I can see beacons sent out by some device (currently only one of my neighbors has the app installed)
I then installed the app to my old tablet (Asus Nexux 7 (2013), Android 6.0.1). Installation succeeded without any errors.
Expected behaviour
But I can not see any beacons sent by this device.
I then hooked the tablet to my development machine to have a look at the logs and fond the following:
06-19 17:51:15.561 2835-2835/? I/ExposureNotification: BleDatabaseWriter.writeBleSighting, id=2EF48754ABD44A88144A5B555E640095 [CONTEXT service_id=236 ]
06-19 17:51:15.614 2835-2835/? I/ExposureNotification: Scan device 5C:F3:3D:7E:67:93, type=1, id=2EF48754ABD44A88144A5B555E640095, raw_rssi=-83, calibrated_rssi=-89, meta=5C57DF85 [CONTEXT service_id=236 ]
06-19 17:51:15.614 2835-2835/? I/ExposureNotification: Reschedule interval too short, timeMsSinceLastSchedule=9701 [CONTEXT service_id=236 ]
06-19 17:51:15.614 2835-2835/? I/ExposureNotification: BleDatabaseWriter.writeBleSighting, id=2EF48754ABD44A88144A5B555E640095 [CONTEXT service_id=236 ]
06-19 17:51:15.626 2835-2835/? I/ExposureNotification: Scan device 5C:F3:3D:7E:67:93, type=1, id=2EF48754ABD44A88144A5B555E640095, raw_rssi=-83, calibrated_rssi=-89, meta=5C57DF85 [CONTEXT service_id=236 ]
06-19 17:51:15.627 2835-2835/? I/ExposureNotification: Reschedule interval too short, timeMsSinceLastSchedule=9705 [CONTEXT service_id=236 ]
06-19 17:51:15.627 2835-2835/? I/ExposureNotification: BleDatabaseWriter.writeBleSighting, id=2EF48754ABD44A88144A5B555E640095 [CONTEXT service_id=236 ]
06-19 17:51:15.631 2835-2835/? I/ExposureNotification: Scan device 5C:F3:3D:7E:67:93, type=1, id=2EF48754ABD44A88144A5B555E640095, raw_rssi=-83, calibrated_rssi=-89, meta=5C57DF85 [CONTEXT service_id=236 ]
06-19 17:51:15.631 2835-2835/? I/ExposureNotification: Reschedule interval too short, timeMsSinceLastSchedule=9701 [CONTEXT service_id=236 ]
06-19 17:51:15.631 2835-2835/? I/ExposureNotification: BleDatabaseWriter.writeBleSighting, id=2EF48754ABD44A88144A5B555E640095 [CONTEXT service_id=236 ]
Not sure if it helps ...
Technical details
- Mobile device: Asus Nexus 7 (2013)
- Android version: 6.0.1
(Installing on a Pixel3a also succeeded without errors and there I can see the generated beacons.)
sqrt-1764
All 16 comments
Asus Nexus 7 (2013) uses a Qualcomm Atheros WCN3660 WLAN a/b/g/n, Bluetooth 4.0 (BR/EDR+BLE) chipset. The hardware/driver does not support the Bluetooth Low Energy "Peripheral mode",, which is necessary to send the "Exposure Notification" beacon .
You may check this with Nordic Semiconductors nRF Connect;
https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp
A lot of Mobiles and Tablets from rhe early 2010's does't support "Peripheral mode". Thats for example stated here: https://source.android.com/devices/bluetooth/ble#device-modes
cschweers
on 19 Jun 2020
In the case that the device does not support required modes, it should generate an error-message, preferably by Google, but if they don't do it, it could be done through the app.
tomjschwanke
on 19 Jun 2020
it could be done through the app.
I don't think the app should attempt to do this, because it is completely unaware of the Bluetooth interface, which is handled only by the Google Play Services.
Note that you can apparently still use the device with this app to receive beacons (and be warned if another user reports their infection) - the log file shows that another devices sent the RPI 2EF48754ABD44A88144A5B555E640095.
mh-
on 20 Jun 2020
could it be even mobile phone Nexus 5 is not compatible as of
https://altbeacon.github.io/android-beacon-library/beacon-transmitter-devices.html
Is there a simple way to tell for the end user?
gizmo21
on 20 Jun 2020
Hhm perhaps yes with Locate beacon app:
gizmo21
on 20 Jun 2020
Oh, great!
I think you have just solved my problem, or rather identified the error as a hardware failure on my smartphone.
@cschweers
The hardware/driver does not support the Bluetooth Low Energy "Peripheral mode", which is necessary to send the "Exposure Notification" beacon.
"Peripheral mode" is indispensable for the CWA?!
@tomjschwanke
I agree, a diagnostic/test function would be great!
The discussion on "test function" has been moved to https://github.com/corona-warn-app/cwa-wishlist/issues/5.
I had downloaded the app:
https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp
Checks look at screenshots
As a result, my smartphone is not CWA-compatible?!
Oh Prima!
ich glaube ihr habt gerade mein Problem gel枚st, bzw. den Fehler als Hardware-Fehler auf meinem Smartphone identitfiziert.
@cschweers
The hardware/driver does not support the Bluetooth Low Energy "Peripheral mode",, which is necessary to send the "Exposure Notification" beacon .
"Peripheral mode" ist f眉r die CWA unvervzichtbar?!
@tomjschwanke
Das sehe ich ebenso, eine Diagnose/Testfunktion w盲re prima!
Die Diskussion zu "Testfunktion" wurde unter https://github.com/corona-warn-app/cwa-wishlist/issues/5 verschoben.
Die App hatte ich mir heruntergeladen:
https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp
Checks siehe Screenshots
Damit ist im Ergebnis mein Smartphone nicht CWA-tauglich?!
JProof
on 20 Jun 2020
I wasn't aware of that detail and can now confirm that the Nexus 7 (2013) does not support "peripheral mode" and therefore is unable to send that beacons because of that limitation of the hardware.
I would not support @tomjschwanke to say that the app is useless then. But it only can do half of the job. The app can not warn other users, but the user of this app still can be warned if he or she had "contact" to infected people.
But in this case I would like to see the option to report an infection to be disabled in the app as it is useless in that case. No beacons were sent and therefore there are no other users out there that could be warned.
In that case it the sharing option should be replaced by a note that explains this fact.
sqrt-1764
on 20 Jun 2020
I agree that from a technical point of view, it would be nice to be informed that the device used is only doing half the work.
But from a social point of view I prefer that Jane/Joe Average have the same user experience regardless of the technical limitations of the device used, especially since only a small percentage of the devices used will have that limit. To get the widest possible user base for this app, the current implementation is certainly the best compromise.
cschweers
on 20 Jun 2020
Hallo @sqrt-1764
Kann ich die Information irgendwo nachlesen?
" to say that the app is useless then. But it only can do half of the job. The app can not warn other users, but the user of this app still can be warned if he or she had "contact" to infected people."
Ist das ein in der CWA einprogrammierter Use-Case?
Use-Case:
Mein Smartphone kann Beacons von anderen Smartphones empfangen
(alle Voraussetzungen auf meinen Smartphone zum empfangen von Beacons sind vorhanden und eingeschaltet)
Mein Smartphone kann keine Beacons senden (weil z.B. "peripheral mode NOT supported")
Annahme 1: meine positiv-meldung
Sollte ich infiziert sein und gebe my TAN in mein Smartphone ein, bekommen Smartphones, deren Beacons sich auf meinem Smartphone befinden, eine Nachricht.
Annahme 2: positiv-meldung auf einem anderen smartphone
Ich w眉rde 眉ber eine Infektion nicht informiert werden, da das andere Smartphone zu keinem Zeitpunkt ein Beacon von mir empfangen hat und somit nicht wei脽, dass mein Smartphone in seiner N盲he war.
Wenn die beiden Annahmen/Unterstellungen der einprogrammierten L枚sung richtig sind, dann w眉rde die Verwendung der App f眉r "mein" Smartphone Sinn machen.
Weiss jemand ob dieses Verhalten ("Do the half Job") bereits dokumentiert ist. Falls nicht, w眉rde ich ein Doku-Ticket er枚ffnen
"The app can not warn other users, but the user of this app still can be warned if he or she had "contact" to infected people."
"But in this case I would like to see the option"
Hello @sqrt-1764
Can I read the information somewhere?
" to say that the app is useless then. But it only can do half of the job. The app can not warn other users, but the user of this app still can be warned if he or she had "contact" to infected people."
Is this a use case programmed into the CWA?
Use case:
My smartphone can receive beacons from other smartphones
(all requirements on my smartphone to receive beacons are available and enabled)
My Smartphone cannot send beacons (because e.g. "peripheral mode NOT supported")
Assumption 1: my positive message
If I am infected and enter my TAN in my smartphone, smartphones whose beacons are on my smartphone will receive a message.
Assumption 2: positive message on another smartphone
I would not be informed about an infection, because the other smartphone has never received a beacon from me and therefore does not know that my smartphone was near it.
If the two assumptions/subconceptions of the programmed solution are correct, then using the app for "my" smartphone would make sense.
Does anyone know if this behavior ("Do the half job") is already documented? If not, I would open a docu-ticket
"The app can not warn other users, but the user of this app still can be warned if he or she had "contact" to infected people."
"But in this case I would like to see the option"
JProof
on 20 Jun 2020
@cschweers: Well, I might behave differently if I think that I informed all my contacts about my infection when the device was not capable of doing so. I disagree with the "social" argument. The fact that the app does not all the things that it promises to do IMHO must not be hidden to the user - 100% transparency.
Although this affects only a very small portion of the user base (infected users that use those old devices) - sending useless data to the server does not make sense to me. So the corresponding option to send infection informatio has to be disabled in that cases.
sqrt-1764
on 20 Jun 2020
@JProof (Although I am german I limit my answer to english as it is the language of developers and makes the anwer shorter ;-) )
Regarding Assumption 1:
AFAIR when publishing an infection the device sends all his last ids to the central server where the server now publishes that information to all the other clients. Then the clients can detect the contact to an infected person locally on their device and inform the user accordingly.
But this is useless when there were no beacons sent in the past. Then no device out there will have the information that they were in proximity of the device of the infected person that reports his or her infection.
But in no case "your" device contacts any other device to inform them about your infection. This is impossible due to the design of the process that otherwise would violate the privacy.
Regarding Assumption 2:
AFAIK the risk level is computed only from the received beacons on the device. So the inablility to send beacons does not affect this. With this limitied functionality you will still be warned if you were in proximity of a device from an infected user. This half of the functionality should still work.
But you can not warn others due to the inability to send beacons.
sqrt-1764
on 20 Jun 2020
@sqrt-1764 Thank you for your comments and please excuse my ticket-hijacking
I'm not going to open an extra ticket for the derivations. This ticket already contains all relevant informations. ..I hope
JProof
on 20 Jun 2020
Maybe some people would be interest how swisscovid implements BLE checking:
https://github.com/DP-3T/dp3t-app-android-ch/blob/master/app/src/main/java/ch/admin/bag/dp3t/util/ENExceptionHelper.java#L41-L60
https://github.com/DP-3T/dp3t-app-android-ch/blob/master/app/src/main/java/ch/admin/bag/dp3t/util/ENExceptionHelper.java#L86-L88
Note that swisscovid checks for MultipleAdvertisementSupported, meanwhile the discussion here is about Peripheral mode. I do not know how they correlate or which is correct.
Interesting side note to isMultipleAdvertisementSupported:
MichaelPFrey
on 30 Jun 2020
Note that swisscovid checks for MultipleAdvertisementSupported, meanwhile the discussion here is about Peripheral mode. I do not know how they correlate or which is correct.
Since there are use cases for BLE advertisements outside Exposure Notifications, e.g. in physical access control, it absolutely makes sense that Google enables EN beacon transmission only if the device supports multiple advertisements. Otherwise they would block all other use cases.
mh-
on 30 Jun 2020
To channel discussion about unsupported phones to a single issue, we will close this one here and refer to #688 for the time being. I will also add a note about the comment regarding Swiss Covid in the linked issue for reference.
tkowark
on 1 Jul 2020
Note that swisscovid checks for MultipleAdvertisementSupported, meanwhile the discussion here is about Peripheral mode. I do not know how they correlate or which is correct.
The Fairphone 2 / Fairphone OS is also indicating no support for MultipleAdvertisement:
06-28 17:06:54.186 3370 22809 I ExposureNotification: Utils#isSupported enabled=true, isDeviceSupported=true, isBluetoothSupported=true, BluetoothAdapter.isMultipleAdvertisementSupported=false [CONTEXT service_id=236 ]
gollub
on 1 Jul 2020
Related issues
Alestrix
路
3Comments
zeus24
路
3Comments
HuiiBuh
路
3Comments
marceljay
路
3Comments
tegutistgut
路
3Comments
Most helpful comment
In the case that the device does not support required modes, it should generate an error-message, preferably by Google, but if they don't do it, it could be done through the app.