User generated list of incompatible devices lacking BLE "Peripheral mode"

gizmo21 commented 4 years ago

CWA app has requirement of Android 6 and Bluetooth Low Energy, but that alone is not enough to get the full functionality. To send the "Exposure Notification" beacon your device not only needs BLE but also a special feature called "Peripheral mode". That way you can never warn others if you are infected, cause your device never sends IDs to other phones. But you can get warned, cause your device is able the record others phones IDs. Even with lack of that "Peripheral mode" on your device the CWA seems to work flawlessly from user standpoint cause neither google play service nor CWA shows the limitation that it is only working one way.

Users can test their devices with this app https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp

@JProof provided screenshots here https://github.com/corona-warn-app/cwa-app-android/issues/674#issuecomment-646949156 Selecting device information and look for Peripheral mode supported - NO

Samsung A7 (SM-A700F)

Internal Tracking ID: EXPOSUREAPP-1667

gizmo21 commented 4 years ago

LG Google Nexus 5

8f617cd9-93f9-49f8-bc2c-f6a49cf98cc1

sqrt-1764 commented 4 years ago

Instead of generating a compatibility list (that would have to be maintained) I would prefer to disable the option to send the infection report to the server in that case as it is useless (as already commented in #674 ) and instead replace it with a note that explains this. The avaliablility of the "peripheral mode" can be detected programmatically and the replaced note informs the user of anything that needs to be known ...

gizmo21 commented 4 years ago

As I understood, the devs atm had no direct access to BT but only the GAProtocol, so perhaps no quick solution available as they (correctly) say it's Google job to warn or even disable protocol for those devices. That's why I thought users soon should at least be able to check and inform others that there are older devices out there that SEEM to be fully compatible but aren't. And as a separate thread so the other threads aren't spammed with "this device too" .

But devs please correct me and perhaps close this issue if these assumptions are wrong.

sqrt-1764 commented 4 years ago

@gizmo21 Well, the fact that the device supports "peripheral mode" or not can be detected programmatically without the help of the google library (See nRfConnect that does this). So the problem can easily be solved on the device without the need of manually maintaining lists that nobody will ever read. ;-)

treysis commented 4 years ago

That way you can never warn others if you are infected, cause your device never sends IDs to other phones. But you can get warned, cause your device is able the record others phones IDs.

Sorry, but I don't understand that sentence. Why would the phone need to send over BLE that I am infected? This should only be sent to the server. It is enough to act as a beacon and record IDs that I observe myself.

MilesTeg97 commented 4 years ago

FYI: https://altbeacon.github.io/android-beacon-library/beacon-transmitter-devices.html

(Last Update September 13, 2018)

gizmo21 commented 4 years ago

That way you can never warn others if you are infected, cause your device never sends IDs to other phones. But you can get warned, cause your device is able the record others phones IDs.

Sorry, but I don't understand that sentence. Why would the phone need to send over BLE that I am infected? This should only be sent to the server. It is enough to act as a beacon and record IDs that I observe myself.

Well I never wrote that BLE sends the infection message, but BLE sending your IDs needs peripheral mode. If your device can't send IDs and you are infected and send that information to the server, the other phones will get server information about infected IDs but as your phone did not send it, other phone won't match IDs and so don't get informed

BudickDa commented 4 years ago

So people having the app installed, but can not send IDs, thus thinking they are helping by having the app installed, but in reality having the app installed for no reason?

treysis commented 4 years ago

@BudickDa As I understood now: yes.

MilesTeg97 commented 4 years ago

@BudickDa: From my understanding this might in theory still be possible if all other users have active beacon transmissions. But that's a wild guess and I have no idea if this is/can be implemented in a secure way at all.

gizmo21 commented 4 years ago

@devs it's nice to have a "FAQ" flag now, but it would be even nicer if there would be a statement if absence of "peripheral mode" really cripples the concept without informing the user in app/service.

pinkit-cwa commented 4 years ago

So people having the app installed, but can not send IDs, thus thinking they are helping by having the app installed, but in reality having the app installed for no reason?

