feat: autolinking for Android with Gradle

[Salakar]

Provides the Android/Gradle functionality to go with #256 & #254

CLI Changes

• Updated react-native config to include the android sourceDir for react native module packages

---

Usage

These are the one-off changes required to enable this in the React Native init template (or for existing user projects).

Modify android/settings.gradle

Include the following line in your Android projects settings.gradle file:

apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)

Modify android/app/build.gradle

Add the following line at the bottom of your Android projects android/app/build.gradle file:

apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)

Modify MainApplication.java

Import the PackageList class;

import com.facebook.react.PackageList;

Replace the protected List<ReactPackage> getPackages() method with the following:

    @Override
    protected List<ReactPackage> getPackages() {
      @SuppressWarnings("UnnecessaryLocalVariable")
      List<ReactPackage> packages = new PackageList(this).getPackages();
      // additional non auto detected packages can still be added here:
      // packages.add(new SomeReactNativePackage());
      return packages;
    }

Testing

I've tested the following scenarios locally:

• User has no React Native global CLI installed
  • Will warn but continue without issue
• User has no React Native packages installed yet
  • Continues as normal with no warning
• User has more than one React Native package installed
  • Correctly adds multiple packages without issue
• User has a package installed that does not support autodetection (config == null)
  • Prints a warning but continues gracefully
• User has custom/non-linked React Native packages
  • Can be sucessfully manually added via packages.add(new SomeReactNativePackage()); as documented above in MainApplication.java

To test this in a new react-native init project locally:

• Clone the CLI project
• Run yarn in the CLI project
• Run cd packages/cli && yarn && yarn link in the CLI project
  • (a little hacky as it's a mono-repo)
• Run yarn link "@react-native-community/cli" on your React Native project
• Make the required changes as above to your React Native project

---

Codegen Output Example

An example of the generated PackageList.java class:

package com.facebook.react;

import android.app.Application;
import android.content.Context;
import android.content.res.Resources;

import com.facebook.react.ReactPackage;
import com.facebook.react.shell.MainReactPackage;
import java.util.Arrays;
import java.util.List;

import com.test.BuildConfig;

// react-native-webview
import com.reactnativecommunity.webview.RNCWebViewPackage;

public class PackageList {
  private ReactNativeHost reactNativeHost;
  public PackageList(ReactNativeHost reactNativeHost) {
    this.reactNativeHost = reactNativeHost;
  }

  private ReactNativeHost getReactNativeHost() {
    return this.reactNativeHost;
  }

  private Resources getResources() {
    return this.getApplication().getResources();
  }

  private Application getApplication() {
    return this.reactNativeHost.getApplication();
  }

  private Context getApplicationContext() {
    return this.getApplication().getApplicationContext();
  }

  public List<ReactPackage> getPackages() {
    return Arrays.<ReactPackage>asList(
      new MainReactPackage(),
      new RNCWebViewPackage()
    );
  }
}

[Salakar]

cc @dulmandakh & @bartolkaruza for review

[grabbou]

Before reviewing, I'll implement JS changes you did here over in my PR, so you can rebase the branch. That way, it will merge cleanly.

Going to attempt a review next week, on Monday.

[grabbou]

Regarding:

I've tested the following scenarios locally:

Shall we also make sure that we print similar messages on iOS, e.g. when the package is not supported or global CLI wasn't recognised?

[Salakar]

Shall we also make sure that we print similar messages on iOS, e.g. when the package is not supported or global CLI wasn't recognised?

I think so - cc @alloy @orta - what are your thoughts on this?

[alloy]

I definitely think we should try to be helpful, but I think we should do this when the user uses react-native install [pkg] by running the spec validation (react-native validate [pkg]?), as that’s the time we know their intent. Afterwards, during eg pod install I personally prefer only relevant output (unless perhaps —verbose is passed), i.e. not list all packages that are not included. I’ll need to read the PR more to make sure I fully understand the other warnings.

[punksta]

This looks much better than javascript linking!
There are react-native packages with constructor accepts parameters. For example new FBSDKPackage(mCallbackManager) from https://github.com/facebook/react-native-fbsdk#31-android.

Will there be a way of excluding package from auto-linking? annotations may be used.

@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.TYPE)
public @interface NoAutoLink {
   String message();
}

