React Native's Platform Build Glue
React Native integrates into Android via Gradle files. You edit settings.gradle and both build.gradle files to wire the React Native Gradle Plugin and enable autolinking. The footgun: editing the wrong build.gradle breaks native modules silently.
Why it exists
React Native runs JavaScript inside a native app, but the Android build system has no native knowledge of JavaScript packages or native modules shipped inside NPM dependencies. The platform-specific configuration files exist to bridge this gap, teaching Gradle how to find, link, and bundle React Native code alongside existing Java or Kotlin source.
The mental model
Think of it as installing a foreign engine into a car. The engine itself is portable, but the mounting brackets, fuel lines, and electrical connectors must be fabricated specifically for the chassis. On Android, those connectors are Gradle scripts. They do not ship with your existing app; you must bolt them on so the JavaScript runtime can start and native modules can register themselves.
How it works
Integration requires editing three separate Gradle files. First, settings.gradle points to the React Native Gradle Plugin inside node_modules and enables autolinking via the ReactSettingsExtension. Second, the top-level build.gradle adds the plugin to the buildscript classpath so Gradle can resolve it. Third, the app-level build.gradle applies the com.facebook.react plugin, adds the react-android and hermes-android dependencies, and calls autolinkLibrariesWithApp inside a react block. Each file has a distinct responsibility, and they must be modified in concert.
When to use it
Use this approach when you are adding React Native screens or features to an existing Android application rather than starting fresh with a framework like Expo. It is also the path you follow when brownfielding a legacy native app where rewriting the entire codebase is not an option.
When not to use it
Do not use manual Gradle integration if you are building a new greenfield app from scratch. In that case, a framework or the Community Template handles these files automatically. You should also avoid this path if your team lacks Android build expertise, because Gradle errors are opaque and debugging them requires reading native build logs.
One canonical example
You have an existing Kotlin banking app and want to add a React Native dashboard. You move the Android project into an android subdirectory, add a package.json, and install dependencies. Then you edit settings.gradle to include the React Native Gradle Plugin from node_modules and enable autolinking. In the top-level build.gradle you add the plugin classpath. In the app build.gradle you apply the com.facebook.react plugin, add implementation lines for react-android and hermes-android, and configure autolinkLibrariesWithApp. If you accidentally edit the top-level build.gradle dependencies block instead of the app-level one, the app compiles but native modules like encryption libraries never link, causing runtime crashes when the dashboard tries to use them.
Interview question
When integrating React Native into an existing Android app, which scenario describes the silent Gradle footgun that breaks native modules after a successful compile?
- a.The build fails immediately with a classpath error because the React Native plugin classpath was added to the app-level build.gradle instead of the top-level one.
- b.The build fails during sync because settings.gradle attempts to add the react-android dependency instead of pointing to the React Native Gradle Plugin location.
- c.The app compiles and launches, but native modules crash at runtime because implementation dependencies and autolinking were configured in the top-level build.gradle rather than the app-level one.Correct
- d.The build fails during configuration because the com.facebook.react plugin was applied in the top-level build.gradle rather than the app-level one.
Why? this is the answer
The card explicitly warns that adding implementation dependencies and autolinkLibrariesWithApp to the top-level build.gradle instead of the app-level one causes the app to compile while native modules silently fail to link at runtime. Distractor A describes a related top-level versus app-level confusion, but misplacing the classpath triggers an immediate build error rather than a silent runtime footgun.
Just read this? Test yourself on what you have been reading.
Read the original → reactnative.dev
- #react-native
- #android
- #gradle
- #brownfield
- #native-modules
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react-native — each one lists the topics its interview covers.
See open roles