Git Product home page Git Product logo

exposure-notifications-android's People

Contributors

alastair-breeze avatar flagxor avatar mariliamelo avatar tjohns avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

exposure-notifications-android's Issues

Thank you

this made my day. impostor syndrome got a little easier today. just a little, but I'll take the win.
😂

Exposure History stored more than 14 days

Describe the bug
The exposure history list should not contain records with more than 14 days. The app is showing records of 7 of September and as today (22 September) the oldest record in the list should be 8 of September .

To Reproduce
Steps to reproduce the behavior:

1.On your Android device, open the Settings app.
2.Tap Google and then COVID-19 Exposure Notifications.
3.Scroll to see all the records and see records with more than 14 days

Expected behavior
The list should not contain records with more than 14 days.
According to the link: https://support.google.com/android/answer/9888358

After you opt into the system, you can delete the random IDs stored on your device. They’re also automatically deleted after 14 days.

Screenshots
screen1
screen2

Device (if relevant):

  • Device: Nokia 7.1
  • OS: Android 10

Providing a way to keep social distancing

I'm sorry that this request may be out of places. But I couldn't find out where I should ask this feature.

Context

Exposure Notification(EN) provides a way to check whether we contacted infected persons. It can be seen as a post-confirmation feature.

What about infection protection? We are suggested to keep social distancing. It may be easy for healthy persons to keep doing that. But it may be difficult for visually challenged persons to do the same thing. In addition, it is important for many people to know if there are/were crowd of people before to go there.

Some APPs provide a measurement feature by using BLE tech. But these APPs work in many case only when each other launch same APP or use same service.

Problem of EN

APPs based method causes a dependent on spec of them. And advertising timing should be as shorter as EN's one to easy to find out by many kind of devices. Of course, it should take care of power consumption.

So, I think it is best way that OSs or Platforms should take care of this to broadcast signal with lowest power consumption and efficiency.

Basically, we can not get a measurement of distance by using EN before getting TEKey/ENIntervalNumber. Even if we don't care about a distance of each other and just find other EN devices, there are some privacy problem.

If certain APP has stored EN RPI/EM Key and infected person's TEKey/ENIntervalNumber were leaked, it can find out when this device was close to infected person. This matter must be unfavorable. (So, iOS seems to hide EN UUID from user.)

Then it is possible to be such as beacons. But as already we know, there are some differences in their specification. (e.g. iBeacon and Eddystone) And fixed UUID of device causes any privacy issues.

And here is the thing, common and unified format is most important!

My proposal

I'd appreciate it if platforms(iOS and Android) would consider to advertise new packet additionally.

Here is my draft proposal.

Advertise Packet

  • Flags
Length Type Flags
0x02 0x01
(Flag)
0x1A
  • Complete 16-bit Service UUID
Length Type Service UUID
0x03 0x03
(Complete List of 16-bit Service Class UUID)
0xXXXX
(Social Distancing Service)
  • Service Data - 16 bit UUID
