٢٣ أغسطس ٢٠٢٤
A page is the granularity at which an operating system manages memory. Most CPUs today support a 4 KB page size and so the Android OS and applications have historically been built and optimized to run with a 4 KB page size. ARM CPUs support the larger 16 KB page size. When Android uses this larger page size, we observe an overall performance boost of 5-10% while using ~9% additional memory.
In order to improve the operating system performance overall and to give device manufacturers an option to make this trade-off, Android 15 can run with 4 KB or 16 KB page sizes.
The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix (if needed) your applications to prepare for Android devices with 16 KB page sizes in the near future.
In most CPUs, dedicated hardware called memory management units (MMUs) translate addresses from what a program is using to a physical location in memory. This translation is done on a page-size basis. Every time a program needs more memory, the operating system needs to get involved and fill out a “page table” entry, assigning that piece of memory to a process. When the page size is 4 times larger, there is 4 times less bookkeeping. So, the system can spend more time making sure your videos look great, games play well, and applications run smoothly, and less time filling out low-level operating system paperwork.
Unlike 32-bit/64-bit mode, a page size is not an Application Binary Interface (ABI). In other words, once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices.
In Android 15, we’ve refactored Android from the ground up to support running at different page sizes, thus making it page-size agnostic.
On new Android 15 based devices:
Many of our other OS components have been rewritten to avoid assuming the page size and to optimize for larger page size when available.
For performant operation, file system block size must match the page size. EROFS and F2FS file systems have been made 16 KB compatible, as has the UFS storage layer.
On 4 KB systems, ELF executable file size increases due to additional padding added for 16 KB alignment (-Wl,-z,max-page-size=16384 option), but several optimizations help us avoid this cost.
The Linux kernel is deeply tied to a specific page size, so we must choose which page size to use when building the kernel, while the rest of the operating system remains the same.
All applications with native code or dependencies need to be recompiled for compatibility with 16 KB page size devices.
Since most native code within Android applications and SDKs have been built with 4 KB page size in mind, they need to be re-aligned to 16 KB so the binaries are compatible with both 4 KB and 16 KB devices. For most applications and SDKs, this is a 2 step process:
Please see our developer documentation for more information.
NOTE: If you are an SDK or tools developer, you should add 16 KB support as soon as possible so that applications can work on 16 KB using your SDK or tools.
There are no production Android devices available today or expected for the Android 15 release that support a 16 KB page size. In order to fix this problem, we are taking steps to work with our partners to make a developer option available on existing devices. This developer option is meant for application development and testing. We are also making a 16 KB emulator target available for developers in Android Studio.
In Android 15, we implemented a developer option that lets users switch between 16 KB and 4 KB page size on the device in order to test their application with either of the page sizes. This option is available on Pixel 8 and Pixel 8 Pro starting in the Android 15 QPR1 Beta, and we're collaborating closely with SoC and OEM partners to enable the option on additional devices soon.
When built for 16 KB pages, the same binary will work with 4 KB and 16 KB devices, however the Linux kernel has to be separate. In order to solve this problem, we’ve added a way to include an extra kernel you can switch to as a developer option. Incrementally compressed, with one copy for each page size and takes ~12-16 MB of space on disk.
Using the 16 KB developer option will require wiping the device once and an unlocked bootloader. Following flashing, developers will be able to switch between a 4 KB and 16 KB mode by toggling the developer option over a reboot.
If you are a device manufacturer or SoC developer, see our instructions on how to enable and use this.
While 16 KB pages are an ARM-only feature, we recognize that many developers are using emulators on x86_64 hardware. In order to bridge this gap for developers, we’ve added support to emulate 16 KB page size for applications on x86_64 emulators. In this mode, the Kernel runs in 4 KB mode, but all addresses exposed to applications are aligned to 16 KB, and arguments to function calls such as mmap(...MAP_FIXED...) are verified to be 16 KB aligned.
To get started, you can download and run the 16 KB pages emulator inside the Android Studio SDK manager. This way, even if you don’t have access to ARM hardware, you can still ensure your applications will work with 16 KB page size.
In this post, we’ve discussed the technical details of how we are restructuring memory in Android to get faster, more performant devices. Android 15 and AOSP work with 16 KB pages, and devices can now implement 16 KB pages as a development option. This required changes from the bottom to the top of the operating system, in our development tooling, and throughout the Android ecosystem.
We are looking forward to application and SDK developers now to take advantage of these options and prepare for more performant and efficient Android devices in near future.