feat: Support autolinking C++ only TurboModules on Android

[atlj]

Summary:

#2296 adds support for auto-linking C++ turbo modules on Android. However, you would still need a build.gradle file for your module to be linked. This is for a couple of reasons:

1. If the module doesn't have a valid AndroidManifest.xml file or a bulid.gradle file, react-native config returns null. See the related line.
2. If your code doesn't have a valid packageName, react-native config returns null. We don't need the packageName property since C++ projects are included by their paths. See the related line.
3. The native-modules.gradle file tries to add your turbo module as a gradle dependency without checking if it's a valid gradle project. See the related line.
4. The generated PackageList.java file tries to include and initialize your turbo module as a Java class. See the related line.

This PR derives a property called isPureCxxDependency from a few factors:

1. The user should define cxxModuleCMakeListsModuleName as a truthy value in their configuration.
2. The user should define cxxModuleCMakeListsPath as a truthy value in their configuration.
3. The user should define cxxModuleHeaderName as a truthy value in their configuration.
4. The user shouldn't have a build.gradle file in their sourceDir (This is android/ by default) or its subdirectories.
5. The user shouldn't have a AndroidManifest.xml file in their sourceDir or its subdirectories.

If all these cases are met, the CLI outputs the isPureCxxDependency property as true. This in turn causes the native-modules.gradle file not to include this dependency in the generated PackageList.java file and the dependency isn't added as a gradle dependency to the app project.

Test Plan:

I have created a turbo module using create-react-native-library. Then I linked the CLI and tested the implementation. I've also added react-native-reanimated as a dependency to the project's example app to make sure this implementation doesn't break the existing support for turbo modules.

Checklist

• [x] Documentation is up to date to reflect these changes.
• [x] Follows commit message convention described in CONTRIBUTING.md

[cortinico]

Thanks for sending this over @atlj this is great!

platforms.android.cxxOnly

I think we should not add a new property, and instead adapt the logic to work on the existing properties:

  cxxModuleCMakeListsModuleName?: string | null;
  cxxModuleCMakeListsPath?: string | null;
  cxxModuleHeaderName?: string | null;

and remove the assumption that there needs to be a *Package file.

[atlj]

Hey @cortinico I've removed the property from the config. The CLI now treats a dependency that doesn't have a manifest or a build.gradle file (full details in the description) as a pure cxx dependency.

[cortinico]

Hey @cortinico I've removed the property from the config. The CLI now treats a dependency that doesn't have a manifest or a build.gradle file (full details in the description) as a pure cxx dependency.

Thanks for the sending this over. I'll try to review this in the next days. Just a heads up that things are slower than usual those days due to https://conf.react.dev/

[cortinico]

Just a heads up that if we merge this, the same functionality needs to be backported here: https://github.com/facebook/react-native/blob/main/packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/tasks/GenerateAutolinkingNewArchitecturesFileTask.kt

[thymikee]

@cortinico is there any design doc around autolinking in the core RN repo? Does it clash somehow with RNCCLI autolinking, doing redundant work, bailing out?

[cortinico]

is there any design doc around autolinking in the core RN repo? Does it clash somehow with RNCCLI autolinking, doing redundant work, bailing out?

Nope I don't have a design doc sadly, but I just ported over all the code from native_modules.gradle inside RNGP.

We should update native_modules.gradle in the near future (i.e. sometime next week), and fire a warning as the template will be updated to don't include that file anymore (see https://github.com/facebook/react-native/pull/44799 for more context). Running config and parsing all the configuration will remain inside the CLI though.

[thymikee]

Thanks, that makes it clearer I think! So we keep autolinking until it's deployed in the core (0.75?) and once it has parity, we can start removing it from this codebase?

[cortinico]

Thanks, that makes it clearer I think! So we keep autolinking until it's deployed in the core (0.75?) and once it has parity, we can start removing it from this codebase?

We can keep it around, I was actually thinking about updating the native_modules.gradle file to just emit a warning in 0.75 so that users won't accidentally include both core + cli ones

[thymikee]

Thanks @atlj! Please contact Nico on how this can be ported to the RNGP in core repo

[cortinico]

@atlj can you open an issue on github.com/facebook/react-native to keep track of this upstreaming?

[cortinico]

Pick for core is here https://github.com/reactwg/react-native-releases/issues/375