Length Type Service UUID SubType TxPower Rolling Proximity ID Rserved
0x17 0x16
(Service Data - 16-bit UUID)
0xXXXX
(Social Distancing Service)
1Byte 1 Byte 16 Bytes 2 Bytes
  • SubType
    • [7:6]: Major version (current: 2b'01)
    • [5:4]: Minor version (current: 2b'00)
    • [3:0]: TxPower Level at ...
      • 4b'0000: 0 [m]
      • 4b'0001: 1 [m]
      • 4b'1111: may not be calibrated
  • TxPower: -127 ~ 127 [dBm]
  • Rolling Proximity ID
    - Periodically changed UUID for Proximity
  • Rserved (muxt be 0x0000)
    • For feature use
  • Notes
    • MAC Address must be changed periodically
    • MAC Addresse changing should be sync with wall clock as possible.
      • easy to prevent from duplicated counting or to decrease false positive
    • MAC Address between EN and Social Distancing Service must not be linked

Jpromnam> We've recently released a [collection of snippets](https://github.com/google/exposure-notifications-internals) to provide additional transparency in how the Exposure Notifications System works.

We've recently released a collection of snippets to provide additional transparency in how the Exposure Notifications System works.

Is google trying to reedem themselves?! In any case, thank you!
Let's hope you start being more transparent and open about your code, at least in this particular case where public health is involved...

Originally posted by @Carallo in #21 (comment)

rollingPeriod of TEK ist exposed in QR code with invalid value

Describe the bug
The reference application exposes invalid rollingPeriod of the TemporaryTracingKey. The value exposed is zero implying a validity of the Key of zero Minutes.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'Debug' in Tab Bar
  2. Click on '....'
  3. Scroll down to 'Provide Manually'
  4. See error in the QR codes and the provided

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Device (if relevant):

  • Device: Google Pixel4
  • OS: Android 10

Additional context
The TemporaryTracingKey rollingPeriod is a simple data type and cant be null (from Android-Exposure-Notification-API-documentation-v1.3.2)

/**

  • A number describing how long a key is valid.
  • It is expressed in increments of 10 minutes (e.g. 144 for 24 hours). */
    long rollingPeriod;

from Exposure Key File Format and Verification.pdf:

// Increments of 10 minutes describing how long a key is valid
optional int32 rolling_period = 4
[default = 144];

Suggested consistent wording in API and open source project docs

https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf

[Temporary Exposure Keys] | {Diagnosis Keys}

[medical provider] | {PHA}

[polling] | {fetching}

Mobile app

Your app does the following:
● Provides [Temporary Exposure Keys] | {Diagnosis Keys}, key start time number, and key transmission risk level from your internet-accessible server to Google Play services.
Information subject to copyright. All rights reserved. Version 1.3.2

● Retrieves keys from the on-device data store and submits them to your internet-accessible server after a user has been confirmed by a [medical provider] | {PHA} as having tested positive

● Schedules [polling] | {fetching} of your internet-accessible server for keys.

README.md points to old version of FAQs

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
README.md from the Exposure Notifications API: Android Reference Design contains a link to the V1.0 FAQs although a newer version, V1.2, is available on another Google site.

To Reproduce

  1. Open https://github.com/google/exposure-notifications-android/blob/master/README.md
  2. Click on link to Frequently Asked Questions
    Note that "Exposure Notification
    Frequently Asked Questions
    Preliminary — Subject to Modification and Extension
    April 2020
    v1.0
    " is displayed.
  3. Open https://www.google.com/covid19/exposurenotifications/
  4. Scroll down to FAQs for Exposure Notifications and open that link
    Note that "Exposure Notification
    Frequently Asked Questions
    Preliminary — Subject to Modification and Extension
    July 2020
    v1.2
    " is displayed.

Expected behavior

  1. The Exposure Notifications API: Android Reference Design should contain a link to the latest FAQ version, at least the available V1.2.
  2. Preferably links to documents should not include a version number coded into the file name (such as *_v1.0.pdf or *_v1.2.pdf) in order to promote maintainability and permanence of links to the document.

Interop testing of COVID-19 contact tracing

We are a university research group working on providing your bluetooth based COVID-19 contact tracing on simple BLE wristbands (as open source project). Our aim is to enable inclusive Covid contact tracing. Many young children, elderly persons, persons with disabilities and also persons with low income all over the world do not have a smartphone or cannot operate it.

Our technical key goal is to provide full compatibility with your COVID-19 contact tracing while using simple, cheap BLE wristbands (10 USD level). This is ongoing work, and some open challenges and tasks remain, but we are confident this can work out. However, we do not want to use the official contact app for interoperability testing. I want to (1) avoid that our test packets end up in the official database and (2) the actual release date for many countries is still some weeks ahead. Do you have a testing framework or traces? According to the document Exposure Notification - Cryptography Specification test vectors should be available. I have seen this code base and also the server example, but I was looking for actual BLE packets, unit tests, or similar.

Unsure if this is a good place to ask this. If not, I will happy if you could refer me on.

Use play-services-nearby via maven instead of file-based

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
Currently, the file play-services-nearby-18.0.2-eap.aar is added directly to the repository. It is not fetched via the gradle build system.

To Reproduce
See https://github.com/google/exposure-notifications-android/tree/master/app/libs

Expected behavior
The dependency should be declared in the build.gradle file and retrieved from a public maven repo.

Make bluetooth scanning location independent

Since Google's Android is a privacy hell anyhow, it seems to be that location services need to be turned on for Corona tracking apps to work. Why is that? Is there any physical explanation for this?

From the Android Help Center:

The Exposure Notification technology uses Bluetooth scanning to understand what devices are near one another. On all phones running Android 6.0 and above, to use Bluetooth scanning, the device location setting needs to be turned on for all apps, not just apps built with the Exposure Notifications System.

File Format?

Can we get more information on the file format expected? Is it going to use the same protobuf spec as Apple?

We are trying to enable our customers to use this SDK in their Xamarin apps and there are a number of questions such as the file format that we have and no point of contact to help answer them. Any help is appreciated!

Release as a open source Chimera Module

The Exposure Notification Framework implementation is de facto closed source, locked inside a closed source component such as the Google Play Services Framework.
It should at least be released as a Chimera module or give other ways to possibly implement it without the need of Play Services installed on the Android System.

Is the Play Framework implementation publically available?

Android is a platform used beyond devices that ship with recent Google Play Services releases. To allow public health authorities to potentially target devices other than Apple iPhones and Google Android if that is deemed useful by the given authority, it may be beneficial if Google released their Android Exposure Notifications implementation recently shipped as part of the Google Play Services offering as some form of Open Source.

Has such a thing be considered (or possibly already done) by Google?

Unsupported key file signature

I received this error message when testing the Android app downloading keys from our EN keys server:
com.google.android.gms.common.api.ApiException: 8: Internal error verifying key file signature: unsupported signature OID: SHA256withECDSA.

All of my test phones failed except the Samsung S9.

  • Samsung S9 (Android 10) worked
  • Pixel 4 (Android 10 with Play services 20.26.14) not working,
  • Moto X4 (Android 9) - not working,
  • LG Astro (Android 8) - not working
  • Moto G (Android 5) - not working

Is there a guideline on this?

Thank You

Key upload fails with error

Describe the bug
If mobile and server are in different timezone, while submitting/uploading the keys to the sever we get below error:

unable to read request data: Invalid publish data: interval number 2651616 + interval count 144 represents a key that is still valid, must end <= 2651703.

The cause of the error is that an android device would send an interval number generated as per its time zone. The interval count by default is 144 (representing 24 hrs). When server (in different timezone as that of the mobile device) tries to process the request and matches it with server time (say EST in US), the request becomes incorrect as sum of interval number and interval count becomes greater than server timestamp.

This can also occur if the server and mobile device are in same time zone, but device uses a different locale setting.

To Reproduce
Steps to reproduce the behavior:

  1. Keep the server in EST timezone.
  2. Put the mobile in a timezone before it say (IST)
  3. Upload the Exposure to server.
  4. Check server logs for error.

Expected behavior
Can this be fixed, such that both mobile device and server use same time zone and we don't run into this error.

Device (if relevant):
We tested on below devices

  • Google Pixel3a - Android 25
  • Xiaomi Redmi Pro8 - Android Pie

Wrong status bar notifications from Google exposure framework

Describe the bug
When either location or bluetooth is not switched on, the Google exposure notification framework pushes notifications to the Android status bar. These notifications, however, are sometimes incorrect, i.e. not reliable.

To Reproduce
Steps to reproduce the behavior:

  1. Use a stock Android version 6.0.1 on a Samsung S5, patched as far as provided by Samsung.
  2. Make sure in Android Settings > Google that exposure notifications are active (yes).
  3. Make sure in Android Settings > Apps that Google Play Services are allowed to push notifications (yes).
  4. Switch on and off location and bluetooth randomly and in varying combinations.
  5. See that the notifications from the Google exposure framework don't match the current Android settings, see below.

Expected behavior

  • If location is switched off I expect a notification to turn on location to use the exposure framework.
  • If bluetooth is switched off I expect a notification to turn on bluetooth to use the exposure framework.

Screenshots

1-on_int_loc_blue-warn_blue Internet, location, bluetooth on, but notification from Google COVID-19 framework that bluetooth is off. 2-Google_OK_warn_active Google settings show no warning (correct) but notification about missing bluetooth is still in status bar. 3-on_int_loc_blue-warn_loc Internet, location, bluetooth on, but notification from Google framework that location is off.
4-on_int_blue-warn_blue Internet, bluetooth on, but warning from Google framework that bluetooth is off. 5-on_int_loc-warn_loc Internet, location on, but warning from Google framework that location is off still in status bar. 6-setting_loc_OK-warn_loc Location settings show: location is switched on, but still warning from Google framework in status bar that location is off.
  • All of the screenshots above were made after waiting for at least several minutes after each change in settings. I see the COVID-19 framework notification about missing location by now for several hours even though location is switched on.
  • How can users be expected not to dismiss those misleading notifications? Not helpful for the cause of dependent apps.

Device (if relevant):

  • Device: Samsung S5 (SM-G900F)
  • OS: Android 6.0.1 (stock Android, patched as far as provided by Samsung) in German Language

Additional context
Related to issue https://github.com/corona-warn-app/cwa-app-android/issues/491 for the German Corona-Warn-App (CWA): neither Google nor CWA provide reliable warnings when location is switched off.

A bug in the attestation nonce generation

I suppose you use Google server reference as you backend. We deployed it on GCP and I copied your attestation code from this repo.

When I tried to verify the app there was a mismatch in the nonces of the app and server.

The problem:

The server expect the Temporary Exposure Keys to be sorted by the key encoded with base64
https://github.com/google/exposure-notifications-server/blob/00e75dfc94cbd135ed39d997b73e453c9ccc0ef3/internal/publish/model/exposure_model.go#L78-L82

In your implementation you sort the keys afterwards, when you created a list of string from all the fields in the TEK.

private String keys(List<DiagnosisKey> keys, int transmissionRisk) {
List<String> keysBase64 = new ArrayList<>();
for (DiagnosisKey k : keys) {
String keyInfo =
BASE64.encode(k.getKeyBytes())
+ "."
+ k.getIntervalNumber()
+ "."
+ DiagnosisKey.DEFAULT_PERIOD
+ "."
+ transmissionRisk;
keysBase64.add(keyInfo);
}
Collections.sort(keysBase64);
return COMMA_JOINER.join(keysBase64);
}

Solution:

Follow server logic: sort the keys first and then convert the list of the keys to the final strings.

Questions

  • Why do you use static DEFAULT_PERIOD and one transmissionRisk for all the keys?
  • Server encode these values from the keys itselves so this is a potential bug a well. Does SafetyNet attestation work for you now?

Exposure_notification_api not found

Hi!

I'm trying to run the reference version from your code (i downloaded to Android Studio) i did the compilation and runs but i get this error

I test this in 2 android phones (Android 10 and Android 8) with latest version of play store

com.google.android.gms.common.api.ApiException: 17: API: Nearby.EXPOSURE_NOTIFICATION_API is not available on this device. Connection failed with: ConnectionResult{statusCode=API_UNAVAILABLE, resolution=null, message=null}
at com.google.android.gms.common.internal.ApiExceptionUtil.fromStatus(com.google.android.gms:play-services-base@@17.2.1:4)
at com.google.android.gms.common.api.internal.ApiExceptionMapper.getException(com.google.android.gms:play-services-base@@17.2.1:2)
at com.google.android.gms.common.api.internal.zah.zaa(com.google.android.gms:play-services-base@@17.2.1:18)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.2.1:204)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zac(com.google.android.gms:play-services-base@@17.2.1:210)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.2.1:108)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.onConnectionFailed(com.google.android.gms:play-services-base@@17.2.1:75)
at com.google.android.gms.common.api.internal.zabn.run(com.google.android.gms:play-services-base@@17.2.1:17)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at com.google.android.gms.internal.base.zap.dispatchMessage(com.google.android.gms:play-services-base@@17.2.1:8)
at android.os.Looper.loop(Looper.java:237)
at android.os.HandlerThread.run(HandlerThread.java:67)

