feat(android): correctly load and present RNViews for the respective arch

[hurali97]

Summary

This refactors the current implementation in RNViewFactory and RNHostManager to allow:

• loading RN inside the respective RNViews based on the arch
• correctly load JNI libs only for new arch

Test plan

• Create a new RN app using RNEF cli with android-brownfield plugin
• Once the RN app is generated, run pnpm package:aar to generate a Aar
• After that publish the Aar to local maven by pnpm:publish-local:aar
• Then consume the published Aar in a native android App
• Run the App and present the RN View, this should work and show you "Welcome to React Native Enterprise Framework!"
• Then add reanimated as a dependency, configure it and try to add a Reanimated simple animation. Then run the following commands to generate and publish Aar.
• cd android && ./gradlew clean && cd .. && pnpm package:aar && pnpm publish-local:aar
• Clean the build folder of native android App and sync gradle files
• Then run the App. present RN View and you should see your Reanimated animation.

Below is the code we have used for presenting a simple Reanimated animation:

import React from 'react';
import {View, Text, StyleSheet, Button} from 'react-native';
import Animated, {useSharedValue, withSpring} from 'react-native-reanimated';

const Details = () => {
  const width = useSharedValue(100);

  const handlePress = () => {
    width.value = withSpring(width.value + 50);
  };

  return (
    <View
      style={{alignItems: 'center', justifyContent: 'center', marginTop: 50}}>
      <Animated.View
        style={{
          width,
          height: 100,
          backgroundColor: 'violet',
          marginBottom: 30,
        }}
      />
      <Button onPress={handlePress} title="Click me" />
    </View>
  );
};

const App = () => {
  return (
    <View style={styles.container}>
      <Text>Welcome to React Native Enterprise Framework!</Text>
      <Details />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

export default App;

The corresponding output from the native App:

Screen.Recording.2025-04-03.at.9.31.23.PM.mov

[vercel]

@hurali97 is attempting to deploy a commit to the Callstack team on Vercel, but is not a member of this team. To resolve this issue, you can:

• Make your repository public. Collaboration is free for open source and public repositories.
• Add @hurali97 as a member. A Pro subscription is required to access Vercel's collaborative features.
  • If you're the owner of the team, click here and add @hurali97 as a member.
  • If you're the user who initiated this build request, click here to request access.
  • If you're already a member of the Callstack team, make sure that your Vercel account is connected to your GitHub account.

To read more about collaboration on Vercel, click here.

[hurali97]

Do not review. I have to conduct testing.

[thymikee]

Some projects use different names for release-type build variants, e.g. „validation”. Would we need to adjust this in such case?

[hurali97]

This change has been moved to callstack/react-native-brownfield#105.

To understand this, we have two areas:

• Android App
• brownfield Aar

The brownfield Aar is basically a wrapper for RN views and APIs. This should not have more than the default buildTypes. If for some team it would make sense, then we will have to make our approach dynamic to account for all of the buildTypes. However, I do not see a purpose of doing it as of yet. For eg, react-android is a variant-aware Aar which has the default build types debug and release.

The Android App module which is basically a native App, it can have more than the default buildTypes. Like, it can have release | debug | validation. In this case, gradle looks for the specific buildType while resolving a dependency. For eg, if user is building the android app using debug build type, gradle will look for debug build type in the dependencies, if there is only one artifact in the dependency, gradle uses it to resolve for debug. BUT if the dependency is variant aware and then gradle looks for debug artifact specifically if it can not find it, gradle will throw an error.

Ideally, in all of the variant aware Aars there are 2 types handled, release and debug. For eg, react-android as explained above.

If an app has a custom buildType say validation, then gradle will fail if it can not find validation build type in dependency. In that case, a fallback should be used in the Android app's build.gradle, since it is a custom setup of the native android app and has nothing to do with the consumed dependency.

[hurali97]

We have removed the changes related to sourceSets and the tasks that were generating those sourceSets. They are now moved to callstack/react-native-brownfield#105.

It made more sense to encapsulate those changes in the brownfield-gradle-plugin so the end-user do not have to worry about those changes anymore.

We still have publications change in this PR and that can not be moved to brownfield-gradle-plugin as it contains code which can is user dependent. For example, if user decides to host the AAR on GH package they will need to tweak the publications block with the relevant changes. The scope of the changes that we have is related to generating variant aware AAR. Which means that the AAR that is published to maven contains both the debug and release variant. That is important to allow loading JNI libs based on the buildType selected by the App.

[hurali97]

The PR here needs to be merged first and released to mavenCentral. Then we can update this PR with the latest version of brownfield-gradle-plugin and merge this PR.

[thymikee]

The PR callstack/react-native-brownfield#105 needs to be merged first and released to mavenCentral. Then we can update this PR with the latest version of brownfield-gradle-plugin and merge this PR.

It's merged, so let's add the finishing touches and add a changeset (run npx @changesets/cli) and we're good to merge

[hurali97]

The PR callstack/react-native-brownfield#105 needs to be merged first and released to mavenCentral. Then we can update this PR with the latest version of brownfield-gradle-plugin and merge this PR.

It's merged, so let's add the finishing touches and add a changeset (run npx @changesets/cli) and we're good to merge

I have re-tested with the latest brownfield-gradle-plugin and looks good 👍