@BudickDa: they can receive IDs and thus will be warned if they were close to an infected person (if that person did not have the same issue).

@cschweers: contrary to your current opinion on this expressed in https://github.com/corona-warn-app/cwa-app-android/issues/674 , I am convinced being transparent about this issue will help:

people would also be informed that their phone is still doing half of the job (which is much better than nothing)
people would know that there is an issue with their handset (not the corona warn app), and might be able to resolve it by switching to a different phone (eigene oder fremde Handyschublade)
if "corona warn" should in the future include some kind of feedback "confirmed receipt of a beacon" then people would wonder why other people do not see their phone

I am still searching for a suitable phone - the two I picked from my drawer are Samsung Galaxy Nexus (2011) and LG Nexus 5 (2013). Without apps like "Beacon Scope" I would not know and think everything is fine. With this information, I can improve the situation.

v1nc commented 4 years ago

So people having the app installed, but can not send IDs, thus thinking they are helping by having the app installed, but in reality having the app installed for no reason?

@BudickDa: they can receive IDs and thus will be warned if they were close to an infected person (if that person did not have the same issue).

@cschweers: contrary to your current opinion on this expressed in

674

, I am convinced being transparent about this issue will help:
* people would also be informed that their phone is still doing half of the job (which is much better than nothing)

* people would know that there is an issue with their handset (not the corona warn app), and might be able to resolve it by switching to a different phone (eigene oder fremde Handyschublade)

* if "corona warn" should in the future include some kind of feedback "confirmed receipt of a beacon" then people would wonder why other people do not see their phone
I am still searching for a suitable phone - the two I picked from my drawer are Samsung Galaxy Nexus (2011) and LG Nexus 5 (2013). Without apps like "Beacon Scope" I would not know and think everything is fine. With this information, I can improve the situation.

Looks like "Peripheral mode" can be enabled by the firmware/kernel. I tested this with an android q los build on hammerhead and "Peripheral mode" works.

gizmo21 commented 4 years ago

Looks like "Peripheral mode" can be enabled by the firmware/kernel. I tested this with an android q los build on hammerhead and "Peripheral mode" works.

@v1nc do you have more info, link to this firmware and is the downside "only one connection", mentioned in Comment # 83 in Google issue, fixed in that version or perhaps irrelevant for full CWA use? https://code.google.com/archive/p/android-developer-preview/issues/1570

BudickDa commented 4 years ago

If some users do not send IDs, they need to be informed about it in the app, so they can change their phone or can additionally use pen and paper.

Also: are there estimations how many devices are only working "half"? Is it 5 % or 50 %?

v1nc commented 4 years ago

If some users do not send IDs, they need to be informed about it in the app, so they can change their phone or can additionally use pen and paper.

Also: are there estimations how many devices are only working "half"? Is it 5 % or 50 %?

Use pen and paper for what?

Looks like "Peripheral mode" can be enabled by the firmware/kernel. I tested this with an android q los build on hammerhead and "Peripheral mode" works.

Do you have more info, link to this firmware and is the downside "only one connection", mentioned in Comment # 83 in Google issue, fixed in that version or perhaps irrelevant for full CWA use?

I tested it with this firmware

I could not verify yet, if scanning and advertising works at the same time. I assume its important for full CWA use. Maybe you could work around this with fast switching between scanning and advertising, but I dont think this is implemented.

pinkit-cwa commented 4 years ago

Which revision exactly? Because the latest does not seem to have "Peripheral mode" enabled.

After repartitioning as described in: https://forum.xda-developers.com/google-nexus-5/orig-development/repartition-nexus-5-repartition-t3844395 I succeeded to install lineage-17.1-20200613-UNOFFICIAL-hammerhead.zip and gapps pico v10 for ARM . I installed Corona Warn app and "BLE Scanner". BLE Scanner says "Bluetooth Smart supported YES" and "Advertiser mode supported NO", i.e. no change. Also, my other phone does not see beacons from Nexus 5.

pinkit-cwa commented 4 years ago

