fix(mobile): pin fbjni to React Native version

[kvnloo]

Problem

Fresh Android dependency resolution can select fbjni:0.8.1 through react-native-shiki-engine's floating fbjni:+ request. That NDK 28 binary is incompatible with React Native 0.86.3's NDK 27 C++ runtime and can crash before JavaScript starts.

Fix

• Add an Expo config plugin that forces com.facebook.fbjni:fbjni:0.7.0, matching React Native 0.86.3.
• Register it beside the existing Android Gradle plugins so clean prebuilds and EAS builds get the same resolution.
• Add focused coverage for injection, idempotency, and a changed Gradle language.

Fixes #13710.

Verification

The issue has independent device/build confirmation that forcing 0.7.0 restores the expected dependency graph and launch behavior. This branch adds the config-plugin regression test; local execution was not available from this GitHub-only session, so this is opened as a draft for CI verification.

Model: GPT-5.6 Sol. Harness: ChatGPT.

Credit / provenance

• @bompus reported Android release builds crash on launch: react-native-shiki-engine resolves fbjni:+ to 0.8.1 #13710 and supplied the Android release-build crash/dependency-resolution evidence showing fbjni:+ resolving to 0.8.1. This PR turns that report into a pinned, testable build invariant.

[andybergon]

Validated this fix from c51940f31e on current main d2c9281b81:

• Fresh Gradle resolution selects fbjni 0.8.1 without the plugin and 0.7.0 (forced) with it, including shiki's + request.
• A clean release build passed for all four Android ABIs. Every packaged fbjni/C++ pair matches the official 0.7.0 AAR, and all 42 Shiki C++ imports resolve against the packaged libraries on each ABI.
• The ARM64 APK passed five cold launches on an Android 16 emulator with an empty crash buffer. Installed as an update with the same package and signer; app data remained intact. The other three ABIs were build/package-tested only.

The plugin tests, targeted lint and formatting pass. One useful addition is a test against React Native's installed version catalog so a future RN upgrade cannot silently leave this pin behind. I verified that this test fails when the force is changed to 0.8.1.

Suggested regression check for the existing test file

Add these imports:

import * as NodeFS from "node:fs";
import * as NodeModule from "node:module";
import * as NodePath from "node:path";

Add this case inside the existing describe:

it("keeps the forced native library aligned with the installed React Native runtime", async () => {
  const require = NodeModule.createRequire(import.meta.url);
  const reactNativeRoot = NodePath.dirname(require.resolve("react-native/package.json"));
  const versions = NodeFS.readFileSync(
    NodePath.join(reactNativeRoot, "gradle/libs.versions.toml"),
    "utf8",
  );
  const reactNativeFbjni = versions.match(/^fbjni\s*=\s*"([^"]+)"/m)?.[1];
  expect(reactNativeFbjni).toBeDefined();

  const generated = await transform(buildGradle);
  const forcedFbjni = generated.match(
    /resolutionStrategy\.force 'com\.facebook\.fbjni:fbjni:([^']+)'/,
  )?.[1];
  expect(forcedFbjni).toBe(reactNativeFbjni);
});

Validation and test addition: GPT-6-Astra through the Codex harness in T3 Code.

[kvnloo]

Thanks @andybergon for the thorough Android validation and the concrete regression suggestion. I added the installed React Native version-catalog check to withAndroidFbjniVersion.test.mjs, so a future RN fbjni bump should now fail instead of silently leaving the force stale. I’m not claiming a fresh green run until CI executes the new head; would appreciate a re-review after that.

[maria-rcks]

Note

Written by claude-opus-5-5 on behalf of Maria

Hi! We are cleaning up open PRs, and this one appears to have been created with an older model (gpt-5.6-sol). If this change is really important, we recommend rebuilding the PR with a newer model if possible.