Enable androidx #2374
Enable androidx #2374
Conversation
| @@ -96,6 +96,13 @@ android { | |||
| } | |||
| } | |||
|
|
|||
| {% if args.enable_androidx %} | |||
| ext { | |||
There was a problem hiding this comment.
Would it be preferable to put the if/endif inside the ext block (which would exist, but empty by default, and this way, more options could be added later in that block if needed?
Just a thought, it's certainly not a problem and it can be changed later when we actually have more options to put in there.
|
@tshirtman ext{} easy to do. But wait. |
|
The first issue is the version of the Android Gradle plugin specified by p4a 3.1.4 does not support jetifier, so AndroidX compatibility is not implemented. A minimum of 3.2.1 is required, the current version is 4.0.1 Great release notes here https://developer.android.com/studio/releases/gradle-plugin#3-2-0 Investigating.... |
Addresses #2020
AndroidX is a support library that replaces the depreciated Android support library.
This PR adds a build option
--enable-androidxwhich (when used) adds a block tobuild.tmpl.gradleWhen AndroidX is enabled, a specific AndroidX library can be added using the existing
gradle_dependenciesoption.Some (or all?) of the latest packages in the AndroidX library depend on
api=28or greater.There is an alternative implementation, setting the same two Gradle flags in a new file named
gradle.properties. Because of the file management uncertainties introduced in the context ofp4a, this author will not use this approach.The previous support library is depreciated. There is an argument that AndroidX should be enabled by default. This would impact users who specify an existing support package in
gradle_dependencies. And there may be some other unforeseen impact. Alternatively AndroidX could be enabled byapiversion, but this would not be transparent to users. I think AndroidX should be enabled by default, but not yet; so it is enabled by build command option.As an example user dependency consider #2200 , it depends on the Android support library but is agnostic to which one. However the user code required does depend on the chosen support library, the change is in a Java class name, and in the name of the
gradle_dependenciespackage.The need for #2200 is wide spread; for example the
plyercamera https://github.com/kivy/plyer/blob/master/plyer/platforms/android/camera.py uses a 'file url' which can no longer be used between Activities, so is not functional with api =29 or greater. To prevent user rework after #2200 is incorporated, I suggest that this PR be incorporated at the same time.