Mishal Ibrar
000
Back to work
CLI2026Creator & Maintainer

(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
3Evidence tiers, APK-verified
Maven coordinates resolved
293Maven coordinates resolved
Runtime dependencies
ZeroRuntime dependencies
RN 16K — React Native 16 KB Page Size Checker
Node.jsReact NativeAndroidGradleELF / ZIP analysisGitHub Actions

(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.

Industry
Developer Tooling
Platform
CLI (Node.js) for React Native on Android
Role
Creator & Maintainer
Duration
2026
Updated
August 2026

Screen patterns

  • Project Analysis
  • Maven Graph Resolution
  • APK Verification
  • Blocker Attribution

User flows

  • Tier 0 to Tier 2 Escalation
  • Failing Library Attribution
  • CI Blocker Gate

Key UI elements

  • Evidence Tier Badge
  • ELF Alignment Check
  • ZIP Alignment Check
  • SARIF Upload

Stack

  • Node.js
  • React Native
  • Android
  • Gradle
  • ELF / ZIP analysis
  • GitHub Actions