I can't get `npm run android` to work after following the steps.

[Alder-dev]

I can't get npm run android to work after following the steps.

Hi, I'm following the installation steps. I have Unity 6000.0, and I followed all the instructions, but it won't run after that.

Error code:

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':app:processDebugMainManifest'.

Incorrect package="com.animaliaar" found in source AndroidManifest.xml: E:\AnimaliaAR\App\AnimaliaAR\android\app\src\main\AndroidManifest.xml.
Setting the namespace via the package attribute in the source AndroidManifest.xml is no longer supported.
Recommendation: remove package="com.animaliaar" from the source AndroidManifest.xml: E:\AnimaliaAR\App\AnimaliaAR\android\app\src\main\AndroidManifest.xml.

• Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.14.3/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 4m 42s
346 actionable tasks: 26 executed, 1 from cache, 319 up-to-date
Error: E:\AnimaliaAR\App\AnimaliaAR\android\gradlew.bat app:assembleDebug -x lint -x test --configure-on-demand --build-cache -PreactNativeDevServerPort=8081 -PreactNativeArchitectures=arm64-v8a,armeabi-v7a exited with non-zero code: 1
Error: E:\AnimaliaAR\App\AnimaliaAR\android\gradlew.bat app:assembleDebug -x lint -x test --configure-on-demand --build-cache -PreactNativeDevServerPort=8081 -PreactNativeArchitectures=arm64-v8a,armeabi-v7a exited with non-zero code: 1
at ChildProcess.completionListener (E:\AnimaliaAR\App\AnimaliaAR\node_modules@expo\spawn-async\src\spawnAsync.ts:67:13)
at Object.onceWrapper (node:events:633:26)
at ChildProcess.emit (node:events:518:28)
at ChildProcess.cp.emit (E:\AnimaliaAR\App\AnimaliaAR\node_modules\cross-spawn\lib\enoent.js:34:29)
at maybeClose (node:internal/child_process:1101:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)
...
at spawnAsync (E:\AnimaliaAR\App\AnimaliaAR\node_modules@expo\spawn-async\src\spawnAsync.ts:28:21)
at spawnGradleAsync (E:\AnimaliaAR\App\AnimaliaAR\node_modules\expo\node_modules@expo\cli\src\start\platforms\android\gradle.ts:134:28)
at assembleAsync (E:\AnimaliaAR\App\AnimaliaAR\node_modules\expo\node_modules@expo\cli\src\start\platforms\android\gradle.ts:83:16)
at runAndroidAsync (E:\AnimaliaAR\App\AnimaliaAR\node_modules\expo\node_modules@expo\cli\src\run\android\runAndroidAsync.ts:62:24)

[JinTonic101]

@am-koan plan

[am-koan]

Now I have a complete picture of the codebase. Let me produce the updated plan.

Revised: Fix Android namespace/package build failures for AGP 8+ with Unity exports

Changes in this iteration

• Resolved Phase 2 contradiction (per review feedback): Replaced the hardcoded namespace "com.unity3d.player" injection with dynamic package-name extraction from the unityLibrary's AndroidManifest.xml. The "Gotcha" warning about com.unity3d.player not matching every project is now the core approach, not a side note. An implementer following the updated Phase 2 will extract the actual package name rather than guessing it.
• Added concrete verification criteria to Phase 0 testing (per review feedback): The Testing Strategy now specifies exact success/failure signals for the README's manual steps—build must complete without processDebugMainManifest errors, and the app must launch with the Unity view rendering. Also added a dedicated "verify documented steps" item.
• Clarified root cause scope: The reporter's error (package="com.animaliaar" in the app manifest) is a general AGP 8+ migration issue, not unique to this library. However, the same error will also hit the Unity-exported unityLibrary module (package="com.unity3d.player"), which is this library's responsibility. The plan now addresses both: documenting the app-level fix and automating the unityLibrary fix.

Summary

