I'm fine with min SDK 24. I do think however we should support
the factory webview version (based on AOSP) instead of picking a chrome
version number, purely because that isn't very enforceable (Could lead
to poor app user experience).
But if required we can discuss that further in another thread since it's
kind of off-topic to Min SDK.
I also agree that if we are picking Min SDK numbers, we should pick the
base (e.g. Support Android 7.0+ instead of 7.1+).
If I recall correctly, it was chosen for Android 5.1 purely because
there was known issues regarding upgradeable webviews on some device
manufacturers with Android 5.0.
FYI I skipped API 25 because there was a lack of data points.
On 2023-03-07 7:55 p.m., julio cesar sanchez wrote:
Any other opinions about it?
El jueves, 8 de diciembre de 2022, julio cesar sanchez <
jcesarmob...@gmail.com> escribió:
I was going to propose to bump the minSDK to 23 since we have been in 22
for a few versions, but I think going to 27 is too much and would make
users to not update or to move to something else.
The truth is, with google support libraries we won't really be cleaning up
that much code since the support libraries (android x core and such) take
care of that.
cordova-android has 2 SDK_INT version checks, one for N and another for M,
statusbar plugin has one for M, camera plugin has one for 28, inappbrowser
has one for O.
We probably have more code for supporting old cordova versions (in the
plugins) that probably nobody uses than for supporting old android versions.
BTW, you missed Android 7.1 (SDK 25).
Also, I wouldn't go with Android 8.1, in any case I would choose 8.0, it
was weird when we went with Android 5.1 instead of 5.0 or 6.0 as the code
to support it was basically the same as for supporting 5.0.
And related to that, I would count minor versions as one major, so Android
8 should be 8.0 and 8.1, so the usage would be 8.5%, and Android 7 (7.0 and
7.1) would be close to the 5% threshold. So we should go to minSDK 24 tops.
We can also do as Capacitor does and say that we support Chrome 60+ (or
the version we decide), so if people use an emulator where the default
version is older, it's not supported despite the Android version is. But
for real devices, the % of out of date WebViews is much much smaller.
El jue, 8 dic 2022 a las 16:59, Norman Breau ()
escribió:
Hi Apache Cordova community,
I'm writing to propose that we increase our Minimum SDK on our next
major release of cordova-android
and I wanted to get a feel of the Cordova community of what a new good
target to be, should we increase
the minimum SDK.
First I wanted to link a resource for the Android OS market share by
Android Version[1].
Based on November 2021-2022 the data summarized as follows:
Android 5.1 (API 22) - 1.32%
Android 6.0 (API 23) - 2.45%
Android 7.0 (API 24) - 2.64%
Android 8.0 (API 26) - 2.61%
Android 8.1 (API 27) - 5.89%
Android >= 9.0 (API 28+) - 9% or greater
It's desirable to drop old versions eventually because maintaining
backwards support can be difficult, particularly when Android introduces
new systems where it may only be available on newer API devices.
Additionally, every Android OS version could potentially be running
a really old system webview assuming the device has never been updated
from factory settings. Which based on the Android AOSP emulators, are as
follows:
Android 5.1 - Chrome 39
Android 6.0 - Chrome 44
Android 7.0 - Chrome 52
Android 8.0 - Chrome 58
Android 8.1 - Chrome 61
Android 9.0+ - Chrome 66+
I think traditionally, Cordova uses a 5% threshold to determine
supported devices, so I propose that for cordova-android@12, we increase
the Minimum SDK to API 27 or Android 8.1,
which contains 2 main benefits: 1) Allowing us to start cleaning up the
codebase significantly and 2) Cordova apps can start assuming a much
better JS feature support in their webviews as
can start assuming that the webview will be at least version 61 for most
devices.
[1] https://gs.statcounter.com/android-version-market-share
Cheers,
Norman
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
