Androidの16KBメモリページサイズ対応とは？Google Play要件・確認方法・エラー対処を解説
初回掲載日:
最終更新日:
Androidの16KBメモリページサイズ対応は、すべてのアプリに同じ大規模修正を求める話ではありません。まずAPKやAABにnative library（共有ライブラリ）が含まれているかを確認し、含まれている場合だけ、.soの配置・ELF alignment・コードの4KB前提を順番に調べます。
先に結論：Android 15（API 35）以降を対象にするGoogle Playアプリは、64-bit端末向けに16KBメモリページサイズをサポートする必要があります。Android Developers公式では、2027年2月1日以降、16KBをサポートしないアプリ更新はGoogle Playで公開できないと案内されています。公開時点の要件は変わる可能性があるため、提出前に公式ページを再確認してください。
この記事で分かること
- 4KBと16KBのメモリページサイズの違い
- 自分のアプリが16KB対応の確認対象かどうか
- NDKを直接使っていなくてもSDKやAAR経由で.soが入る理由
- APK Analyzer、ELF、zip alignmentで非対応箇所を探す方法
- 自前native code、外部SDK、ビルド環境ごとの修正方針
- 16KB環境でのテストとGoogle Play警告後の確認順
16KBメモリページサイズとは
メモリページは、OSが仮想メモリを管理するときの基本単位です。従来のAndroidでは4KBページが中心でしたが、Android 15からは16KBページサイズで構成された端末をAOSPがサポートしています。ページが大きくなると、OSやアプリのメモリ管理の前提が変わるため、native libraryや4KBを固定値として扱うコードは影響を受ける可能性があります。
| 項目 | 4KB | 16KB |
|---|---|---|
| 1ページの大きさ | 4,096 bytes | 16,384 bytes |
| Androidでの位置づけ | 従来から広く使われてきた | Android 15以降の対応端末で利用される |
| 影響を受けやすいもの | native library、ELF/zip配置、ページサイズを固定したnative code | |
| 対応の考え方 | アプリ内の.soとビルド・実行時の4KB前提を確認する | |
16KB対応は、JavaやKotlinのソースを機械的に書き換える作業ではありません。native codeを使っていないアプリなら対応済みの場合もありますが、外部SDKやAARにnative libraryが含まれていないかを先に確認します。
Google Playの現行要件
Android Developers公式では、Android 15（API level 35）以上を対象とするアプリは、Google Play上の64-bit端末で16KBページサイズをサポートする必要があると説明されています。2027年2月1日以降は、16KBをサポートしないアプリ更新を公開できないという期限も掲載されています。
ここで注意したいのは、期限だけを見て「すべてのアプリが今すぐnative code修正必須」と判断しないことです。対象API、64-bit向けの配布物、native libraryの有無、SDKの対応状況を分けて確認します。過去に案内された別の期限を現在の要件として転記せず、提出時点の公式情報を基準にしてください。
対応が必要かを判断する
| アプリの状態 | まず行うこと | 判断の目安 |
|---|---|---|
| Java / Kotlinだけで、全SDKにもnative codeがない | APK Analyzerでlibフォルダを確認 | 公式上は16KB対応済みと考えられるが、16KB環境で動作確認する |
| 自分でC/C++やNDKを使っている | .soのELF alignmentとコードの固定値を確認 | 再ビルドとnative code修正が必要になる可能性がある |
| NDKは使っていないがSDK/AARを多数利用 | APKのlib配下を確認し、提供元の対応版を調べる | 依存SDKの更新で解決する場合がある |
| Play Consoleに警告がある | 警告対象のAAB/APKと.soを特定 | 警告を消すことではなく、修正後の配布物を再検証する |
「NDKを直接使っていないから必ず無関係」でも、「警告が出たからアプリ全体を作り直す」でもありません。APKに実際にnative libraryが入っているかを見てから、原因を分けます。
.soファイルとは何か
.soはAndroidで使われる共有ネイティブライブラリです。C/C++で自作したコードだけでなく、広告、ゲームエンジン、画像処理、音声、暗号、データベースなどのSDKがAARや依存関係を通じて含めることがあります。
そのため、KotlinやJavaだけでアプリを書いていても、完成したAPKの lib/arm64-v8a/ や lib/x86_64/ に.soがあれば確認対象です。依存関係の名前だけでは判断せず、最終成果物を確認します。
確認方法1：Android StudioのAPK Analyzer
- Android Studioでプロジェクトを開く。
- BuildメニューからAnalyze APK...を選ぶ。
- 確認したいAPKを選択する。
- ツリーの
libフォルダを開き、共有ライブラリの有無を見る。 - Alignment列に警告が出ていないか確認する。
libフォルダや.soがなければ、少なくともそのAPKにはnative libraryが含まれていません。存在する場合は、どのABI・どのファイルが警告対象かを記録します。Android Studioは、事前ビルド済みライブラリやAPKのalignment問題を警告できるため、最初の切り分けに向いています。
確認方法2：APKのELF alignmentを調べる
公式ページでは、Linux/macOS向けの check_elf_alignment.sh でAPK内の共有ライブラリを確認する方法と、コマンドラインツールでELFのLOAD segmentを見る方法が案内されています。スクリプトを使う場合は、公式ページから作業時点の最新版を取得してください。
Windows PowerShellで個別の.soを確認する場合の例は次のとおりです。SDKとNDKのパス、NDK_VERSION、ファイル名は自分の環境へ置き換えます。
& "$env:ANDROID_SDK_ROOT\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe" `
-p ".\lib\arm64-v8a\sample.so" | Select-String -Pattern "LOAD"LOAD行のalignmentが16KBに対応する 2**14 以上かを確認します。2**13、2**12など小さい値が残っている場合は、ライブラリの更新・再コンパイル・パッケージ方法を見直します。
確認方法3：zip alignmentとAABを確認する
共有ライブラリのELF alignmentだけでなく、APKのzip配置やAABから生成されるAPKの配置も確認します。公式ページでは、Android SDK Build-Tools 35.0.0以上のzipalignを使う方法が案内されています。
zipalign -c -P 16 -v 4 app-release.apk最後にVerification successfulが表示されるかを確認します。AABの設定を見る場合は、bundletoolの出力にPAGE_ALIGNMENT_16Kがあるかを確認します。
bundletool dump config --bundle=app-release.aab | grep alignmentWindowsでは環境に合わせてfindstrなどへ置き換えられますが、重要なのはコマンドの名前ではなく、AABから生成される配布物が16KB配置を要求しているかを確認することです。
原因別の直し方
| 原因 | 対処 | 再確認 |
|---|---|---|
| 古い外部SDKの.so | SDK提供元の16KB対応版へ更新 | 更新後APKのlibとalignmentを再確認 |
| 自前NDKの.so | NDK・リンカー設定を更新して再ビルド | ELFのLOAD alignmentと実機動作を確認 |
| NDK r27以下でビルド | 可能ならNDK r28以上へ更新。難しい場合は公式指定のリンカーフラグを検討 | 生成された各ABIの.soを再検証 |
| AGPが古く、共有ライブラリが未圧縮 | AGP 8.5.1以上への更新を優先 | AABのzip alignmentとPlay向けAPKを確認 |
| 4KB固定のnative code | PAGE_SIZEや4096前提を見直し、実行時ページサイズを取得する | 16KB環境で該当処理を実行 |
| RELROやcustom allocatorの問題 | 公式ガイドのRELRO・メモリアロケータ手順を確認 | 起動、メモリ使用量、該当機能をテスト |
AGP 8.5.1以上、NDK r28以上、16KB対応済みのprebuilt dependencyを使うと、公式ガイド上は初期状態で対応しやすくなります。ただし、既存の自前コードや外部SDKが対応済みとは限らないため、成果物確認を省略しません。
自前NDKコードの注意点
NDKを更新してELFをそろえても、コードが4KBを前提にしていれば実行時問題が残ることがあります。公式ガイドでは、PAGE_SIZEや4096を固定値として使う処理を見直し、getpagesize()やsysconf(_SC_PAGESIZE)など、実際のページサイズを取得する方法を検討するよう説明しています。
mmap()などページ境界を要求するAPI、custom allocator、独自のメモリプールを使っている場合は、単なるパッケージ再配置では終わりません。該当するnative処理を16KB環境で実行して、クラッシュやメモリ使用量の変化を確認します。
外部SDKが原因の場合
自分のソースにC/C++がなくても、AARやSDKに.soが含まれていることがあります。次の順で切り分けると、依存関係をむやみに削除せずに済みます。
- APK Analyzerで警告対象の.so名とABIを記録する。
- Gradleの依存関係から、その.soを含むSDK候補を探す。
- SDK提供元のリリースノートや対応表で16KB対応版を確認する。
- 依存SDKだけを更新して再ビルドする。
- 同じAPK Analyzer、alignment確認、16KB環境テストを再実行する。
SDK更新で直らない場合は、提供元へ対応状況を確認します。警告を隠すだけの設定変更や、問題の.soを手作業で置き換える方法は、ABIや署名、実行時依存関係を壊す可能性があります。
16KB環境でテストする
公式ガイドでは、Android 15以上の16KB対応エミュレーター、Cuttlefish、対応端末の開発者オプションなどを利用できます。テスト環境で次のコマンドを実行し、ページサイズが16384であることを確認します。
adb shell getconf PAGE_SIZE続いて、アプリの起動だけでなく、native libraryを使う画面・画像処理・音声・カメラ・データベース・バックグラウンド処理など、アプリ固有の処理を動かします。端末が16KB環境だから自動的にすべての問題が出るとは限らないため、ユーザーが使う経路を優先します。
Google Play Consoleで警告されたときの確認順
- 警告対象のversionとAAB/APKを特定する。
- 対象APIがAndroid 15（API 35）以上かを確認する。
- APK Analyzerで
libと.soを確認する。 - 自前native codeか外部SDKかを切り分ける。
- ELF alignment、zip alignment、AAB設定を確認する。
- AGP、NDK、依存SDKを更新し、必要ならコードの4KB前提を修正する。
- 新しいAABを作成し、同じ検査と16KB環境テストを行う。
Google Playの警告文だけで原因ライブラリを断定せず、最終成果物のファイル名と依存関係を照合します。API 36対応のような別の公開要件も同時に確認する場合は、Google Play API 36の記事で要件を分けて確認してください。
リリース前チェックリスト
- 対象APIとGoogle Playの現行要件を公式ページで再確認した
- APK Analyzerでlibと.soの有無を確認した
- 自前native codeと外部SDKを切り分けた
- AGP、NDK、依存SDKを対応版へ更新した
- ELF LOAD segmentが16KBに対応している
- AABのalignment設定とAPKのzipalignを確認した
- PAGE_SIZEが16384の環境で起動・主要機能をテストした
- 4KB固定のPAGE_SIZE、4096、mmap周辺処理を確認した
- 修正後のAABをGoogle Play Consoleへ再アップロードして警告を確認した
関連する公開設定との違い
16KB page size対応は、Google PlayのversionCodeやアプリ署名とは別の、native libraryと実行環境の互換性に関する確認です。アプリ更新の番号管理はversionCode / versionNameの記事、バックグラウンド処理の制限はForeground Serviceの記事で扱っています。互いに関係する場合でも、要件を混ぜずに個別に確認してください。
FAQ
Q. Kotlinだけのアプリでも16KB対応が必要ですか？
アプリ本体とすべてのライブラリ・SDKがJava/Kotlinだけなら、公式ページでは16KB対応済みと説明されています。ただし、外部SDKにnative libraryが含まれる可能性があるため、APK Analyzerで確認し、16KB環境でテストしてください。
Q. NDKを使っていないのに警告が出るのはなぜですか？
依存SDKやAAR、アプリビルダーがnative libraryを含めている可能性があります。完成したAPKのlibフォルダから.soを確認してください。
Q. .soがあれば必ずコード修正が必要ですか？
必ずではありません。対応済みのSDKや正しく再ビルドされたライブラリなら、依存更新や設定確認だけで済む場合があります。alignmentと16KB環境での動作を確認して判断します。
Q. AGP 8.5.1とNDK r28は必須ですか？
公式ガイドが示す対応しやすい構成です。ただし、プロジェクトや依存SDKによって移行方法は異なります。古い構成を使う場合は、公式の代替手順と成果物検証を行ってください。
Q. 4KB端末で動けば問題ありませんか？
十分ではありません。16KB環境を用意し、adb shell getconf PAGE_SIZEで16384を確認したうえで、native codeを使う機能をテストします。
まとめ
16KBメモリページサイズ対応は、Android 15以降の16KB端末でアプリを動かすための互換性確認です。最初にAPK/AABに.soがあるかを調べ、あればSDK・AAR・自前NDKのどこから来たかを切り分けます。
その後、ELF alignment、zip alignment、AGP・NDK・依存SDK、4KB固定のnative codeを確認し、16384の16KB環境で実際にテストします。Google Playの期限だけを追うのではなく、最終配布物と実行環境の両方を確認することが安全な対応です。