[hsjoberg]

Hi @atlj, just checking in here before I file a bug report upstream.

Does this still work in react-native 0.75+? I updated your example project here https://github.com/hsjoberg/rn75autolinkregression without doing any other changes.

However, on Android I get error on the new autolinkLibrariesWithApp() RNGP function that was added for android/app/build.gradle in react-native 0.75. It doesn't appear to respect pure C++-only TurboModules as gradle will try to find a gradle dependency for the lib:

BUILD FAILED in 10s
error Failed to install the app. Command failed with exit code 1: ./gradlew app:installDebug -PreactNativeDevServerPort=8081 FAILURE: Build completed with 2 failures. 1: Task failed with an exception.
-----------
* Where:
Build file '/Users/coco/Projects/Blixt/1/TurboLnd/example/android/app/build.gradle' line: 54 * What went wrong:
A problem occurred evaluating project ':app'.
> Project with path ':react-native-cxx-turbomodule' could not be found in project ':app'.

Simply removing autolinkLibrariesWithApp() fixes the issue you everything works all good (but ofc won't work in a real project). I tried looking into the react-native gradle plugin but couldn't find anything yet.

[szymonrybczak]

hey @hsjoberg, what's the output of npx @react-native-community/cli config command?

[hsjoberg]

@szymonrybczak Oh right I forgot to tell about that one. It still interestingly enough reports "isPureCxxDependency": true.

{
  "root": "/Users/coco/Projects/Blixt/1/TurboLnd/example",
  "reactNativePath": "/Users/coco/Projects/Blixt/1/TurboLnd/example/node_modules/react-native",
  "reactNativeVersion": "0.75",
  "dependencies": {
    "react-native-turbo-lnd": {
      "root": "/Users/coco/Projects/Blixt/1/TurboLnd",
      "name": "react-native-turbo-lnd",
      "platforms": {
        "ios": {
          "podspecPath": "/Users/coco/Projects/Blixt/1/TurboLnd/react-native-turbo-lnd.podspec",
          "version": "0.1.0",
          "configurations": [],
          "scriptPhases": []
        },
        "android": {
          "sourceDir": "/Users/coco/Projects/Blixt/1/TurboLnd/cpp",
          "packageImportPath": null,
          "packageInstance": null,
          "buildTypes": [],
          "libraryName": "RNTurboLndSpec",
          "componentDescriptors": [],
          "cmakeListsPath": "/Users/coco/Projects/Blixt/1/TurboLnd/cpp/build/generated/source/codegen/jni/CMakeLists.txt",
          "cxxModuleCMakeListsModuleName": "TurboLnd",
          "cxxModuleCMakeListsPath": "/Users/coco/Projects/Blixt/1/TurboLnd/cpp/CMakeLists.txt",
          "cxxModuleHeaderName": "TurboLndModule",
          "isPureCxxDependency": true
        }
      }
    }
  }
  <n.b: commands omitted>
}

[szymonrybczak]

@hsjoberg at first look output looks right 🤔 maybe it's something in new autolinking integration in React Native Core? @cortinico any ideas?

[hsjoberg]

at first look output looks right 🤔

Yeah. 🤔 I think there has been a regression recently.

Mind you, it all works well if I delete autolinkLibrariesWithApp(), as to not cause any gradle dependency autolinking by RNGP, indicating that cli handles the pure C++ TM correctly. My guess would be that there is something wrong in RNGP.

[cortinico]

My guess would be that there is something wrong in RNGP.

Can very much be. I definitely ported this feature inside RNGP but it can be we missed a parameter of a field somewhere. @hsjoberg Is TurboLnd a public dependency? Can we create a reproducer with https://github.com/react-native-community/reproducer-react-native + that dependency to reproduce the failure?

[hsjoberg]

@cortinico It is public yes, https://github.com/hsjoberg/react-native-turbo-lnd, but not deployed to npm.

But please instead see the small reproducer project I made here: https://github.com/hsjoberg/rn75autolinkregression It's just @atlj's demo project for this PR, but updated to react-native 0.75.2. I was just in the wrong project when I did the npx @react-native-community/cli config. It's observable with the bare minimum.

[hsjoberg]

@cortinico FYI, I believe I found the problem. I've submitted a pull request to the react-native repo.

https://github.com/facebook/react-native/pull/46381