request a complete, out-of-the-box solution to complement a minimal proof of concept.

Note: This issue tracker is for reporting bugs in the Android Reference Design only. Bugs relating to the Exposure Notifications API itself cannot be reported here.

Is your feature request related to a problem? Please describe.
I don't understand why Google & Apple couldn't develop a complete and open source client/server setup and release it to the public. This is something that would be more relevant at a city/county/municipality level rather than state/country level- and these organizations (and even larger state/countries governments) do not have the time, money, and skillsets required to develop a full, bug free, solution in a short amount of time.

Describe the solution you'd like
A complete solution in a box

Describe alternatives you've considered
Hundreds to thousands of health departments around the world hire developers to develop their own bug free Android and iOS apps.

Additional context
n/a

How should the diagnosis server be implemented ?

It's not clear whether the back-end diagnosis server that is used for storage and retrieval of diagnosis keys can be implemented by App developers or will it be provided as a cloud service by Google ? In case it needs to be implemented by App developers, does the API mandate a specific query format or app developers are allowed to choose whatever format they prefer ?

As per the exposure key file format, seems like the apps will be able to download in batches. Does that mean the query parameters should contain timestamp ranges and batch number ?

https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Exposure-Key-File-Format-and-Verification.pdf

Energy saving issue

Describe the bug
The app tells you that it is not working because the "energy saving" option is enabled, even it is deactivated.

