Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-26472] Android: Replace support libraries with AndroidX

GitHub Issuen/a
TypeImprovement
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2020-01-31T11:00:19.000+0000
Affected Version/sn/a
Fix Version/sRelease 9.0.0
ComponentsAndroid
Labelsandroid, dependencies, library
ReporterHans Knöchel
AssigneeJoshua Quick
Created2018-10-19T08:29:04.000+0000
Updated2020-01-31T11:00:19.000+0000

Description

The Android "Support Libraries" have been deprecated by Google in favor of the AndroidX libraries. Google will no longer be making updates to the Support Libraries (v28 is their last version). New features will be going to AndroidX instead. https://developer.android.com/jetpack/androidx The Titanium SDK and its modules needs to migrate to the AndroidX libraries. Titanium's app builds will also need to leverage Google's "jetifier" tool which replaces prebuilt Android libraries, replaces their references from the Support libraries to AndroidX by hacking the binary (this is a Google sanctioned feature) so that 3rd party modules will be backward compatible. https://developer.android.com/jetpack/androidx/migrate AndroidX is best implemented in the app "build.gradle" file via... 
android {
	useAndroidX true
	enableJetifier true
}

Comments

  1. Hans Knöchel 2019-02-15

    Hey there (cc [~gmathews] & [~jquick]), is this on the roadmap for 2019? I see this being done in other frameworks and wondering what the benefits or downsides this has.
  2. Joshua Quick 2019-02-15

    The plan is to first implement gradle support [TIMOB-19300] and then update the support libraries to rev 28 [TIMOB-26262], which is the last revision from Google that is not "androidx". Updating to rev 28 maintains backward compatibility and avoids having to recompile all modules. We can't replace our support libraries with androidx libraries "yet" since that would break most modules and hyperloop users. Currently, everyone has hard-coded java imports to android.support.v4, android.support.v7, etc. and assumes Titanium includes those libraries. There will have to be a migration period. Google has a migration tool (such as jetifier) to help with this, but it is imperfect. _(This isn't trivial. Worst case scenario is a module that depends on a 3rd party pre-compiled JAR that depends on the "old" support libraries.)_ Once we have gradle support, you'll be able to reference the dependencies you want (such as androidx). The next challenge on our end is dealing with version conflicts such as the warning below. The below isn't unique to androidx. It'll happen if 2 libraries references 2 different revision of support libraries in general, such as between rev 27 and rev 28. (Gradle doesn't magically fix this.) 
       All com.android.support libraries must use the exact same version specification
  3. Hans Knöchel 2019-02-15

    Sounds like a plan, thanks Josh!
  4. Hans Knöchel 2019-03-24

    First library updates are Android-X only now, like Lottie. I hope this can be scheduled soon.
  5. Rainer Schleevoigt 2019-04-07

    The Oboe library https://github.com/google/oboe/tree/master/samples/audio-device has changed to androidx 3 month ago. In my case I can simple downgrade ;-)) (they only use androidx for annotations)
  6. Michael Gangolf 2019-09-21

    Any update here? The current ti.playservices (https://github.com/appcelerator-modules/ti.playservices/releases/tag/v16.1.5) module is not working correctly because it tries to use androidx libraries (https://github.com/appcelerator-modules/ti.playservices/issues/29). That should be downgraded in order to make it work for devs
  7. Joshua Quick 2019-09-23

    We need to update the Titanium build system to use gradle first, which we're actively working on now. Once done, we can then update Titanium to use AndroidX. Google's gradle build system comes with a tool to change the binary in all JARs to replace the Android Support library references with AndroidX references. This is needed so that 3rd party prebuilt JARs won't break. For now, yes, we should downgrade "ti.playservices". I agree.
  8. jon kravetz 2019-10-04

    Does this mean we can't use AndroidX libraries in a titanium module? This would be unfortunate. Currently trying to implement workmanager in a titanium module. Would we need to use Workmanager 1.01, since Workmanager 2+ has androidx dependencies? I have been trying to get the newer workmanager to work for days, but I'm getting a conflict when trying to compile my application with the module due to support library (V4). Would you suggest abandoning the use of workmanager altogether? Documentation for android apps/modules without gradle or androidx is not easy to find at this point.
  9. Joshua Quick 2019-10-04

    bq. Does this mean we can't use AndroidX libraries in a titanium module? You cannot at the moment. This is because you can't use a mix of the old Android support libraries and AndroidX libraries at the same time. This will cause a conflict. Every module, including the core Titanium libraries, would have to transition over to AndroidX for this to work. This is something we're looking into doing in Titanium 9.0.0, but we don't have an ETA at the moment. (This is a huge task.)
  10. Hans Knöchel 2019-12-22

    Pull request: https://github.com/appcelerator/titanium_mobile/pull/11409
  11. Joshua Quick 2020-01-11

    I'm closing the above PR in favor of the one below. (But I did cherry-pick most of Hans' migration code. Thanks Hans!) PR (master): https://github.com/appcelerator/titanium_mobile/pull/11428
  12. Samir Mohammed 2020-01-31

    Closing ticket, fix verified in SDK version 9.0.0.v20200130113429 Test and other information can be found at: https://github.com/appcelerator/titanium_mobile/pull/11428

JSON Source