Idea: keep React Native native libraries to the processors you ship

[AmineYagoub]

The problem. React Native's Gradle plugin adds pickFirsts rules such as **/libreactnative.so, **/libjsi.so, **/libfbjni.so, **/libc++_shared.so and **/libhermesvm.so. In Android's packaging, a pick-first rule wins over an exclude. So an app that limits its processors still ships every prebuilt library for all four: armeabi-v7a, arm64-v8a, x86 and x86_64.

What it cost us. In Minhajna (djazairdev/minhajna#105), the universal APK meant for ARM phones came out at 65,053,601 bytes, with x86 and x86_64 code inside. packaging.jniLibs.excludes did nothing, and reading the rules in onVariants failed with "configuration not completed".

The fix, in apps/android/android/app/build.gradle:

• empty the pick-first rules in androidComponents.onVariants;
• add them back as lib/<abi>/<lib> for the processors actually built;
• exclude the other processors.

The universal APK dropped to 34,443,995 bytes. A check in CI (tools/android/release-apks.js) now rejects any APK that carries a processor it shouldn't.

Who else it hits. Any React Native app that ships ARM only, splits its APKs by processor, or watches its download size, which matters most where data is expensive. Most apps never notice: the APK installs and runs, and is simply twice as big.

What to build

• A small Gradle plugin, or a React Native config plugin, that reads the processors an app builds for. It would narrow React Native's pick-first rules to those, exclude the rest, and fail the build if a stray processor's library slips in.
• A short write-up with the before-and-after sizes, and a fix to propose upstream in @react-native/gradle-plugin.

Size: small. The logic is about 15 lines of Gradle, plus tests on a sample app. MIT or Apache-2.0, to match React Native.

From Minhajna's work; drafted with Claude Code.