🐞 Autolinking.json does not update correctly when switching branches with different packageName/applicationId

[AjayGol]

Description

📌 Summary:

When working with multiple branches that have different packageName / applicationId, React Native’s autolinking.json file does not update automatically. This causes native references like com.[package].R or BuildConfig to point to the wrong package, leading to build-time or runtime errors.

Steps to reproduce

🧪 Reproduction Steps:
1. Create a React Native project with 2 branches:
• development: packageName = com.mealpe
• nbs: packageName = com.nbs
2. Add native modules like CodePush or others that depend on R.string or BuildConfig.
3. Switch from development → nbs
4. Run the app (npx react-native run-android)
5. Observe errors like:

error: package com.mealpe.R does not exist

React Native Version

0.78.0

Affected Platforms

Runtime - Android

Output of npx @react-native-community/cli info

System:
  OS: macOS 15.3.1
  CPU: (8) arm64 Apple M1
  Memory: 126.33 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.20.4
    path: ~/.nvm/versions/node/v18.20.4/bin/node
  Yarn:
    version: 1.22.0
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.7.0
    path: ~/.nvm/versions/node/v18.20.4/bin/npm
  Watchman:
    version: 2025.04.14.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK:
    API Levels:
      - "30"
      - "31"
      - "32"
      - "33"
      - "34"
      - "35"
    Build Tools:
      - 30.0.3
      - 31.0.0
      - 32.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
      - 35.0.0
    System Images:
      - android-28 | Google ARM64-V8a Play ARM 64 v8a
      - android-30 | Google APIs ARM 64 v8a
      - android-31 | Intel x86_64 Atom
      - android-31 | Google APIs ARM 64 v8a
      - android-31 | Google APIs Intel x86_64 Atom
      - android-31 | Google Play ARM 64 v8a
      - android-32 | Google APIs ARM 64 v8a
      - android-32 | Google Play ARM 64 v8a
      - android-33 | Google APIs ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
      - android-34 | Google Play ARM 64 v8a
      - android-35 | Google Play ARM 64 v8a
      - android-36 | Google Play ARM 64 v8a
    Android NDK: 22.1.7171670
IDEs:
  Android Studio: 2022.1 AI-221.6008.13.2211.9619390
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 20.0.1
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react: Not Found
  react-native: Not Found
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

CodePush.getInstance(getResources().getString(com.mealpe.R.string.CodePushDeploymentKey), getApplicationContext(), com.mealpe.BuildConfig.DEBUG),

MANDATORY Reproducer

https://github.com/AjayGol

Screenshots and Videos

No response

[react-native-bot]

Warning

Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:

• For majority of bugs: send us a Pull Request with the RNTesterPlayground.js edited to reproduce your bug.
• If your bug is UI related: a Snack
• If your bug is build/upgrade related: a project using our Reproducer Template

You can read more about about it on our website: How to report a bug.

[riteshshukla04]

Could you please elaborate on the issue you're facing? The autolinking.json file is located in build/generated/linking, which is listed in .gitignore. As a result, any changes to this file won't be tracked by Git and therefore won't reflect across branches.

Maybe a reproducer with the issue might help here

[AjayGol]

@riteshshukla04
Yes, you’re right. The autolinking.json file is located in:

android/build/generated/autolinking/autolinking.json

This file contains details like the packageName and applicationId, and is generated automatically during the build process. However, since the entire build/ folder is typically listed in .gitignore, this file is not tracked by Git, and therefore any changes in one branch will not carry over or reflect in another branch automatically.

This means if I switch from one branch (e.g., development with com.abc) to another (e.g., main with com.dcf), the autolinking.json file doesn’t update.

any solution for this issue then Please let me know.

[riteshshukla04]

It’s recommended to perform a Gradle clean after changing your package ID or application ID. This helps clear any existing autolinking and build files. When you run the project again, everything will be regenerated automatically.

[AjayGol]

However, simply checking out a branch where the package name has already been changed does not require manually changing the package ID again across all files. If the changes are already applied in the branch, you just need to run a Gradle clean and then rebuild the project — manually editing the package name again is unnecessary and incorrect.

I’ve tried performing a full clean (including gradlew clean and deleting build/cache folders), but the autolinking.json file is still not updating automatically after checking out the branch where the package ID has already been changed.

It seems that even with a clean build, the autolinking configuration is not being refreshed properly. Please let me know if there are any additional steps required to force autolinking.json to regenerate based on the new package ID from the checked-out branch.

[riteshshukla04]

I’m not fully able to understand the issue yet. Ideally, cleaning the project after switching branches (with a new package ID) should reset the autolinking.json.

Could you please share a minimal repro using the Reproducer Template? That would really help maintainers to debug.