[META] AndroidX migration plan

[dulmandakh]

Google introduced AndroidX as a new era for the Support Library https://android-developers.googleblog.com/2018/05/hello-world-androidx.html, and it is the future. I would like to talk and plan migration to it.

About AndroidX

For more information about AndroidX please visit https://developer.android.com/jetpack/androidx/.
And migration guide https://developer.android.com/jetpack/androidx/migrate.

Buck target naming

BUCK is used to run build and run tests both on Circle CI and FB internally. But there are differences in setup (or configuration) due to special requirements. And there are many complications due to this difference, which results in many Import Failed even when CI is passing.

To resolve Import failed issues and make contributions easier we need to make sure that AndroidX target names are same in both GitHub and FB, even though the setup is different.

Proposal

I think it's best to try to follow AndroidX package naming and dependency as much possible. See https://developer.android.com/jetpack/androidx/migrate

Let's assume we have third-party/android/androidx as root, then target names will be third-party/android/androidx:annotation, third-party/android/androidx:core-common, third-party/android/androidx:lifecycle-common etc.

And use exported_deps to export libraries that it depends on. For example, androidx:core-common will export itself and androidx:annotations, because it depends on it. So it's enough to import just androidx:core-common and not think about its dependencies like in Gradle.

Only AndroidX package names or targets will have visibility of PUBLIC or ReactAndroid, and other targets or implementations details remain only visible in the file. Make sure that no other BUCK rules depend on internal targets, but only exported ones.

Todo

• Agree on BUCK target naming
• Agree on deadline
• Land AndroidX in BUCK
• Land AndroidX in Gradle
• Change target names in BUCK files and package names in .java files. And export to GitHub.

[dulmandakh]

@mdvacca here is my proposal for AndroidX migration. Sorry for my poor English

[hey99xx]

I assume if RN migrates to AndroidX, statements like this:

import android.support.v4.view.ViewCompat;
import android.support.v4.net.ConnectivityManagerCompat;

etc. will also have to switch to the new path:

import androidx.core.view.ViewCompat;
import androidx.core.net.ConnectivityManagerCompat;

If brownfields apps are using v4 APIs for other things unrelated to RN, can they ship with both SupportV4 and AndroidX classes together in one APK? Is there any issue besides app size increase? Would there be any issues in runtime? For example can we render AndroidX native widgets in V4's FragmentActivity and vice-versa? Maybe you would want to incorporate these points into your proposal, more so than build tool related issues.

I'm mentioning this because there might be quite a few apps out there (including the one I work on) that make use of old support library and unfortunately will not be ready to move on to androidx for years.

That's also why I think it's too early for this migration. It's only been like 4 months since first 1.0.0 release of AndroidX. But decision is up to the package owners i.e. Facebook I guess.

Btw your English has no issues.

[dulmandakh]

created a hypothetical BUCK for AndroidX's appcompat for discussions #23120.

@hey99xx IIRC, we'll enable some Gradle flags and it'll automatically translates old support library to AndroidX during compilation. So no need to hurry to change the code.

[mdvacca]

Thanks for kicking-off this effort @dulmandakh!!!

I will be sharing the internal plan at Facebook in the next couple of days and we can start coordinating this migration.

[guhungry]

created a hypothetical BUCK for AndroidX's appcompat for discussions #23120.

@hey99xx IIRC, we'll enable some Gradle flags and it'll automatically translates old support library to AndroidX during compilation. So no need to hurry to change the code.

Yes, add below to gradle.properties file:

android.useAndroidX=true
android.enableJetifier=true

[cpojer]

@mdvacca merged AndroidX support just this week and @dulmandakh (OP) is helping with the necessary cleanup. I think it's fine to close this issue and handle the remaining work through pull requests.

[jgreen210]

Is there a plan for supporting the androidx transition in the react-native library ecosystem?

I'm trying to move our project to androidx. We've got dependencies on a variety of third-party react-native-* npm modules, some are actively maintained, some not, few (if any) support androidx. Many of these libraries have android source code embedded within them. They therefore can't be automatically fixed up by android studio (it can make the changes for you, but you'd have to upstream them all or maintain forks/patches, and that's not desirable/feasible). Neither can they be fixed up by enabling https://developer.android.com/studio/command-line/jetifier using android.enableJetifier=true in gradle.properties (it only works on aars and zips).

It looks to me like the community needs some sort of postinstall script that can do what jetifier does, but for node_modules/. Does one exist already? The closest I found was https://blog.danlew.net/2018/11/14/the-reality-of-migrating-to-androidx/ (although it would need some effort to make it cross-platform and escape regexes). Some libraries would need more work (if they generate code or don't use support lib 28.0.0) but I'm guessing that most could be fixed up automatically.

Update: the above script does nothing for version numbers, and it's generally more complicated than just replacing 28.0.0 with 1.0.0.

[joshfriend]

Since I don't see it mentioned here yet, I'll point out that v28 will be the last release of the traditional non-androidx support libraries. Android 29 (Q) will have AndroidX only support libraries.

We are currently in the first beta release of Q, the final release will be in Q3 of this year, so maybe this should be bumped up the priority list

[hramos]

Is there a plan for supporting the androidx transition in the react-native library ecosystem?
...

@jgreen210 Can you open a new discussion in https://github.com/react-native-community/discussions-and-proposals/issues? As you can tell by the late reply, people don't closely follow closed issues (I only get around them after I've read every green issue / PR notification).

[hramos]

Since I don't see it mentioned here yet, I'll point out that v28 will be the last release of the traditional non-androidx support libraries. Android 29 (Q) will have AndroidX only support libraries.

We are currently in the first beta release of Q, the final release will be in Q3 of this year, so maybe this should be bumped up the priority list

@joshfriend Support for AndroidX landed 17 days ago, you can expect this to be included in the next React Native release, 0.60. That's pretty much the highest priority that can be given to this, under the current release structure.

[bondparkerbond]

For anyone running into issues migrating npm packages to AndroidX, this package should help you Jetify them over to AndroidX if you're already on RN 60+.

[Anasmp]

#25307 (comment)

[KashifAhmed]

Well i have tried this solution for fix androidX issue and it works for me.

https://gist.github.com/janicduplessis/df9b5e3c2b2e23bbae713255bdb99f3c

[ghost]

Is AndroidX supported in RN 60+ ?

[dulmandakh]

Yes