To Reproduce
Steps to reproduce the behavior:

  1. Enable energy saving
  2. Open the app
  3. Close it and disable energy saving
  4. Open the app and see error

Expected behavior
To work as the energy saving feature is disabled.

Screenshots
https://gyazo.com/a874870a66bf5675b486b692f17b2724

Device (if relevant):

  • Device: Xiaomi MI 8
  • OS: MIUI 11

EXPOSURE_NOTIFICATION_API is not available on this device error (Error code 39507)

com.google.android.gms.common.api.ApiException: 17: API: Nearby.EXPOSURE_NOTIFICATION_API is not available on this device. Connection failed with: ConnectionResult{statusCode=UNKNOWN_ERROR_CODE(39507), resolution=null, message=null}

Getting this error in the googles official github project
Google Play Service updated but still getting the same error
could anyone suggest how to implement EXPOSURE_NOTIFICATION_API and how to use this source code in Android App

The build scripts does not work on Windows

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
The build scripts works on Linux, but not working on Windows

To Reproduce
Steps to reproduce the behavior:

  1. checkout the repo from Android Studio
  2. build the debug APK

Expected behavior
A debug APK is built

Device (if relevant):

  • Device: N/A
  • OS: Windows 10

Additional context
I also tried on Linux, it is working properly. So it seems the build script is not working on Windows. It shows the following error messages.

