minSdkVersion as low as possible #16
Comments
|
Once they will implement Google Api the minSdk should be 23 (android 6). So no need to support androidSdk < 23 right? |
|
@corrado4eyes I believe there should be an implementation independent from GMS, see #10. |
|
AFAIK, the minimum Android version which supports BLE peripheral mode is 5.0. So even if API 18 is supported, it would give user a false sense of security, since there would be huge gaps in tracing. |
|
@Vanuan Thank you, I did not know this. |
|
Our only hope for 99% adoption is that Google/Apple somehow backport/update their older OS without user consent, basically installing malware. But even then app developers would be limited by APIs they provide, the beacon database would likely be encrypted and not available without rooting, and BLE protocol being closed source. |
|
Adding new APIs to deprecated systems is what the GMS are designed for. I personally would generally consider them to be malware because it behaves in ways I don't support and can't control. However I'm not sure whether the GMS have such a deep control over the system that it would allow such a change, which sounds to me like it would be relatively low-level. On the other hand, they already announced their Tracing API will be Marshmellow and up. |
|
New information from Android Exposure API:
So the minimum version should be API 21. |
|
So I am ready and willing to work on this issue (to lower the minSdkVersion to 21), if I can get some buy-in from a core contributor that this would be considered for the production app. Every additional accessible phone makes a difference, especially down-market (cheap) phones, which are predominantly used by citizens who are more likely to be disadvantaged (older, less disposable income, second phones for older teens, etc) |
This is a first look at what would be required to lower the minSdkVersion to 21, thereby picking up devices with Android 5.0 and 5.1 (<5% in Switzerland, approx 15% worldwide). API level 21 has good support for Bluetooth LE. What it is missing is some stuff related to power management, and support from the AndroidX libraries. The solution was to back-port the EncryptedSharedPreferences.java file from AndroidX, as it alone did not depend on much API 23 stuff, and then adapt the key creation stuff to do the same thing as MasterKey did, but to fallback to another way of making the master key that works in API 21. This change has been tested from one Android 5.1 phone to another Android 6 phone, and contact tracing worked. Fixes DP-3T#16.
This is a first look at what would be required to lower the minSdkVersion to 21, thereby picking up devices with Android 5.0 and 5.1 (<5% in Switzerland, approx 15% worldwide). API level 21 has good support for Bluetooth LE. What it is missing is some stuff related to power management, and support from the AndroidX libraries. The solution was to back-port the EncryptedSharedPreferences.java file from AndroidX, as it alone did not depend on much API 23 stuff, and then adapt the key creation stuff to do the same thing as MasterKey did, but to fallback to another way of making the master key that works in API 21. This change has been tested from one Android 5.1 phone to another Android 6 phone, and contact tracing worked. Fixes DP-3T#16.
This is a first look at what would be required to lower the minSdkVersion to 21, thereby picking up devices with Android 5.0 and 5.1 (<5% in Switzerland, approx 15% worldwide). API level 21 has good support for Bluetooth LE. What it is missing is some stuff related to power management, and support from the AndroidX libraries. The solution was to back-port the EncryptedSharedPreferences.java file from AndroidX, as it alone did not depend on much API 23 stuff, and then adapt the key creation stuff to do the same thing as MasterKey did, but to fallback to another way of making the master key that works in API 21. This change has been tested from one Android 5.1 phone to another Android 6 phone, and contact tracing worked. Fixes DP-3T#16.
The Google Exposure Notification service works down to API 21, so the SDK should as well. Handle the missing EncryptedSharedPreferences by simply writing the preferences in cleartext when it is not available. Fixes DP-3T#16.
To allow as many users as possible to participate, the minimum Android version should be as low as possible. Since BLE is introduced in Android 4.3 (API 18), this would be the ideal
minSdkVersion.With the help of the Android linter, I will summarize the sections that would be highlighted as incompatible depending on the API version one would pick as a
minSdkVersion.API 21
androidx.security:security-cryptoonly supports API 23. Likely, it could be replaced with the library Android-Vault, which uses the Android keystore to store the key as well.As well as these trivial issues:
PowerManager.isIgnoringBatteryOptimizations(String): battery optimizations were only introduced in API 23.AlarmManager.setExactAndAllowWhileIdle(int, long, PendingIntent):setExact(int, long, PendingIntent)would provide the same behavior up to API 19.API 19
BleClientandBleServeras an alternative for older devices. Some calls inGattConnectionTaskwould have to be changed.API 18
Trivial issues:
AlarmManager.setExact(int, long, PendingIntent):set(int, long, PendingIntent)would give the same behaviour.Objects.hash(Object...): The call inDayDatecould return thetimestampRepresentationvalue as a hash directly.The text was updated successfully, but these errors were encountered: