Adapted for Android 15 with 16 KB PAGE SIZE

Starting November 1, 2025, apps targeting Android 15+ devices uploaded to Google Play must support 16KB page size

Original Article

How to verify if your app meets the 16KB page size requirements

After uploading the .aar to the Google Play Console backend, you can see the check results at the bottom of the page
(Currently not mandatory for publishing, estimated to be for early checking)

You can see that if it doesn't meet the requirements, there will be a prompt This app version only targets 32 bit devices and does not need to support 16 KB

The officially recommended method uses the cmd zipalign to verify .so alignment
Use command: zipalign -c -P 16 -v 4 APK_NAME.apk
If it passes, it will show verification success

---

Drag your apk into the Android Studio window
It will help you analyze your apk
For example, in the image below, x86_64 shows as unaligned:

---

#!/bin/bash

# usage: alignment.sh path to search for *.so files

dir="$1"

RED="\e[31m"
GREEN="\e[32m"
ENDCOLOR="\e[0m"

matches="$(find $dir -name "*.so" -type f)"
IFS=$'\n'
for match in $matches; do
  res="$(objdump -p ${match} | grep LOAD | awk '{ print $NF }' | head -1)"
  if [[ $res =~ "2**14" ]] || [[ $res =~ "2**16" ]]; then
    echo -e "${match}: ${GREEN}ALIGNED${ENDCOLOR} ($res)"
  else
    echo -e "${match}: ${RED}UNALIGNED${ENDCOLOR} ($res)"
  fi
done

Use the script to check .so files under the build cache folder for performance under various ABIs

Use this script in this folder (or other custom .so folders):

..//Your Project Name/Your Project modele/build/intermediates/stripped_native_libs/channelDebug/stripChannelDebugDebugSymbols/out/lib

armeabi armeabi-v7a x86

arm64-v8a

x86_64

---

This is like adding an extra layer of insurance
Or when you want to do simple testing initially
You can directly install the app on a 16KB page size emulator
You should be able to find it in AVD in Android Studio
(However, the emulator executes sequentially - only after solving one issue will the next appear)

For example: Running app on 16 KB page size devices encountering a certain .so crash issue:

---

During the experimental process
You'll find that even using the officially recommended methods
Or manually throwing the apk into AS for verification
There's still a chance of encountering situations where the screen shows success
But using another method shows different results
I'll record this here
Everyone can refer to it:

1. Using zipalign command with -P set to 16
   Verification all shows success, but actual testing with other methods might not succeed
   

2. AS built-in analyzer
   Under different ABIs, there are different alignment levels
   However, after actually modifying mmkv to adjust to a version supporting 16KB
   Throwing it into the analyzer again still shows mmkv as unaligned
   But actually running on 16KB emulator no longer crashes
   Or using script to run also shows as aligned
   

3. Using script to check if ELF is aligned to 2^14 || 2^16
   Under different ABI architectures, there might be different alignment levels
   But this depends on what the official final requirements are for alignment
   Because currently the mainstream should be x86_64 and arm64-v8a
   GCP backend verification currently seems to only verify these two ABIs
   (You can also optimize for each ABI if the official requires it in the future, otherwise just optimize what needs to be optimized for publishing)
   

Postscript: Recording examples of unaligned .so files in third-party libraries I've encountered

mmkv

• Crash log

Process: com.xxx.xxxxxxxxx, PID: 5910
java.lang.UnsatisfiedLinkError: dlopen failed: empty/missing DT_HASH/DT_GNU_HASH in "/data/app/~~GDguKzQkEWWU7nKgxukJ3g==/com.xxx.xxxxxxxx-LLLvOX6N3NINoK5qFkhyxQ==/base.apk!/lib/arm64-v8a/libmmkv.so" (new hash type from the future?)

• Solution: Method 1. Go to the official GitHub, modify related settings and build a 16KB version .aar yourself Then change the original implement location to your own built content
  Method 2. Upgrade to version 1.3.14, tested to work normally
  Method 3. Official Oct 22, 2024 updated 2.0.0 to support 16KB Update related references to 2.0.0 or above
  Reference official release note

• Reference discussion thread

sqlcipher

• Crash log

