Increase MinSDK ? #1
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Current minSdkVersion as set in app/build.gradle is 21, last changed in late 2022, it was 14 before that.
21 is Lollipop, released November 2014. This version is equivalent to Java 7, except it is missing java.nio.file. By supporting Android 21, we cannot use any Java 8 features in core, router, i2ptunnel, and other subsystems used by Android. The user base of people with 11 year old phones is vanishingly small.
I propose we increase it to one of the following, depending on what Java features we'd like to use:
24 (Nougat, released August 2016): Some Java 8 features including java.util.function
OR
26 (Oreo, released August 2017): Most Java 8 features, and Java 7 java.nio.file.
OR
28 (Pie, released Sept. 2018): Pretty much full Java 8/9
In addition to changing the build.gradle file, you'd have to adjust your build to switch to Java 8 compiler, and do some testing. Let's have a discussion about it.
The Jetty 9 EOL doesn't affect android, but may cause us to bump our desktop min Java to 17. If so, maybe we should bump android all the way to API 30 (R, Android 11.0, released Sept. 2020) which would allow us to use Java 11 features throughout.
If Java 17 is likely to be required for desktop, then my vote actually goes to API 30 for the Java 11 features and to make things a little simpler to keep up-to-date. I had been very cautious in the past, but it means carefully keeping track of the versions of all the gradle plugins that Android Studio uses. Moving to Java 11 would allow me to use some of the Android Studio tooling to keep that up-to-date. Instinctively, having Desktop and Android using the same Java version feels like less to keep track of.
However, if it's Java 8 or 11 for the desktop instead, the same basic argument would apply there, and I would choose 28 instead for the more-or-less complete Java 8 featureset. It will still be simpler to keep up-to-date.
As you said, there are very few people using 11 year old phones now, even aftermarket phones have long-surpassed that place. It's probably an exercise in futility to be as conservative as I've been. Moving forward would be better.
I'm going to start with a branch to look into Java 8 upgrades. I've actually tried this a few times before, using the Android Studio tools for this purpose. It may be mostly automatic IIRC.
Another point for Java 17: If I can use Java 17, I can use GeckoView, which means I can use it to replace the existing embedded browser, which currently does not support CSS, most types of images, actually most things.
I did not propose Java 17 for Android (U, Android 14, API 34) which was only released late 2023. That would knock out all the phones I own and I suspect a lot of other people.
My most ambitious proposal in my 2nd comment was to API 30.