Android Gradle Plugin 8+ no longer allows setting a module's namespace via the package attribute in AndroidManifest.xml—it must be declared as namespace in build.gradle. When Unity exports the unityLibrary module, it generates a manifest with package="com.unity3d.player" (or a project-specific package name) and a build.gradle that may lack a namespace declaration. This causes processDebugMainManifest failures identical to the one reported. This plan updates the README with manual remediation steps for bare RN projects, and enhances the Expo config plugin (app.plugin.js) to fix the unityLibrary module automatically by dynamically reading its package name and injecting the namespace declaration.

Alternatives Considered

• Approach A (chosen): Expo plugin auto-fix + README manual steps. The Expo plugin reads the unityLibrary/src/main/AndroidManifest.xml, extracts the package attribute, injects namespace into the unityLibrary's build.gradle, and strips package= from the manifest. Manual steps are documented for non-Expo users. Trade-off: Requires the Unity export to exist at prebuild time (which it should per the documented workflow). Slightly more complex plugin code, but zero manual steps for Expo users.

• Approach B: Hardcoded namespace "com.unity3d.player" injection. Simpler implementation but incorrect for any project where Unity's export uses a different package name (e.g., com.animaliaar or a custom namespace configured in Unity). Trade-off: Breaks for any non-default Unity project configuration. Rejected because the reporter's own project uses com.animaliaar, demonstrating that com.unity3d.player is not universal.

• Approach C: Post-export script users run manually. Provide a CLI script (e.g., npx react-native-unity fix-android) that patches the exported unityLibrary. Trade-off: Extra manual step even for Expo users; easy to forget. Could be added later as a complementary tool but shouldn't be the primary solution.

Implementation Phases

Phase 0: Update README with manual steps for non-Expo users

• What: Edit README.md (lines 93–127, the Android section). After the existing step 3 ("Remove <intent-filter>..."), add a new step:

  4. If your build fails with Setting the namespace via the package attribute in the source AndroidManifest.xml is no longer supported, you need to:

  • Open unity/builds/android/unityLibrary/build.gradle and add namespace "<your-unity-package-name>" inside the android { } block (the package name can be found in unityLibrary/src/main/AndroidManifest.xml as the package attribute).
  • Remove the package="..." attribute from unityLibrary/src/main/AndroidManifest.xml.
  • If your app's own android/app/src/main/AndroidManifest.xml also contains a package="..." attribute, remove it and ensure namespace is set in android/app/build.gradle.

  Also add a note at the top of the Android section: "If you are using AGP 8+ (Gradle 8+), see step 4 for namespace migration."

• Why: Non-Expo users have no automated fix and need clear instructions. The current README has zero mention of the namespace migration, which is the chore: add support for Unity 6 on Android #1 cause of build failures with Unity 6 + modern RN templates.

• Gotchas:

  • The package name varies per Unity project—the README must tell users where to find it (in the manifest), not assume a value.
  • Some users may be on AGP 7.x where this isn't required; the step should be conditional ("if your build fails with...").

• Done when: README contains the new step with clear instructions. A developer following the steps on a bare RN 0.73+ project with Unity 6 export and AGP 8.x can resolve the processDebugMainManifest error by following the documented procedure.

Phase 1: Add unityLibrary namespace fix to Expo config plugin

• What: Edit app.plugin.js to add a new withUnityLibraryNamespaceFix modifier. This modifier:

  1. Uses withDangerousMod (Android) to read unity/builds/android/unityLibrary/src/main/AndroidManifest.xml at prebuild time.
  2. Extracts the package attribute value using a regex: package="([^"]+)".
  3. Reads unity/builds/android/unityLibrary/build.gradle.
  4. If the build.gradle does not already contain a namespace declaration: injects namespace "<extracted-package>" inside the android { } block.
  5. Removes the package="..." attribute from the manifest XML, writing back a clean <manifest xmlns:android="...">.
  6. Wire this new modifier into the withUnity function (line 12–19 of app.plugin.js), after withSettingsGradleMod.

