Better Android Gradle Plugin 3.x integration

[CFKevinRef]

Motivation

Better integration with the Android Gradle-based build process, especially the changes introduced by the Android Gradle Plugin 3.x and AAPT2.

Fixes #16906, the android.enableAapt2=false workaround is no longer required.

Bases the task generation process on the actual application variants present in the project. The current manual process of iterating build types and product flavors could break down when more than one dimension type is present (see https://developer.android.com/studio/build/build-variants.html#flavor-dimensions).

This also exposes a very basic set of properties in the build tasks, so that other tasks can more reliably access them:

android.applicationVariants.all { variant ->
    // This is the generated task itself:
    def reactBundleTask = variant.bundleJsAndAssets
    // These are the outputs by type:
    def resFileCollection = reactBundleTask.generatedResFolders
    def assetsFileCollection = reactBundleTask.generatedAssetsFolders
}

Test Plan

I've tested various combinations of product flavors and build types (Build Variants) to make sure this is consistent. This is a port of what we're currently deploying to our CI process.

Release Notes

[ ANDROID ] [ BUGFIX ] [ react.gradle ] - Support Android Gradle Plugin 3.x and AAPT2
[ ANDROID ] [ FEATURE ] [ react.gradle ] - Expose the bundling task and its outputs via ext properties

[ide]

I'm not that familiar with Gradle but this looks like fairly compatible with the directories the existing Gradle script was working with.

@hramos any objection from FB's side to landing Gradle commits?

[nitaliano]

There is also this PR #17747 that updates gradle and Android SDK version

[ide]

not sure we want these destructive actions during the build step (vs in a clean step)

[CFKevinRef]

This is generally how the internal Android tasks work (example) - the full task clears its destination directory and places its outputs there. Directories aren't shared by tasks or merged at any point, they're separate source sets eventually merged into the final package automatically.

As far as I can tell, react-native bundle always regenerates a full bundle anyway. Keeping the directory around doesn't provide a benefit, but introduces the possibility of old assets being included until a manual clean.

We still have to do the somewhat hacky copy to $buildDir/intermediates/assets/${targetPath} below because unfortunately we only have variant.registerGeneratedResFolders() and not variant.registerGeneratedAssetsFolders().

[hramos]

@ide It should be fine. We don't use Gradle internally (aside from running a test to ensure the project can be built using Gradle, to ensure CI does not break when the commit syncs out).

[ide]

OK, this seems fine to me.

@facebook-github-bot shipit

[facebook-github-bot]

Something went wrong executing that command, @hramos could you take a look?

[facebook-github-bot]

@ide is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[charpeni]

Looks like we can't build from source anymore with the default gradle setup in master or 0.54.

https://facebook.github.io/react-native/docs/android-building-from-source.html

[ujwal-setlur]

This worked for me with gradle-4.6 and gradle plugin 3.0.1. This was critical for me since I use react-native-maps which demands an upgraded gradle. I think react-native needs to upgrade its gradle, but I don't know what the impact of third party libraries is.

Thank you @CFKevinRef

[compojoom]

What happened to this? d16ff3b - here it says 0.55, but this fix is not in 0.55 that was released few hours ago?

[hramos]

If the commit has the tag, then it should be in the accompanying release. What we ship to npm is built from those tags, it shouldn't be possible for the commit to not make it into the release.

[charpeni]

From what I could recall, d16ff3b have been reverted because we couldn't build from source with these changes.

[ujwal-setlur]

Yes, that's what I recall seeing.

[jameslporter]

Would be great to get this released and working, been reported since June in various related issues.

[SharpMobileCode]

What is the status of this? Is this going to get re-merged or not? android.enableAapt2=false is throwing warning with Android Studio 3.1.x saying that it will be removed at the end of 2018. So that means a lot of people are going to be in a world of hurt if this doesn't get addressed. This should be a priority.

[MarkOSullivan94]

I wouldn't be surprised to see more people try out Flutter

[charpeni]

This is a priority, we're still on this.

#17747 looks like a good candidate to land an updated Gradle and Android.

[CodingPapi]

Any news on this?
Stucked, set aapt2=false cause other problems in my project

[hramos]

@janicduplessis re-opened.

[facebook-github-bot]

I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification.

[CFKevinRef]

I can resolve the conflict by effectively backing out Android - Fix Drawable v4 paths in Android Artifact Resources (Libraries) as I believe this makes it redundant, but I need to find/create a test case to be sure.

[CFKevinRef]

OK, up to date with master and using fallbacks for at least plugin 2.3.3.

[ITsolution-git]

@CFKevinRef .
This works, Really saved my life. Thank you.

Is it possible to merge this PR? Thanks.

[CFKevinRef]

Closing since #20526 (mirror of this one) just landed!