Transition to using 16 KB page sizes for Android apps and games

I realize that most apps wouldn’t need to make changes and that a recompilation would suffice, but is this time frame enough for the apps that do need code changes?

https://android-developers.googleblog.com/2022/04/expanding-...

You have to update an application every year, even if it is just meaningless version bump. Otherwise it will be removed after 2 years. Despite saying that this policy is required to ensure user security, several recent Android releases didn't have any corresponding major security changes.

It could be that Google explicitly wants to dump un(der) maintained apps. Sure some might be clean and basic utilities that will work till the end of time, but many are probably abandonware or crummy demos and hello-world apps that look old and dated. They went on a whole purge recently already.

The App Store market is changing as Google/Apple grapple with efforts to end their monopolies. Maybe they're seeing that change and trying to use their dying advantage to frame themselves as the curated and reputable stores with high-quality maintained and up to date apps. When distribution is available from other places, they can chose their customers.

- On Android, apps are built with targetSdkVersion set to the API version you're app is compiled for and tested against, but you cam set a lower minSdkVersion to the lowest device API version your app will run on.

- On devices with API level newer than targetSdkVersion, the OS looks at your app's targetSdkVersion and disables newer behaviours than your app is targetting. So the app should run well on newer devices.

- On devices with API level older than targetSdkVersion, but newer than (or same as) minSdkVersion, your own app is responsible for detecting missing APIs before trying to use them, and adapting itself to the older environment.

- On devices with API level older than minSdkVersion, your app will not be run. This ensures the user gets a clear failure, rather than unpredictable crashes or unexpected behaviour due to missing APIs the app tries to call.

So, in principle, it's possible to build an app which targets the most recent Android 15, while being capable of running on all versions of Android back to version 1. Apps linked for 16 kiB page-alignment should run on older devices that use 4 kiB pages too.

The Google Play Store enforces that targetSdkVersion is fairly close to the latest Android version. But it doesn't place requirements on minSdkVersion.

If you rely on being able to do things like mark a range of memory as read-only or executable, you now have to care about page sizes. If your code is still assuming 4KB pages you may try to change the protection of a subset of a page and it will either fail to do what you want or change way too much. In both cases weird failures will result.

It also can have performance consequences. For example, if before you were making a lot of 3.5KB allocations using mmap, the wastage involved in allocating a 4KB page for each one might not have been too bad. But now those 3.5KB allocations will eat a whole 16KB page, making your app waste a lot of memory. Ideally most applications aren't using mmap directly for this sort of thing though. I could imagine it making life harder for the authors of JIT compilers.

Some algorithms also take advantage of the page size to do addressing tricks. For example, if you know your page size is 4KB, the addresses '3' and '4091' both can be known to have the same protection flags applied (R/W/X) and be the same kind of memory (mmap'd file on disk, shared memory segment, mapped memory from a GPU, etc.) This would allow any tables tracking information like that to only have 4KB granularity and make the tables much smaller. So that sort of trick needs to know the page size too.