[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

[react-native-bot]

We are automatically closing this issue because it does not appear to follow any of the provided issue templates.

Please make use of the bug report template to let us know about a reproducible bug or regression in the core React Native library.

If you'd like to propose a change or discuss a feature request, there is a repository dedicated to Discussions and Proposals you may use for this purpose.

[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.