Thanks for your input Alex.

We too have started using min sdk 24 internally, and Chromium's latest tag is also using Min SDK 24:

https://chromium.googlesource.com/chromium/src/+/refs/tags/113.0.5653.1/build/config/android/config.gni#46

Since some time as been gone with no additional comments, I created a PR and summarize the discussion in the commit. If there any other concerns, it should be commented on the PR, preferably before it gets merged.

PR: https://github.com/apache/cordova-android/pull/1571


On 2023/03/08 14:33:51 Alexandre Alves wrote:
> Just a small contribution... I see no problem in updating the minimum requirements as the percentage of users in 5.0 is currently marginal.
>
> In the applications we publish we have already updated the requirements for minSDK 24.
>
>
> ________________________________
> From: julio cesar sanchez
> Sent: 08 March 2023 12:05
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Android - New Minimum SDK?
>
> As far as I know the problems with upgradeable webviews on some device
> manufacturers affect all versions, not only 5.0. Some vendors decide to not
> make it updatable, and others use their own implementation instead of the
> system one.
>
> Anyway, I’m ok with 24
>
> El El mié, 8 mar 2023 a las 1:49, Norman Breau
> escribió:
>
> > 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
> >
> >
>

Reply via email to