• Why: Expo users currently hit the same processDebugMainManifest failure because the plugin doesn't address the unityLibrary's package attribute. The library's own android/build.gradle already handles its own namespace (via supportsNamespace()), but no code handles the unityLibrary module that comes from Unity's export.

• Gotchas:

  • The Unity export must exist before expo prebuild runs. This is already a requirement (the README says "Export Unity app" before anything else), but the plugin should fail gracefully with a clear error if the files don't exist rather than crashing.
  • The regex for extracting package from the manifest must handle both package="com.unity3d.player" and custom package names like package="com.animaliaar".
  • Some Unity versions (especially Unity 6+) may already include a namespace in the exported build.gradle. The plugin must check for this to avoid duplicate declarations—use a guard like if (!contents.includes('namespace')).
  • The manifest may contain other attributes on the <manifest> tag; only remove the package= attribute, not the entire tag.

• Done when: Running expo prebuild on an Expo project with a Unity 6 export that has package="com.unity3d.player" in its unityLibrary manifest produces a unityLibrary build.gradle with a namespace declaration and a manifest without the package attribute. The subsequent expo run:android builds successfully without processDebugMainManifest errors.

Phase 2: Handle the library's own AndroidManifest.xml cleanup (housekeeping)

• What: The library's own android/src/main/AndroidManifest.xml (line 2) still contains package="com.azesmwayreactnativeunity". While this is handled at runtime by the supportsNamespace() guard that switches to AndroidManifestNew.xml, the old manifest is still shipped. Since the library already requires AGP 7.3+ (the supportsNamespace() function returns true for 7.3+, and the current buildscript references AGP 7.4.2), consider:

  • Removing the supportsNamespace() conditional and always using namespace + AndroidManifestNew.xml.
  • Or: leave as-is if backward compatibility with AGP < 7.3 is still needed.

  This is a low-priority cleanup; evaluate whether any users are on AGP < 7.3 before proceeding.

• Why: Reduces confusion. New developers reading the library code see package= in the manifest and may think that's the pattern to follow. Simplifying to always use namespace sends the right signal.

• Gotchas:

  • The library's build.gradle line 8 declares classpath "com.android.tools.build:gradle:7.4.2", but this is only used for standalone library builds (e.g., in the example project). Consuming apps use their own AGP version, which is what supportsNamespace() checks at build time. Removing the guard could break consumers on old AGP versions.
  • Safest approach: keep the guard but add a comment explaining it's for backward compatibility only.

• Done when: Decision is documented (keep guard or remove it). If removing, both manifest files are consolidated and the supportsNamespace() function is removed.

Corner Cases

• Unity export doesn't exist at prebuild time: The Expo plugin must check for the existence of unity/builds/android/unityLibrary/src/main/AndroidManifest.xml and log a clear warning (not crash) if missing: "Unity Android export not found. Export your Unity project before running prebuild."
• unityLibrary build.gradle already has namespace: Unity 6+ may start including this. The plugin must detect existing namespace declarations and skip injection to avoid Gradle syntax errors from duplicate namespace lines.
• Custom Unity package names: The extracted package name could be anything (com.unity3d.player, com.mycompany.mygame, etc.). The plugin must use whatever is in the manifest, not assume a value.
• Multiple package= attributes in manifest: Unlikely but possible if the manifest has merged content. The regex should match only the package attribute on the <manifest> root element.
• Windows path separators: The reporter is on Windows (E:\AnimaliaAR\...). The Expo plugin uses path.join (line 91), which handles this correctly. Ensure any new path construction also uses path.join, not string concatenation with /.
• App-level manifest package= attribute: This is NOT the library's responsibility to fix (it's an Expo/RN project configuration issue), but the README should mention it as a common co-occurring problem.

Testing Strategy