Cause: error when building with cmake using C:\Users\USER\AndroidStudioProjects\apollo\exposure-notifications-android\third_party\CMakeLists.txt: Build command failed.
Error while executing java process with main class com.google.prefab.cli.AppKt with arguments {--build-system cmake --platform android --abi arm64-v8a --os-version 21 --stl c++_static --ndk-version 21 --output C:\Users\USER\AndroidStudioProjects\apollo\exposure-notifications-android\prioclient.cxx\cmake\debug\prefab\arm64-v8a\prefab}
Usage: prefab [OPTIONS] [PACKAGE_PATH]...
Error: Missing argument "PACKAGE_PATH".

17: API: Nearby.EXPOSURE_NOTIFICATION_API is not available on this device

I am getting this below exception.
17: API: Nearby.EXPOSURE_NOTIFICATION_API is not available on this device. Connection failed with: ConnectionResult{statusCode=API_UNAVAILABLE, resolution=null, message=null}.

As described in docs, android app code & google play-services are required to access from public health agencies. As like that, do we have to follow these steps..? Could please suggest

1: we need to provide advance notice to the Google Play App Review team to use Exposure API's

2: after got the access(do we get any help doc for development), can we test Exposure API's locally while developing app or do we need to required to access with step 1 credentials only. Because source-code does not have any configurations to access and validations

