Android 15の16 KB PAGE SIZEに対応

2025年11月1日より、Google PlayにアップロードするAndroid 15+デバイス向けアプリは16KB page sizeをサポートする必要があります

原文

アプリが16KB page sizeの要件を満たしているかを確認する方法

方法1: Google Play Consoleチェック方法

.aarをGoogle Play Consoleバックエンドにアップロードした後、ページ下部でチェック結果を確認できます
（現在はアップロードに必須ではなく、早期チェック用と推定されます）

要件を満たしていない場合、This app version only targets 32 bit devices and does not need to support 16 KBというプロンプトが表示されます mcp

方法2: zipalign

公式推奨方法はcmd zipalignを使用して.soのアライメントを確認します
コマンドを使用： zipalign -c -P 16 -v 4 APK_NAME.apk
通過すると検証成功が表示されます mcp

方法3: Android Studioのアナライザー

apkをAndroid Studioのウィンドウにドラッグ&ドロップします
apkを解析してくれます
例えば下図では、x86_64でアライメントされていないことが表示されます：

アライメントされていない例1

方法4: .soファイルが16KBにアライメントされているかチェックするスクリプトを書く

#!/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

スクリプトを使用してビルドキャッシュフォルダ下の.soファイルを各ABIでのパフォーマンスをチェックします

このフォルダ（または他のカスタム.soフォルダ）でこのスクリプトを使用します：

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

例：

armeabi mcp armeabi-v7a mcp x86 mcp

arm64-v8a mcp

x86_64 mcp

方法5: エミュレーターで16KB PAGE SIZEクラッシュを検証

これは追加の保険のようなものです
または最初に簡単なテストをしたい場合
アプリを16KB page sizeエミュレーターに直接インストールできます
Android StudioのAVDで見つけることができるはずです
（ただし、エミュレーターは順次実行されます - 一つの問題を解決してから次が表示されます）

例：16 KB page sizeデバイスでアプリを実行して特定の.soクラッシュ問題に遭遇： mcp

上記の方法で遭遇する可能性のある状況

実験過程で
公式推奨の方法を使用しても
またはapkを手動でASに投げて検証しても
画面では成功と表示されるが
別の方法では異なる結果が表示される可能性があることがわかります
ここに記録しておきます
皆さんの参考になれば：

zipalignコマンドを使用し、-Pを16に設定
検証はすべて成功と表示されますが、実際に他の方法でテストすると成功しない可能性があります
AS内蔵アナライザー
異なるABIで異なるアライメントレベルがあります
ただし、実際にmmkvを16KBサポート版に調整した後
再度アナライザーに投げてもまだmmkvがアライメントされていないと表示
しかし実際に16KBエミュレーターで実行するともうクラッシュしません
またはスクリプトで実行してもアライメント済みと表示されます
スクリプトを使用してELFが2^14 || 2^16にアライメントされているかチェック
異なるABIアーキテクチャで異なるアライメントレベルがある可能性があります
しかし、これは公式の最終要件がどのアライメントかによります
現在主流はx86_64とarm64-v8aのはずです
GPCバックエンドの検証は現在この2つのABIのみを検証しているようです
（将来公式が要求すれば各ABIを最適化することもできますが、そうでなければアップロードのために最適化すべきものを最適化すれば良いです）

後記：遭遇したサードパーティライブラリ内の.soファイルがアライメントされていない例の記録

mmkv

クラッシュログ

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?)

解決方法： 方法1. 公式GitHubで関連設定を変更し、自分で16KB版の.aarをビルドその後、元のimplementの場所を自分でビルドした内容に変更
方法2. 1.3.14バージョンにアップグレード、テスト後正常動作
方法3. 公式がOct 22, 2024に2.0.0を更新して16KBをサポート関連参照を2.0.0以上に更新
公式リリースノート参照
ディスカッションスレッド参照

sqlcipher

クラッシュログ

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)

解決方法：新バージョンに移行
公式GitHubリポジトリ：sqlcipher-android
移行ドキュメント：こちらをクリック

xCrash

この問題で遭遇したログ

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?)

実テスト解決方法、自分でaarをビルド
- プロジェクトをクローン：Githubリポジトリ
- プロジェクト内のCMakeList.txtに2^14 || 2^16 MaxSizeの関連フィールドを追加、例：
- NDK関連環境をインストール、元のプロジェクトは21.3.6528147を使用、ローカルインストール後にbuild failedが発生したので、近いバージョンを試す
NDKインストール方法
- インストール済みNDKをリスト表示
```
ls -la ~/Library/Android/sdk/ndk/
```
- インストール済みNDKターゲットバージョンが正常にビルドできるかチェック
```
~/Library/Android/sdk/ndk/[your_version]/ndk-build --version
```
- ダウンロード可能バージョンを表示
```
~/Library/Android/sdk/tools/bin/sdkmanager --list | grep ndk
```
- 指定NDKをインストール
```
~/Library/Android/sdk/tools/bin/sdkmanager --install "ndk;25.2.9519653"
```
JDKバージョンが新しすぎてダウンロードできない可能性があります、環境のJDKを8に戻してダウンロード
- xCrashの.aarビルドを開始、以下のコマンドは主にclean > build > checkstyleを実行、自分で組み合わせ可能、主にbuildを実行ただし調整過程でbuild failedに遭遇した場合、これを使ってチェックできます
```
./gradlew clean :xcrash_lib:build -x checkstyle --rerun-tasks
```
遭遇する可能性のある問題
- ./gradlew :xcrash_lib:build使用時に遭遇：checkstyleを入力しなくてもcheckstyleが実行され、AnrHandler.javaのjava ifにスペースが不足していることが検出されましたが、元のクローンがそうだったので、後でスペースを追加すれば解決
```
> Task :xcrash_lib:checkstyle FAILED
[ant:checkstyle] [ERROR] ../xcrash/AnrHandler.java:144:9: 'if' is not followed by whitespace. [WhitespaceAfter]
```
.aarで元のxCrashを置き換え、置き換え後書いた./agliment.shでチェックするとアライメント済みと表示 しかし実際に16KBデバイスではまだエラーが報告
回避方法
- 16 KB pages sizeデバイスで実行できるかテストしたいが、Google Play Consoleにはアップロードしないので、build configをintlに切り替えてテスト可能

Umeng

libtnet.soクラッシュ問題に遭遇
ただしGPCにもアップロードしないので、回避方法でテスト可能、intlに切り替えてビルド

AMap（高德地図）

implementation方式でamapをインポート
その後16KBチェック../str/c/stripChannelDebugDebugSymbols/out/libを実行
アライメントされていないことがわかります
公式サイトからダウンロードした最新版SDKを試用つまり.jarを使用するように変更正常にビルドでき、16 KB page sizeデバイスで実行可能
- ../str/c/stripChannelDebugDebugSymbols/out/lib下の.soを再チェックすると消失しかし公式の.soを直接チェックするとまだアライメントされていません（これはダウンロードした.zipを解凍後）または公式の.aarを直接使用して中の.soを抽出してもアライメントされていません
現在mvnの最新amapバージョンをチェックしても、公式サイトの最新バージョンはまだありません
オープンソースのソースコードも見つかりません
16 KB page sizeで遭遇
後に、これは自分では解決できないことがわかりました。公式がソースコードをオープンソース化していないため、自分でビルドして回避策を作ることができませんそのため公式のアップデートを待つしかありません