(04) — case study
RN 16K
React Native 16 KB Page Size Checker
A zero-dependency CLI that decides whether a React Native Android app meets Android 15's 16 KB page size requirement. It resolves the transitive Maven graph that node_modules alone never shows, checks ELF segment and APK ZIP alignment without the Android SDK, and attributes every failing library back to the dependency that shipped it.
- Evidence tiers, APK-verified
- 3
- Maven coordinates resolved
- 293
- Runtime dependencies
- Zero

(01) — the build
Overview
Android 15 introduced Google's 16 KB memory page size requirement for 64-bit apps. A React Native app carries native binaries from React Native itself, from npm packages, from source-built modules, and from transitive Maven dependencies, so the requirement lands in several places at once.
The difficult part is that scanning node_modules is not enough. Important native libraries arrive through Maven AARs and never appear as files inside the JavaScript dependency tree.
rn16k is a zero-dependency CLI that analyses a React Native Android project and determines whether its native libraries meet the 16 KB requirement. The whole report starts with a single command, npx rn16k.
The Challenge
Teams hitting this requirement had to reason about it manually across:
- npm packages shipping prebuilt .so files
- Native modules compiled from source by the project's own NDK
- Transitive Maven SDKs that never touch node_modules
- ELF segment alignment inside every 64-bit shared library
- ZIP alignment of uncompressed .so entries inside the APK
- A Play Console rejection that names none of the above
The goal was to turn a confusing rejection into an actionable engineering report that says what is wrong, where it came from, and what to upgrade.
Solution
With a single command, rn16k can:
- Scan installed packages for native libraries
- Resolve the full transitive Maven dependency graph through Gradle
- Inspect cached AARs
- Build a release APK when necessary
- Verify the actual shipped artifact
- Identify libraries that fail the requirement
- Attribute each failure back to the package responsible
- Report the first known version that fixes the issue
Evidence Tiers
The key design decision was to refuse to treat "no known blockers" as proof of compliance. Every run states how strong its evidence actually is.
- Tier 0: static project analysis
- Tier 1: project analysis plus Maven dependency resolution
- Tier 2: verification of a real APK
Only Tier 2 can produce the strongest verified verdict, because it checks the artifact that ultimately ships.
Technical Implementation
The checker validates both sides of the 16 KB requirement.
- ELF PT_LOAD segment alignment for every 64-bit .so
- ZIP alignment of uncompressed .so files inside the APK
It checks the ELF congruence condition rather than relying on p_align alone, which prevents false-positive passes on binaries that declare a 16 KB alignment they do not actually satisfy.
The tool is implemented without runtime dependencies and uses Node.js built-ins for its core functionality. Binary analysis needs no Android Studio, no llvm-objdump, no zipalign and no Android SDK.
Dependency Attribution
The report does not stop at "this .so is broken." It answers the question that follows: which dependency caused this, and what version fixes it? Attribution covers npm packages, transitive Maven SDKs, and libraries affected by the project's own NDK configuration.
Validation
rn16k was validated against Google's own tooling. On a production React Native application containing 1,314 npm packages, 293 resolved Maven coordinates, 72 native libraries and 36 64-bit libraries, it agreed with independent llvm-objdump ELF checks and with Google's zipalign verification. All three approaches reported the same alignment result.
Synthetic binaries built with different NDK versions were also tested, and rn16k matched the expected 4 KB and 16 KB alignment results.
CI/CD
The project ships GitHub Actions support, so teams can fail CI when a 16 KB blocker is detected and optionally upload SARIF results for code scanning.
Security
The tool is designed to run against source trees and CI environments, so security was treated as part of the implementation.
- Zero runtime dependencies
- No install scripts
- No telemetry
- No network access during normal scanning
- No modification of the user's project
- Bounded binary and archive parsing
- Protected path handling
- Redacted project paths in output
- Signed release provenance through Sigstore
Tech Stack
- Runtime: Node.js, zero runtime dependencies
- Target: React Native, Android 15+, 64-bit ABIs
- Build integration: Gradle, Maven dependency resolution, AAR inspection
- Binary analysis: ELF PT_LOAD parsing, ZIP alignment verification
- Automation: GitHub Actions, SARIF code scanning
- Distribution: npm, Sigstore release provenance
Open Source
rn16k is released as an independent MIT-licensed open-source project. It is not affiliated with Google, Android, or Meta.
The Result
Instead of manually investigating Android 15's 16 KB compatibility requirements across npm packages, Maven dependencies, native binaries and APK alignment, developers start with one command and get an evidence-based report explaining what is wrong, where it came from, and what to upgrade.