Could you please suggest on this..? please excuse if anything is wrong from my end

Internal error, please try again

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
After building the app and running it on either an emulated phone, or my Pixel 2 XL, and pressing the "Turn On" button (to turn on Exposure Notification), an error appears saying "Internal error, please try again". The app does not proceed to the next screen.

To Reproduce
Steps to reproduce the behavior:

  1. in Ubuntu 20, in Android Studio 3.6.3, import the project and insert the URL for this repo
  2. Build the app
  3. Open it in an emulated phone or a real phone connected via USB.
  4. See on phone Internal error, please try again
  5. See error in Logcat: E/wifi_forwarder: RemoteConnection failed to initialize: RemoteConnection failed to open pipe

Expected behavior
Notifications should be turned on and the app should advance to the next screen

Additional context

  • I have not changed anything in build.gradle except ext.safetynet_api_key

Sample code could be more representative of real-life Android code

This is more of a remark than a bug as the code is functional as is.

The sample code makes heavy use of ListenableFuture, Guava and is Java based.

I understand that this is according to Google internal standards, but most Android apps are build with Kotlin ("Kotlin first") and use primitives like coroutines or RxJava for async work.

To further clarify: the most important parts for me are the interactions with the API. The ListenableFuture stuff makes that quite hard to follow and understand. I don't expect this to be the perfect example of how you build Android apps, but I would like to be able to take the crucial bits, e.g. the API interactions, and use that as a starting point for the app I'm working on.

What version of the minSdk in the end?

Starting from v1.3 the documentation says the min is 23:

For your app to work on a device, the device must be running Android version 6.0 (API
version 23) or higher

But after a few updates in this repo to v1.3 and higher it still uses 21 as the minSdk. Is this a mistake in the documentation or here?

Thank you

README refers to upcoming build of already released Google Play services

Documentation issue - where to find

README.md
Second paragraph.

Documentation issue - description

The README.md states:

"Only approved government public health authorities can access the APIs (included in an upcoming build of Google Play services) to build an app for COVID-19 response efforts."

however the text in brackets:
"(included in an upcoming build of Google Play services)"

is outdated. The Exposure Notification System API in Google Play services was already released several months ago. The release-notes start documenting with the release of V1.5 in July 2020.

Suggested resolution

Remove the text "(included in an upcoming build of Google Play services)" from the sentence "Only approved government public health authorities can access the APIs (included in an upcoming build of Google Play services) to build an app for COVID-19 response efforts." in the README.md document.

Additional context

The previous edit to this file was done by @mariliamelo. Maybe you could make this minor change as well?

Poor visibility of notification with large display and font size.

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
Unfortunately, when bluetooth is switched off, the notification of a possible encounter with infected is unclear on devices with a large display and font size.

This is unfortunate because older people or people with impaired vision who have chosen a large display and font size and are not particularly familiar with mobile phones, especially older people.

Who don't understand that bluetoth is essential for use,
may not understand the probblem .

To Reproduce
Steps to reproduce the behavior:

  1. Install a Corona-Warn-App in my example https://play.google.com/store/apps/details?id=de.rki.coronawarnapp&hl=de

  2. Go to the android Settings and set the display and font size to the largest size.

  3. Setup the app and enable Corona Tracing

  4. Then dissable Bluetooth

  5. You can see a unclear notification (see screenshot)

Expected behavior
a better explanation of what the problem is that is compatible with large display / font sizes.

Screenshots
image

Device:
I think thats not realy relevant but her it is:

  • Device: [Moto G5s Plus]
  • OS: [Android 8]

Orginal Issue: corona-warn-app/cwa-app-android#532

Why is Bluetooth and Internet Permission needed