pid: 8796, tid: 8891, name: pool 1  >>> com.xxx.xxxxxxxxxx <<<
2025-05-21 14:29:47.380  8901-8901  DEBUG                   pid-8901                             A        #02 pc 0000000000006700  /data/app/~~p4bSI2XwdSmTfm3vZluhdw==/com.sand.airdroidkidp-9wKFuA4x7Jclg5hVTLRBSA==/base.apk!libtnet-3.1.14.so (offset 0x5504000) (BuildId: 2510ff56a9673370b9d664c21a3dcb04a541d939)
2025-05-21 14:29:47.380  8901-8901  DEBUG                   pid-8901                             A        #03 pc 00000000000060c4  /data/app/~~p4bSI2XwdSmTfm3vZluhdw==/com.sand.airdroidkidp-9wKFuA4x7Jclg5hVTLRBSA==/base.apk!libtnet-3.1.14.so (offset 0x5504000) (JNI_OnLoad+76) (BuildId: 2510ff56a9673370b9d664c21a3dcb04a541d939)

• Solution: Migrate to new version
  Official GitHub repo: sqlcipher-android
  Migration documentation: Click here
  

xCrash

• Log encountered with this issue

  2025-06-03 11:14:11.095  6505-6505  xcrash com.xxx.xxxxxx E  NativeHandler System.loadLibrary failed (Ask Gemini)
  java.lang.UnsatisfiedLinkError: dlopen failed: empty/missing DT_HASH/DT_GNU_HASH in "/data/app/~~NKxgZmiW0fnAnkqxbM6pmg==/com.xxxxxx.xxxxx-TBH_eXBREJRiwzaa0oJFsQ==/base.apk!/lib/arm64-v8a/libxcrash.so" (new hash type from the future?)
  

• Tested solution, build aar yourself

  • Clone project: Github repo

  • Add 2^14 || 2^16 MaxSize related fields to CMakeList.txt in the project, such as:

  • Install NDK related environment, the original project uses 21.3.6528147, I got build failed after local installation, so try a similar version

• NDK installation method

  • List installed NDKs

  ls -la ~/Library/Android/sdk/ndk/
  

  • Check if installed NDK target version can build normally

  ~/Library/Android/sdk/ndk/[your_version]/ndk-build --version
  

  • View downloadable versions

  ~/Library/Android/sdk/tools/bin/sdkmanager --list | grep ndk
  

  • Install specified NDK

  ~/Library/Android/sdk/tools/bin/sdkmanager --install "ndk;25.2.9519653"
  

  It's possible that the JDK version is too new to download, switch JDK back to 8 to download

  • Start building xCrash .aar, the following command mainly executes clean > build > checkstyle, you can combine them yourself, mainly executing build But during the tuning process, if you encounter build failed, you can use this to check

  ./gradlew clean :xcrash_lib:build -x checkstyle --rerun-tasks
  

• Possible issues encountered

  • When using ./gradlew :xcrash_lib:build, encountered: even without typing checkstyle, it still ran checkstyle, which detected that AnrHandler.java was missing a space in java if, but the original clone was like this, later adding the space solved it

  > Task :xcrash_lib:checkstyle FAILED
  [ant:checkstyle] [ERROR] ../xcrash/AnrHandler.java:144:9: 'if' is not followed by whitespace. [WhitespaceAfter]
  

• Replace the original xCrash with the .aar, after replacement although using the written ./agliment.sh check shows already aligned But actually still reports errors on 16KB devices

• Workaround method

  • Because you want to test if it can run on 16 KB pages size devices, but it won't be uploaded to Google Play Console, so you can switch the build config to intl for testing

Umeng

• Encountered libtnet.so crash issue
• But it also won't be uploaded to GPC, so you can also use Workaround for testing, switch to intl to build

AMap aka Gaode Maps

• Using implementation method to import amap
  Then do 16KB check ../str/c/stripChannelDebugDebugSymbols/out/lib

  Will find unaligned

• Try using the latest SDK downloaded from the official website Which means changing to use .jar Successfully can build and run on 16 KB page size devices

  • Re-check ../str/c/stripChannelDebugDebugSymbols/out/lib for .so files and found they disappeared But directly checking the official .so is still unaligned (This is after downloading and unzipping the .zip) Or directly using the official .aar to extract the packaged .so is also unaligned

• Currently checking the latest amap version on mvn, there's no latest version from the official website yet

• Also haven't found open source code

• On 16 KB page size will encounter

• Later found this cannot be solved by myself, because the official doesn't open source code, cannot create workaround through self-building So can only wait for official updates