• Phase 0 verification (manual steps):

  1. Create a bare React Native 0.73+ project (AGP 8.x).
  2. Install @artmajeur/react-native-unity.
  3. Place a Unity 6 Android export at unity/builds/android/.
  4. Follow the README steps exactly as written, including the new step 4.
  5. Pass criteria: npx react-native run-android completes without processDebugMainManifest errors. The app launches and the Unity view renders.
  6. Fail criteria: Any build error mentioning package= in a manifest, or any step that is ambiguous enough that the tester has to guess.

• Phase 1 verification (Expo plugin):

  1. Create an Expo project (SDK 50+).
  2. Install @artmajeur/react-native-unity.
  3. Place a Unity 6 Android export at unity/builds/android/ with a manifest containing package="com.unity3d.player".
  4. Run expo prebuild --clean.
  5. Verify: unity/builds/android/unityLibrary/build.gradle now contains namespace "com.unity3d.player" inside android { }.
  6. Verify: unity/builds/android/unityLibrary/src/main/AndroidManifest.xml no longer contains package=.
  7. Run expo run:android.
  8. Pass criteria: Build succeeds, app launches, Unity view renders.

• Edge case: plugin runs without Unity export:

  1. Run expo prebuild --clean without placing a Unity export.
  2. Pass criteria: Prebuild completes (or warns) without crashing. The missing-export warning is logged.

• Edge case: unityLibrary already has namespace:

  1. Manually add namespace "com.unity3d.player" to the unityLibrary's build.gradle before running prebuild.
  2. Pass criteria: No duplicate namespace line after prebuild.

Risks & Alternatives

• Risk: Unity changes its export format in a future version, breaking the regex-based manifest parsing. Mitigation: The regex is simple (package="([^"]+)"), matching a well-defined XML attribute. An XML parser would be more robust but adds a dependency for minimal gain. The guard checking for existing namespace prevents double-injection even if parsing fails.
• Risk: The withDangerousMod approach modifies files outside the standard Expo config plugin scope. Mitigation: This is the documented pattern for Expo plugins that need to modify arbitrary files (the library already uses withDangerousMod for Podfile modifications on iOS, line 82–107 of app.plugin.js).
• Alternative rejected: Patching the unityLibrary at Gradle build time (via a custom Gradle plugin or settings.gradle script) instead of at prebuild time. This would work for non-Expo users too but is significantly more complex, harder to debug, and could conflict with Unity's own Gradle configuration.

Open Questions

• Should the Expo plugin also strip <intent-filter> from the unityLibrary manifest? The README already instructs users to do this manually (step 3). Since the plugin is already going to modify the manifest for the package= fix, it would be trivial to also remove <intent-filter> blocks. This would eliminate a manual step for Expo users. Recommend: yes, add this while we're in there.
• Minimum supported AGP version: Should the library officially drop support for AGP < 7.3? The supportsNamespace() guard in android/build.gradle suggests backward compatibility is still a concern, but AGP 7.3 was released in 2022. If dropped, Phase 2 cleanup becomes straightforward.
• Should we add a post-install warning? A postinstall script could check if unity/builds/android/unityLibrary exists and whether it has a package= attribute, printing a warning. This would help non-Expo users who miss the README step. Low priority but worth considering.

⚠️ Plan review flagged unresolved items after 3 rounds — human review recommended.

• Phase 2: Testing strategy is missing — The phase is presented as an implementation phase under "Implementation Phases" but only provides "Done when: Decision is documented..." as acceptance criteria. If the decision is made to consolidate manifest files and remove the supportsNamespace() guard, the plan should specify how to test the refactored code. What tests or verification steps ensure the consolidated manifests work correctly with AGP 7.3+ and that the removed conditional doesn't break anything? Either clarify Phase 2 as a non-implementation decision point (separate from implementation phases), or add testing strategy describing how to verify the refactored code.

---

Generated by Kōan /plan — iteration on existing issue