The Exposure Notification Framework API (implemented as Play Framework) is listening for data sent via Bluetooth. The app is can just start/stop this functionality and can request data/sates via the API for more information but the Framework runs the whole bluetooth related code. Why does the app need Bluetooth and Internet permission if it does do any bluetooth related tasks? The permissions should only be bound to the PlayFramework not the the app...

Google apple exposure notification allowlisted account

I want to use Google Apple exposure notification api. I'm wondering if I can use it for research purpose or in debug mode. In the documentation is written that an allowlisted account is prerequisted. Any one have some information ?

There are messages shown in app, which we have no control over

Notification issue

In above image we see two notification being shown. The first one we can find in the Sample Code shared. Issue is with second notification. We couldn't find it in the sample code and have no control on when it shows.

Please share more details on the behavior of second notification and if can we control it.

Problem rolling out v1.5

Note: This issue tracker is for reporting bugs in the Android Reference Design only.

Describe the bug
I still have v1.0 of EN API.

To Reproduce
Settings>Google>COVID-19 Exposure Notifications>ExposureNotification
Turn Off.
Unable to turn on again!

Expected behavior
V1.5 must be installed -> Possibility to turn on Exposure Notification in Settings.

Device (if relevant):

  • Model number: F3311
  • Android version: 6.0
  • COVID-19 Notifications Version 202414000

Additional context
Using Corona Warn App in Germany

"Same day" tek upload in example app

When a user uploads their keys the getTemporaryExposureKeyHistory () is called which will return as per documentation:

The keys provided here will only be from previous days; keys will not be released until after they are no longer an active exposure key.

Will the app simply ignore keys from the same day or is an upload scheduled after the period until keys from current day are released?

Test Dependency should migrated to AndroidX

In the build.gradle in different modules

testImplementation 'com.android.support.test.espresso:espresso-core:3.0.2' 
testImplementation 'com.android.support.test:runner:1.0.2'

Support Lib has been discontinued and projects should use AndroidX Test (https://developer.android.com/training/testing/set-up-project)

androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
androidTestImplementation 'androidx.test:runner:1.2.0'

Please update the dependency.

Api Access

Only approved government public health authorities can access the APIs (included in an upcoming build of Google Play services) to build an app for COVID-19 response efforts.

Can i access without any permission of authorities ?

if No then how i can apply for permissions and what steps need to follow.

Improving proximity estimation by handling RSSI per advertisement channel

Hi, I am not sure if I understood the documentation of the API right, so I wanted to ask: Is it correct that in android version > 9, exposure notifications are received on all three BTLE advertisement channels, 37, 38 and 39, and then the RSSI values received on that channels will be averaged and stored into the ScanInstance structure? Will these averaged values then be used to compute the attenuation value that is used as a distance estimator (https://developers.google.com/android/exposure-notifications/ble-attenuation-overview)?

I am asking, because on behalf of my master thesis, I measured RSSI values in BTLE for different distance channel wise. And these measurements have shown that there are big differences in RSSI between these channels. Here are some of my results for an (almost empty) office environment:
ble_single_channels

I am concerned now, that if we average those values over the three channels, we will generate a less accurate RSSI value for the attenuation calculation than the situation really is. In a way, that a close contact, was for example correctly detected with a high RSSI value greater than -45dBm on channel 37 and then by averaging with the other received values like a -60 on channel 38 and 39, the indicator will be lower than -55 and a false negative will be produced. And as we already know (e.g. from Leith and Farrell), using RSSI as a distance approximation is very error prone, already if we only use one channel. But we could take advantage of the presence of all three channels. My suggestion in this case would be, only using the channel where the maximum RSSI value was received out of the three channels. As I don't know if the channel can be determined (Edit: I know read a paper and detailed parts in the standard, that the channel information ist not available. Gentner, Günther and Kindt are suggesting an approach to retreive channel information), another solution would be to use the maximum RSSI for a specific time window. This then could be a more close to reality description with better signal propagation characteristics, which hopefully results in less false negative results.

I hope my suggestion can help to improve the distance estimation (if it isn't already implemented in a way without averaging) :)

best regards,
Eric

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.