[META] AndroidX migration plan
dulmandakh opened this issue · 17 comments
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.
@mdvacca here is my proposal for AndroidX migration. Sorry for my poor English
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.
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.
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.
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@guhungry It'll be automatically added when you migrate to AndroidX and it doesn't help to resolve issues with old support library usages in react-native modules like rn-fetch-blob, react-native-webview, react-native-sentry and etc. It's very annoying for me to try to resolve this issues in my android project because I don't want to wait until this issues will be fixed in new versions (I mean, I don't want to hold androidx migration in my project). And unfortunately, I don't have enough time to contribute to this projects.
@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.
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.
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
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).
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.
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+.
Well i have tried this solution for fix androidX issue and it works for me.
https://gist.github.com/janicduplessis/df9b5e3c2b2e23bbae713255bdb99f3c
Is AndroidX supported in RN 60+ ?