I have an update, but still no beacons:

"Beacon Scope" fails because "some other app might be sending beacons". If I disable exposure notification in CWA, then "Beacon Scope" app says that it now is able to send Exposure notification beacons.

My other phone still does not see those beacons, while it does see beacons from other phones, so I think "Beacon Scope" is wrong, the phone does not send, neither from CWA nor from "Beacon Scope".

pinkit-cwa commented 4 years ago

Hmm. I do see some beacons from Nexus 5 with 20200613 LOS installed. Sometimes. So CWA "peripheral mode" might work there - or not. Need to do further research.

BudickDa commented 4 years ago

If some users do not send IDs, they need to be informed about it in the app, so they can change their phone or can additionally use pen and paper. Also: are there estimations how many devices are only working "half"? Is it 5 % or 50 %?

Use pen and paper for what?

If my smartphone does not send IDs (https://github.com/corona-warn-app/cwa-app-android/issues/688#issuecomment-647159934) , I am "invisible" for other users so I need to keep track of my contacts in another way for the authorities to inform them (for example by writing them down if possible).

If users trust that the app does their contact tracing for them, but it doesn't, the manual contact tracing by the authorities could be more difficult. Because: If I think, I don't need to remember something, because my smartphone does it for me, I am more prone to not remember it.

In a nutshell: Users must be informed, if their app doesn't send IDs.

But I think this should be discussed in another (maybe wishlist?) issue.

tkowark commented 4 years ago

We are currently discussing how to best handle the creation of such a list.

For the time being, we want to concentrate discussions on a single issue (this one). So, for reference, we will close:

780 Fairphone
674 Asus Nexus

tkowark commented 4 years ago

For reference, the approach used by SwissCovid check BLE capabilities is mentioned here: https://github.com/corona-warn-app/cwa-app-android/issues/674#issuecomment-651531895

ArnoldSchiller commented 4 years ago

Huawai Y6P Android EMUI 10.1.0.128 MED-LX9N Modell 2020 - no Chance - GSF not installable. The old Samsung with Android 4.4. no chance and a newer Samsung J5 (2016) perhaps. LG 620 BT - no chance to get it work.

daimpi commented 4 years ago

@ArnoldSchiller has recently suggested that missing "peripheral mode" is not a problem with the hardware but rather that outdated Google Mobile Services (GMS) might be the reason why phones don't have have it. Based on that a solution for some devices might be a recent LineageOS build with up-to-date openGapps. Does anyone know whether that could work and/or has tried this?

pinkit-cwa commented 4 years ago

[...] for some devices might be a recent LineageOS build with up-to-date openGapps. Does anyone know whether that could work and/or has tried this?

I think I did. But maybe you see something I missed.

I have two phones with non-working peripheral mode: 1) Samsung "Galaxy Nexus" aka maguro

LineageOS 13.0-20180211-NIGHTLY (not that recent)
Android version 6.0.1
CWA
up-to-date "google play services" aka com.google.android.gms, Version 20.26.14 (040306-320008519)

ENF possibly receives beacons (can't tell as there are no statistics). ENF does not send beacons.

BeaconScanner can receive ExposureNotification frames, but not send due to missing Peripheral Mode. THis is not an issue of GSM, but seems to be an issue of hardware drivers not supporting peripheral mode.

2) I tested the same with a LG "Nexus 5" aka hammerhead with LineageOS 17 and OpenGapps. See my previous comments dated june 26 (above in this thread). Currently, this phone runs UBports, but I am willing to revert to some Android to test this further.

Do you think I missed something?

daimpi commented 4 years ago

@pinkit-cwa thanks for the feedback. Tbh I was mainly relaying what @ArnoldSchiller said in our twitter exchange. I couldn't really judge how likely his suggestions were to yield success, as I'm not an expert on the BT stack. It's a pity that this simple solution doesn't seem work. Maybe he can chime in with some further suggestions, I'll ping him on twitter 🙂 .

daimpi commented 4 years ago

Got a reply and suggested moving the twitter conversation here:

Laut dem Text ist es Android version 6.0.1, jetzt wäre die Frage ob das einen Kernel 4.x - in 3er-Kernel wird es nur unterstützt, wenn es "Backported" geworden ist.

So this means, the Android version used would be the limiting factor for "peripheral mode", not GMS, right?

So if I understand this correctly "peripheral mode" would require either:

An Android with kernel version >= 4.x or
An Android with kernel version 3.x but with suitable backported drivers

@ArnoldSchiller is this representation correct?

pinkit-cwa commented 4 years ago

Got a reply and suggested moving the twitter conversation here:

Laut dem Text ist es Android version 6.0.1, jetzt wäre die Frage ob das einen Kernel 4.x - in 3er-Kernel wird es nur unterstützt, wenn es "Backported" geworden ist.

So this means, the Android version used would be the limiting factor for "peripheral mode", not GMS, right?

So if I understand this correctly "peripheral mode" would require either:
* An Android with kernel version >= 4.x or

* An Android with kernel version 3.x but with suitable backported drivers
@ArnoldSchiller is this representation correct?

I confirm kernel version 3.0.101-g176096d for my "maguro".

I currently have installed UBports version 16.04 to the hammerhead. That one also has kernel version 3.4.0-cyanogenmod-g2b465f7 .

I did not yet check the kernel version for LineageOS on hammerhead. But, my guess would be "3.x" as well, due to the README in:

https://github.com/LineageOS/android_kernel_lge_hammerhead

I do not find a kernel 4.x based Android for either device, yet.

ArnoldSchiller commented 4 years ago

Bluetooth LE Linux Kernel versions:

= 4.4 Will work out of the box = 3.13 Ok for Bluetooth Classic and LE however consider backporting = 3.10 Ok for Bluetooth Classic however consider backporting

GisoSchroederSAP commented 3 years ago

Meanwhile, we checked quite a range of devices including Huawai, Samsung, Nokia, OnePlus that do not support the BLE peripheral mode. The results are comfortable: Even without the statement "BLE peripheral mode not supported", all devices worked fine with both

sending/receiving keys for contact tracking
regular retrieving of key packets for risk calculation

So far, we did not find any issues related to BLE peripheral mode in the test cases (test lab).

JProof commented 3 years ago

@GisoSchroederSAP

........100k infections later somewhere in issues there are whishes from first oder second day of public official release: Test-function or self-test or diagnose For App-Users to check the functionality of the CWA (sending receive). Please investigate by your self

pinkit-cwa commented 3 years ago

Even without the statement "BLE peripheral mode not supported" [...]

There is some issue with this sentence. I guess the "without" should be a "with" - or should the "Even" be a "When"?

So far, we did not find any issues related to BLE peripheral mode in the test cases (test lab).

I could supply you with an Google Galaxy Nexus, just to make your statistic a little bit worse. On the other hand, I doubt anybody else is using this handset anymore.

Also, I by now switched to LG Nexus 5X "bullhead", which works fine (while LG Nexus 5 "hammerhead" does not), so I do not have this issue anymore.

Regarding the missing self-test functionality, I agree, but I also have a workaround: I use "BeaconScope" to check for presence of other devices beacons. I just cannot see if CWA actually notices other devices beacons.

Actually, my bullhead once said (green) "low risk" while it mentioned an "encounter". Which might enable a usable self-test: leave your phone in some crowded underground station for a day or so. Within a few days you should know if CWA works or not. On the other hand, I am not sure if the Exposure Notification API can tell if/how many beacons have been received - probably that remains hidden within the framework. Please confirm.

daimpi commented 3 years ago

On the other hand, I am not sure if the Exposure Notification API can tell if/how many beacons have been received - probably that remains hidden within the framework.

Indeed: while the Exposure Notification Framework (ENF) by Google/Apple in principle has information on all the recorded rolling proximity identifiers (RPIs) only matches with positive diagnosis keys (DKs) will be exposed to CWA by the API (see here for more details on the response CWA gets from ENF in the currently used v1 legacy mode).