@NoAutoLink(message = "Link module manually, providing ReactApplication class instance")
class LibraryPackage {
    public LibraryPackage(ReactApplication application) {
     
    }
}

[Salakar]

Hey @punksta, I was just discussing args support with @grabbou - for now, we'd look at only supporting arguments where they are set up already to be linked, for example https://github.com/Microsoft/react-native-code-push/blob/master/package.json#L45 is one I'm looking at supporting as it works as is currently on the old way of linking.

Whereas the FBSDK one you linked doesn't link the package with args by default - you have to manually link it, so probably not a scenario we'd support yet.

---

For excluding packages from auto-linking, this can be configured in the CLI config (not sure where yet 😅), when it tells us in the config that the Android config is null we skip linking.

[grabbou]

Ideally, fbsdk would provide a custom packageInstance property in their package.json so that we know it needs extra parameters.

Alternatively, maybe we can guess it and provide some stubs?

Will there be a way of excluding package from auto-linking? annotations may be used.

We are keeping JavaScript as a source of truth, so you will be able to modify settings for each package (in case it has broken settings or doesn't link properly, e.g. providing that custom packageInstance yourself to tell us to use it to link fbsdk or just disable linking on Android/iOS/both entirely). Details to follow in my PR #254

[Salakar]

Updated to work with latest config changes + new platform-android package

cc @grabbou @thymikee

[thymikee]

Left small comments to address, but this looks good! Is there a chance we could add a smoke test for that, similar to CocoaPods version?

cli/package.json

Line 13 in a759214

"test:ci:cocoapods": "ruby packages/platform-ios/native_modules.rb",

[Salakar]

@thymikee changes requested have been made, thanks for the review 🎉

For testing: the only way I can see testing being added is if we set up an Android project and run a build and validate that it:

1. builds the apk without error
2. the generated output at generated/rncli/src/main/java/com/facebook/react/PackageList.java contains the RN modules that should be available as part of the test (e.g. yarn add react-native-webview)

I think this should be based off the RN template though, init a fresh project as part of the test, add a couple of RN modules via npm/yarn, build android and validate output.

Current problem is the template is not yet live with the new changes so not sure how best to do this until then? Thoughts? Or shall we add test suites once the template is live on RN master? This will also need Windows testing for CI - have tested locally though for Mac + Windows.

[thymikee]

RN can technically be in monorepo so we can't make assumptions about where node_modules with cli are. That's why in iOS implementation we spawn a Node process and use its require.resolve to output the resolved path to stdout

[Salakar]

This is handled by the final arg here:

cli/packages/platform-android/native_modules.gradle

Line 178 in 7a7115f

cmdProcess = Runtime.getRuntime().exec(REACT_NATIVE_CONFIG_CMD, null, getReactNativeProjectRoot())

- the process is spawned relative to the project root, which can also be overridden here:

cli/packages/platform-android/native_modules.gradle

Line 114 in 7a7115f

if (this.extension.has("reactNativeProjectRoot")) {

[thymikee]

Ok, so it won't be seamless but at least that's supported. We need to add documentation on how the autolinking is working on how to configure it.

[grabbou]

@Salakar, we already have config.root in our config outputted from react-native config. You could use that one.

Also, you can just do console.log(require.resolve('react-native')) script and exec node to get the exact location. I think this is what we use on iOS.

[thymikee]

I'm cool with waiting for RN to publish the new template and using that as a source. Or you could publish a custom template (based on the PR you made to RN) and create a custom test in e2e/ directory. See how the new template looks like: https://github.com/Esemesek/react-native-new-template/ (basically a template.config.js with a path to the template that will be straight copied over to your project)

[grabbou]

I am wondering if there's any way we can wrap an instance of ReactPackage here to LazyReactPackage. By default, packageClassInstance is e.g. new CodePushPackage() and in order to convert it to a LazyPackage, we would have to update that package itself.

Is there a way to wrap it or create our custom lazy package for each ReactPackage, that will lazily create it and return everything what's needed?

[Salakar]

I think the CodePushPackage class itself would need to extend LazyReactPackage instead of ReactPackage for this to work? Not something we can do? 🤷‍♂️

Would forcing every package to be lazy also cause issues for packages that are not inherently meant to be lazy, e.g. modules that have app initialization logic that must always be run?

Not 100% sure

[thymikee]

let's give it a shot!