minSdkVersion as low as possible

Question

minSdkVersion as low as possible

fynngodau opened this issue 5 years ago · 8 comments

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

The library androidx.security:security-crypto only 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

A lot of Bluetooth APIs were apparently rewritten; those rewrites are only included in API 21. As such, using the old (deprecated) methods would require a rewrite of BleClient and BleServer as an alternative for older devices. Some calls in GattConnectionTask would 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 in DayDate could return the timestampRepresentation value as a hash directly.

Answer 1 · 2020-04-18T09:16:39.000Z

Once they will implement Google Api the minSdk should be 23 (android 6). So no need to support androidSdk < 23 right?

Answer 2 · 2020-04-18T09:21:07.000Z

@corrado4eyes I believe there should be an implementation independent from GMS, see #10.

Answer 3 · 2020-04-23T14:46:58.000Z

AFAIK, the minimum Android version which supports BLE peripheral mode is 5.0.
Android 4.3 would require a screen to be unlocked to send beacons, just like any version of iOS.

So even if API 18 is supported, it would give user a false sense of security, since there would be huge gaps in tracing.

Answer 4 · 2020-04-23T14:58:05.000Z

@Vanuan Thank you, I did not know this.

Answer 5 · 2020-04-23T15:00:51.000Z

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.

Answer 6 · 2020-04-23T17:16:06.000Z

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.

Answer 7 · 2020-04-30T14:06:43.000Z

New information from Android Exposure API:

Bluetooth functionality, including all broadcast and scanning for BLE beacons and local
database storage, happens within Google Play services on-device. Your app will need to
have the BLUETOOTH permission in its manifest, but does not require
ACCESS_FINE_LOCATION or BLUETOOTH_ADMIN. For your app to work on a device, the
device must be running Android version 5.0 (API version 21) or higher.

So the minimum version should be API 21.

Answer 8 · 2020-05-05T10:20:19.000Z

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)