doak commented 3 years ago

Btw., even if not supported by the majority of ROMs, there are custom/unoffical Lineage builds available for Samsung Galaxy S3 (i9300) and Samsung Galaxy S3 LTE (i9305) which does indeed support BLE peripheral mode and are proven to work (tested with nrf Connect for instance).

GisoSchroederSAP commented 3 years ago

@JProof , I just added the mentioned self-test idea to the wishlist. We'll evaluate this as part of enhancing the "tooling" within the app.

GisoSchroederSAP commented 3 years ago

@pinkit-cwa

Even without the statement "BLE peripheral mode not supported" [...]

There is some issue with this sentence. I guess the "without" should be a "with" - or should the "Even" be a "When"?

No, I chose the phrase intentionally, but also could rephrase: Even if you skip/forget the statement "BLE peripheral mode not supported" all devices worked fine [...]

Meaning: Regardless of the peripheral mode, the verified devices worked fine. Obviously, I agree, there are still devices that will not be supported (yet) - for various reasons.

fynngodau commented 3 years ago

I don't quite understand why there is no warning in the app when a device doesn't support BLE periphial mode. Obviously, there are some devices like the Fairphone 2 where no beacons can be sent.

It is possible to detect whether this is the case in the app with just a few lines of code.

At CCTG, I am right now working on including a warning on the main screen to inform users when the device is not able to broadcast RPIs / IDs. (Previously, we only had this warning hidden in some menu.) I think it is quite crucial for users to know when the app is not working fully, therefore, I would strongly suggest CWA to include such a warning as well.

My suggestion is to add a card to the main screen, like this (screenshot from in-development 1.13.0.0 CCTG):

cctgincompatible

vaubaehn commented 3 years ago

Hi Fynn, during end of last year there was a plan, to introduce a better user-friendly error reporting. I suppose your solution strongly goes into the direction that was planned. I'd love to see something similar for CWA, and I'm wondering if there is a way to coordinate a common approach? So I'm pinging @BMItter here, who was supposed to work on this for CWA. Cheers, v.

thomasaugsten commented 3 years ago

@fynngodau Can you please create a PR for this warning?

vaubaehn commented 3 years ago

@fynngodau @thomasaugsten One open question: should the 'incompatibility card' actually replace (or block) the 'have you been tested card' as affected users cannot warn others?

Sorry, can answer myself: No, as the QR code for a test should be able to be scanned. But one could think about 'greying out' all submission related menus.

thomasaugsten commented 3 years ago

I think a normal block is ok no replacing not grey out because you can maybe in the future not only submit ENF TEKs

fynngodau commented 3 years ago

@thomasaugsten Sure, I can create a PR that introduces the incompatibility warning card as shown in the screenshot in the next days.

Ein-Tim commented 3 years ago

The "Fix 2.1" label should be removed here. The PR #2873, which implements the incompatible warning card, has been merged into the release/2.2.x branch, so this will be released with version 2.2, not with 2.1.

heinezen commented 3 years ago

@Ein-Tim True, I've corrected the labels.

Corona-Warn-App Open Source Team

gizmo21 commented 3 years ago

Thanks to everyone for input and coding of the warning card now. As I see this correctly now with next version I will have a drum roll on startup on my Nexus 5 hammerhead if that one is sending dispite the lack of BLE or if this one is really in incompatble.

fynngodau commented 3 years ago

I opened a PR for the FAQ entry that can gets opened once the card is clicked: https://github.com/corona-warn-app/cwa-website/pull/1211

Edit @gizmo21: The code for checking is likely very similar to that in the app from the screenshots in your original post. Therefore, if the app says "no" to peripheral mode, CWA should show a warning as well.

MikeMcC399 commented 3 years ago

Google Play Store does not offer CWA to a Pixel 3a emulator, Android 10 (API 29), because of the lack of Bluetooth support by the emulated device. The Store says "Your device isn't compatible with this version." If I however bypass that check and sideload CWA Android 2.2.1 on to the device, then the app shows an incompatibility warning, as planned: