Optimize Your Applications for 16 KB Page Size Compatibility Using Samsung’s Remote Test Lab
due to advancements in memory management and performance optimization, android is transitioning its kernel page size from 4 kb to 16 kb. this change impacts how applications manage memory and requires developers to ensure compatibility, and was addressed in adding 16 kb page size to android and support 16 kb page sizes. google play has also published a blog post (prepare your apps for google play’s 16 kb page size compatibility requirement) asking developers to support 16 kb page sizes in their applications. starting november 1st, 2025, all new apps and updates to existing apps submitted to google play and targeting android 15+ devices must support 16 kb page sizes. native code applications containing native code must be built to support 16 kb page sizes. refer to the official google document for detailed instructions. testing environment google android emulator provides a testing environment for 16 kb pages. for real-world testing, samsung's remote test lab offers a similar environment on actual samsung devices. see get started with remote test lab for mobile app testing, a previous remote test lab blog, to check if your application works in a 16 kb page environment. we recommend that you search using the keyword "remote test lab" in the blog list and look through other posts related to the remote test lab as well. understanding 16 kb page size for a general understanding of what a page refers to in the context of an operating system (os), see page (computer memory). you can think of it as a way of managing dram memory in units called pages. for example, if you divide a physical dram memory of 32 kb into 4 kb pages, you get 8 pages. if you divide it into 16 kb pages, you get 2 pages. this physical memory is mapped into the virtual address space of each process, and the unit of this mapping is a page. when a process accesses a specific address, it goes through a page table to access the page of the physical memory corresponding to the address. if the page size is increased from 4 kb to 16 kb, allocating and mapping a memory of 16 kb that would have used 4 operations can now be done in just one. this affects not only in-kernel memory management, but also the file system and block layer, ultimately leading to an improvement in performance. kernel mmap & application change understanding the mmap api in a linux kernel, user space processes use the mmap api to map files or devices into their virtual address space. one of the arguments in mmap is the offset, which is required to be a multiple of the page size, as shown below. failing to adhere to the requirement will fail the mmap operation. if the application logic assumes that mmap will succeed, this may cause the application to crash. the offset must be a multiple of the page size as returned by sysconf(_sc_page_size) impact of the page size change when the kernel page size changes from 4 kb to 16 kb, the mmap's offset value must now be a multiple of 16 kb, not 4 kb. in other words, on a 4 kb page kernel, offsets of 0, 4, 8, and 12 kb work correctly, but on a 16 kb page kernel, offsets of 4, 8, and 12 kb do not. you can configure these mmap operations while building an application, but it is also possible the developer did not use the mmap themselves, because in many cases the internal linker performs the mmap automatically. a linker refers to the application's executable and linkable format (elf) to perform the mmap. it's important to build the application with 16 kb pages to make sure the linker performs the mmap to the correct locations for the 16 kb page kernel. to reiterate, if your application includes native code (not just java), ensure that you have built it to support 16 kb page sizes. for guidance, refer to this google document. we have also provided a shell script that you can use to verify that your application supports the 16 kb page size.