"We do not have native code" is the most common answer engineering teams give to Google's 16 KB requirement. It is usually wrong, and the reason is a governance gap, not a technical one.
The Requirement
Google's page size guide is direct: apps targeting Android 15 and higher "must support 16 KB memory page sizes on 64-bit devices on Google Play," and "starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates." The platform gains are real, including app launch times "3.16% lower on average" under memory pressure and boot time improved by roughly 8%, so the direction will not reverse.
Why It Is a Vendor Problem
The exemption covers apps that use only Kotlin or Java code "including all libraries or SDKs." Most production apps fail that clause without knowing it. Analytics, crash reporting, media codecs, on-device machine learning, maps, payments and anti-fraud SDKs routinely ship compiled native libraries. Google's guidance is blunt: if an app "uses any NDK libraries, either directly or indirectly through an SDK," it must be rebuilt. A compiled library inside a vendor's package can only be fixed by that vendor.
That moves the critical path outside the building. Every vendor facing this deadline faces it across its whole customer base at once, and the customers who ask first tend to get answers first.
The Trap in the Tooling
One detail illustrates why this needs verification rather than trust. On some build tool versions (Android Gradle Plugin 8.3 to 8.5), Google notes that "the app may appear to work, but when built from a bundle in Play, it won't install." A build that passes every internal check can still fail at the store.
A Four-Month Plan
- Inventory now. List every native library in the release build and the vendor that supplies it. That list is the project.
- Update the toolchain. Current build tools handle the organisation's own code by default.
- Open a ticket per vendor with an owner and a date, and escalate the ones without a roadmap. A vendor with no fix is a replacement decision, and replacements take a quarter.
- Gate the build so a future dependency upgrade cannot quietly reintroduce the problem.
- Ship before January behind a staged rollout, so the compliance release is not also a feature release.
-Rocky
#VendorRisk #Android #TechGovernance #EngineeringDreams #StrategiaX
Originally published on ANDROID-ARCHITECT, the Android engineering blog of Strategia-X.