[EN-Google] Android Devices send Beacons divergent from Exposure Notification Bluetooth Specification

[jkrwdf]

Avoid duplicates

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

Describe the bug

Using the Android App "nRF Connect", I looked at the COVID-19 Exposure Notification beacons sent by various devices.

The expected data is described in the Exposure Notification Bluetooth Specification.

While the raw data sent by iOS devices matches the specification and starts like this:

0x02011A03036FFD17166FFD....

the data I see from my own Android devices (Pixel 3 XL, Samsung A10, LG Nexus 4) omit the "flags section" and directly start with

0x03036FFD17166FFD....

Of course I assume that interoperability is still given between iOS and Android (eventually the Bluetooth Core Spec allows omission of the "flags section" with their current data), this difference allows me to distinguish users with active CWA by their operating system type over the air.

This could be considered an unnecessary information disclosure arising from the usage of the CWA (which in most cases is also facilitated by Apples "Nearby" beacons, but those can eventually be switched off by disabling AirDrop).

Expected behaviour

Android devices shall use a beacon according to the specification.

Steps to reproduce the issue

Use a BLE scanner which allows visualization of the "flags section" of the received data and look at the data emitted from an Android device.

Examples:
"nRF Connect" can show the raw data by pressing "RAW".

Example raw data from an Android device:

Example raw data from an iOS device:

---

Internal Tracking ID: EXPOSUREAPP-1937

[tomjschwanke]

Unfortunately, this can't be addressed here. This app is just using the API provided by Google / Apple and thus, they'd need to make changes.

[jkrwdf]

Unfortunately, this can't be addressed here. This app is just using the API provided by Google / Apple and thus, they'd need to make changes.

I fully agree.

To my relief, issue #744 shows that bugs residing in the framework may be discussed here and might be addressed to Google development by the CWA team.

[daimpi]

Related: corona-warn-app/cwa-documentation#341
e.g. Googles own specification states

The advertiser address type shall be Random Non-resolvable.

But it seems currently resolvable advertisement is used on Android.
Those are obviously not problems which fundamentally break or jeopardize the utility of the Google/Apple ENF (and therefore apps utilizing it), but it would be great nevertheless if Google/Apple could get them sorted out in a timely manner (bonus points if they do so in a transparent way by publicly acknowledging/commenting on the issues and keeping us appraised on the progress they make towards their resolution).

[kabeljan]

We are observing additional deviations of Googles ExposureNotification-BluetoothSpecificationv1.2.pdf.

According to the specification the type of advertising shall bey ADV_NONCONN_IND

During the Bluetooth broadcast, advertisements are to be non-connectable undirected of type ADV_NONCONN_IND [p. 5]

When using Wireshark with nRF52840-DK as Bluetooth sniffer, we are seeing many beacons of type ADV_SCAN_IND as you can see in the screenshot:

The Flags are also omitted by this beacons as shown in the screenshot.

[mh-]

@kabeljan Which Android devices are showing this behaviour?

[kabeljan]

@mh- I'am observing this deviation on my Huawei P20 lite and P30 lite and also on a Samsung and Motorola Device of my parents (dont know the exact type yet). I will collect further information in the next days. But it seems to me that this could be a general issue.

The question here is, whether the receiving device will reject those "malformed" beacons or not?

Also even if only the both named Huawei devices are affected it is very bad, because I think they are widely used.

[mh-]

Do the Huawei devices still use Google Play Services, or HMS Core („Huawei Mobile Services“)?

I believe these beacons will be scanned without problems. But you can check yourself by looking at the logs (logcat) - do you have adb installed on a computer?

[kabeljan]

@mh- I dont know if my Huawei devices are using HMS instead of Google Play, but i checked the behavior today with two other phones from my colleagues. I'am observing the "malformed" beacons with a Google Pixel 3 and a Samsung Galaxy A50.

To quick check malformed Beacons you can simply use the nrfConnect Android App. You can see there Beacons with a Connect-Button which indicates the wrong type, without Flags (see Screenshots).

I believe these beacons will be scanned without problems. But you can check yourself by looking at the logs (logcat) - do you have adb installed on a computer?

Unfortunately I have no adb installed, but i can check this in the next days. Thanks for this advice :)

[heinezen]

Hello everyone,

This should have been fixed by Google's Android Exposure Notification API. If you can, please retest with the latest version.

---

Corona-Warn-App Open Source Team

[jkrwdf]

I have two Android devices with the ENF versions 18210214000 and 18210613000, and as I can see using the RaMBLE application on the respectively other device, both still emit their beacons without the "Flags" section.

[dsarkar]

@jkrwdf OK, thanks for the feedback. Stand by, please.

[svengabr]

I have just checked the linked Jira issue.

Jira Ticket is flagged as:
Resolution: Wont Fix
Status: Obsolete

Developer comment:

To be fixed by Android-ENF.