AndroidX Migration Plan

[matt-oakes]

Introduction

React Native 0.60 will move from using the Support Library to AndroidX. These are mostly the same library, however the artifacts names and package names have all changed. Google has stopped supporting the support library (ha) and will only be releasing updates to AndroidX.

Details from Google.

With this change, React Native apps will need to begin using AndroidX themselves. They cannot be used side-by-side in one app, so all of the app code and dependency code needs to be using one or the other.

A normal native app can use the Jetifier tool to migrate. This goes through all of their dependencies and changes any references to the support library to AndroidX.

Jetifier will not work for React Native projects as it only works on "packaged artifacts". Almost all React Native dependencies come in the form of a reference to the library source code. These are not migrated by Jetifier.

The Core of It

We are going to have lots of reported issues where developers Android apps will not build because some of their dependencies are using AndroidX and some are using the support library.

The "best" solution is for all libraries to release a version which has migrated to AndroidX and the app developer can then upgrade all of their dependencies at once. This would mean, however, that users who want to get bug fixes for that library would need to migrate their app to AndroidX. This, in turn, means that if just one of their dependencies is not migrated to AndroidX, they are locked into using <=RN 0.59 and cannot use new versions of libraries which have migrated.

Most React Native libraries do not need to use the support library, however, there are many that do and not all are actively maintained.

Discussion points

How can we help developers with this problem?

[mikehardy]

Thanks Matt!

the ideas I have seen so far are:

• convert module to AndroidX, then use some tool (bob?) to generate AAR for distribution and run reverse jetifier
• maintain module with support libraries and distribute as AAR so consumers may use Jetifier
  have a postinstall script that does a translation using something like this https://developer.android.com/topic/libraries/support-library/downloads/androidx-class-mapping.csv
• maintain separate branches (tagged @androidx or @support or similar)

I'm interested in the AAR ideas but I'm unsure of the exact mechanics to generate an AAR, distribute it, and how to document AAR integration into a project.

[matt-oakes]

convert module to AndroidX, then use some tool (bob?) to generate AAR for distribution and run reverse jetifier

Would this require changes to the way libraries are referenced in the build.gradle files? If so, this could be confusing to developers where Gradle is already pretty opaque and hard to understand.

---

Another idea I was to have a postinstall script which "migrates" dependency source using sed and a CSV mapping file which Google provides.

• Script: https://gist.github.com/dlew/5db1b780896bbc6f542e7c00a11db6a0
• Mapping: https://developer.android.com/topic/libraries/support-library/downloads/androidx-class-mapping.csv

This could work, but also has the possibility to just break more things than it fixes.

[mikehardy]

I believe this would require different dependency referencing yes, but this is also something that CLI could likely handle in an unlink/link phase, reducing the problem set to consuming projects performing an upgrade (or can CLI run scripts on upgrade?)

If signaled by a semver major with instructions for projects that could not migrate, it might at least work. It's my understanding that we don't have any solution candidates that handle all cases, so even having this idea sussed-out to a "could at least work" status would be a positive.

[yeswanth]

The above solutions might be tough for someone not familiar with Android. I would also like to see a list showing which libraries are compatible, so that users can make a conscious call on whether they can safely upgrade to 0.60 or not. Maintaining this list might be difficult, but it could be a good official approach (not just for this particular use case, but can be useful for others too).

[mikehardy]

For unrelated reasons I just ended up chewing on a library dependency that had updated to AndroidX and it was unusable in a react-native 0.59 context. That library emitted an AAR so it was possible for me to reverse-jetify it (if we had the infrastructure for that to be easy for people) and that would have possibly solved my problem. However I had to fork another library dependency and update it then point package.json to my github fork and that made me think - even if we build an AAR reverse-jetify infrastructure (which I would argue would solve a lot of problems) people that have one foot across AndroidX (by using RN0.60+some reverse jetifier AAR magic) but one foot not across it (by relying on libraries that don't support it and don't provide any workarounds) will not be able to quickly fork+modify libraries that have gone AndroidX because any AAR+reverse-jetifier infra will necessarily be some post-processing that doesn't work in a package.json+git-reference context.

I consider this an edge case, but it is one that affects me so I thought it was worth mentioning. There may be nothing that can be done, some breaking changes are like that.

I'm still thinking AAR distributions and some reverse jetifier magic will help the largest number of people but I haven't proven that out yet as feasible or acceptable

[matt-oakes]

Just to note that this is the sort of issue which will be opened if we don't find a way to make this migration work:

react-native-netinfo/react-native-netinfo#107

[mikehardy]

In the linked issue from react-native-firebase above, a user commented that this allowed them to use react-native-firebase in an AndroidX app, I have not tested it but it might work?

UPDATE: this was tested (see below) and DOES NOT WORK. I wish it did, but it does not. I am leaving it here so we know what doesn't work, but don't waste your time (sadly)

Edit: For anyone else, the workaround is this:
Add gradle.properties into the android folder of each incompatible module, with this content:

android.useAndroidX=false
android.enableJetifier=false

[EskelCz]

@mikehardy it got me through react-native-firebase, react-native-google-signin and react-native-maps errors. For react-native-navigation it didn't work and I'm stuck, thinking about reverting the whole 'upgrade'. Only difference I see is that react-native-navigation has gradle wrapper inside it and disabled android.enableAapt2 because of some building issues.

I'm new to android so this whole thing drives me crazy. Seems like a move to promote flutter on part of google.

[mikehardy]

Shame it didn't work all the way - I wouldn't be so cynical though, AndroidX the layer beneath flutter I believe, and it's one of those painful ecosystem-wide migrations that need to happen once in a while. I'm not aware of anyone on the pure-Android side that has problems with it because in general jetifier works great, using dependencies by source inclusion is extraordinarily rare in the Android world...except react-native :-)

[matt-oakes]

I’m going to look into this as it’s clear this is going to be a pretty big pain point for the 0.60 release. I’ll report back with any updates I have on progress.