クイックアンサー
Google Play は Android 15（API レベル 35）以上をターゲットにするアプリに、64ビット端末での 16 KB メモリページサイズへの対応を求めており、2027年2月1日からは対応していない更新をリリースできなくなります。ライブラリと SDK を含めて Java または Kotlin だけで書かれたアプリは、すでに要件を満たしています。ネイティブの .so ライブラリを含むアプリは、そのすべてをビルドし直すか差し替えるまで通りません。できれば Android Gradle Plugin 8.5.1+ と NDK r28+ を使い、ビルドが別々の2つのチェックを両方通ることが必要です。すべての ELF LOAD セグメントが最低 2**14 にアライメントされていること、そして App Bundle が PAGE_ALIGNMENT_16K を報告することです。フレームワークを上げたことは証明になりません。証明になるのは成果物です。この警告を消す作業で進行中のクローズドテスト（closed testing）が止まってしまったなら、ビルドし直している間のテスター側は PrimeTestLab が回し続けます。
警告は短く、せいぜいファイル名をひとつ告げるだけで、しかもビルドが終わったと思った後にやってきます。だからこそ、いつも同じ3つの間違った道に入ってしまいます。すでに変わった期限を信じる、フレームワークを上げただけで終わったと思い込む、ローカルの APK をひとつ確認しただけで Google が実際にビルドに使うバンドルを見ない、の3つです。この記事は問題が実際に解けていく順番、つまり特定し、出どころを突き止め、直し、証明する、の順に並べています。内容はすべて2026年8月5日時点のもので、Google のページサイズガイドが最終更新されたその日に照合しました。根拠が公式のリリースノートではなくメンテナーの Issue トラッカーである場合は、事実に丸めずカードにそのまま明記しています。
アライメントラボ
このエラーひとつのために作った道具が12個あります。アカウントもアップロードもネットワーク通信も不要です。すべての道具が、入力していただいた値をもとにブラウザの中だけで動きます。
目次
3ステップで解決する
このエラーの本当の解決策は、いつも同じ3つの動作を同じ順番で踏むことです。アライメントされていないネイティブライブラリを特定し、そのファイルを含む依存関係を更新し、アップロードしようとしている成果物を確認する。いきなり2番目に飛ぶからこそ、多くの開発者がフレームワークを上げてビルドし直したのに、警告がそのまま戻ってくるのを目にすることになります。
要件そのものは範囲が狭いものです。Google のページサイズガイドは、Android 15（API レベル 35）以上をターゲットにするアプリは64ビット端末で 16 KB メモリページサイズに対応する必要があり、2027年2月1日からは対応していない更新をリリースできなくなると述べています。対象はネイティブコードだけです。アプリとその中のすべてのライブラリと SDK が純粋な Java または Kotlin であれば、すでに 16 KB 端末に対応していると Google が明記しています。問題は、この警告を見た開発者の多くが自分はその区分に入ると信じていて、実際には入っていないことです。
問題の .so を特定する
Android Studio の Build > Analyze APK... でリリース用 APK を開き、lib/arm64-v8a と lib/x86_64 を展開して Alignment 列を見てください。指摘されたファイル名をすべて書き留めます。そのファイル名が、手元にある唯一の信頼できる検索キーです。
そのファイルを持つ側を更新する
自分でコンパイルしたバイナリはツールチェーンで直ります。AGP 8.5.1 以降と NDK r28 以降で十分です。一方、プラグイン、SDK、エンジン、AAR の中に入ってきたバイナリは、それをビルドした側にしか直せません。ですからやることは、そのパッケージを上げるか、差し替えるか、ビルドし直した成果物を依頼することです。
フレームワーク別の最短ルートを見るアップグレードではなく成果物を確認する
独立した2つのチェックを両方通す必要があります。すべての ELF LOAD セグメントが 2**14 以上にアライメントされていること、そして bundletool がリリース用バンドルについて PAGE_ALIGNMENT_16K を報告することです。片方が通っても、もう片方については何も証明されません。
判断のすべてを1画面に
依存関係のバージョンをひとつでも変える前に、この流れをたどってください。2分ほどで済みますが、正しいものを直すか、そもそも原因ではなかったパッケージを11個も上げるかの分かれ目がここにあります。
リリース用 APK に .so ファイルの入った lib フォルダはありますか。
すでに要件を満たしています
その APK にネイティブコードはありません。Google は、ライブラリと SDK を含めて Java または Kotlin だけのアプリはすでに 16 KB 端末に対応していると述べています。それでも一度テストしてみる価値はありますし、アップロードしたものと同じビルドを見たかを確認しておく価値もあります。
APK Analyzer または check_elf_alignment.sh は、アライメントされていないライブラリを挙げていますか。
出どころを突き止めて上げる
その正確なファイル名を提供しているフレームワーク、プラグイン、SDK、エンジンを探し、そのパッケージを更新してください。自分の NDK が他人のビルド済みバイナリを書き換えることはできません。
リリース用バンドルに対して bundletool dump config は何を報告しますか。
PAGE_ALIGNMENT_4K
ライブラリは問題なく、まずいのはパッケージングです。AGP 8.5.1 以降に上げてビルドし直すか、上げられないならレガシーパッケージングの回避策を適用してください。
PAGE_ALIGNMENT_16K
パッケージングは正しいです。次は Play が生成した APK を実際の 16 KB 環境でテストし、ページサイズが固定だと前提している実行時のコードがないか点検してください。
一行でまとめた落とし穴
アライメントのチェックをすべて通ったローカルの APK は、アップロードしたバンドルが正しいことを証明しません。Google は、Android Gradle Plugin 8.3 から 8.5 が、手元の APK は完璧に見えるのに Play がそのバンドルからビルドした APK は ZIP アライメントされていない、というバンドルを作りうると特に警告しています。このずれが、「うまくいったはず」の修正の後も警告が生き残る最も多い理由です。
Play Console の警告が実際に意味すること
Google が文書に書いた結果は正確です。2027年2月1日から、Android 15（API レベル 35）以上をターゲットにしながら 16 KB に対応していない更新をリリースできなくなります。更新に対するリリースの停止であって、すでに公開されたアプリがその日にストアから消えるという話ではありません。それまでの間、多くの開発者が目にするのはアップロードを拒む却下ではなく互換性の警告です。
言い回しが重要なのは、この話のパニック版のほうが正確な版より速く広まるからです。Google が実際に表示している文言を読めば、対象範囲は狭く、扱える大きさになります。
App must support 16 KB memory page sizes
Google がページサイズのガイドに掲載した Play Console のスクリーンショットを再現しました。ラベルはそのスクリーンショットのとおり英語のままにしています。実際の Console では日本語で表示されることがあり、画面構成や表示されるボタンもアカウントによって異なる場合があります。
このカードの読み方でよく2つ間違いが起きます。ひとつめ、「Action by Feb 1, 2027」は削除までのカウントダウンではありません。同じページの Google の本文も、結果をそうした更新をリリースできないことだと説明しています。ふたつめ、Extension granted という文字列は Google のスクリーンショットに見えますが、それがいまご自身に延長申請の導線が開いている根拠にはなりません。ご自身の Play Console の中でその選択肢が実際に見えるときだけ、延長があると判断してください。
読んだ期限はどちらでしたか
3つの日付が出回っていて、生きているのはひとつだけです。目にしたほうを選んでいただくと、2026年8月5日に最終更新された Google の現行ドキュメントと照らして状態をお伝えします。
道具 01
期限の判定
Google はこの期限を1回以上動かしています。2027年2月1日を前提にリリース計画を立てる前に、ご自身でページサイズのガイドを開き、末尾の「Last updated」の表示を確認してください。この習慣ひとつが、この記事を含めどんな記事に印刷された日付よりも価値があります。
16 KB の要件は自分のアプリにも当てはまるか
これを決めるのはフレームワークではなく、生成された APK の中身です。lib の下に .so ファイルがあれば、C++ のファイルを一度も開いたことがなくても対象で、ひとつもなければすでに 16 KB 端末に対応しているというのが Google 自身のガイダンスです。
純粋な Java または Kotlin のアプリ
ここでの Google の記述は明快です。アプリとそのすべてのライブラリと SDK が Java または Kotlin だけを使っていれば、そのアプリはすでに 16 KB 端末に対応しています。それでも想定外の不具合を見つけるために 16 KB 環境でのテストを推奨しており、コストはエミュレータ1回分です。
落とし穴は「そのすべてのライブラリと SDK」という部分です。データベース、分析、クラッシュレポート、メディア、地図、機械学習、セキュリティの依存関係ひとつで、ソースには Kotlin しかないプロジェクトにネイティブバイナリが入ってきます。「C++ は書いていない」は証拠になりません。証拠は lib フォルダです。
Flutter、React Native、Unity、Kivy、ノーコードビルダー
これらのスタックは設計上ネイティブのランタイム、エンジンのバイナリ、プラグインのライブラリを同梱するので、ほぼ必ず対象になります。Google は、作者が C や C++ をまったく書いていなくてもアプリが影響を受ける経路として、ネイティブライブラリを使うサードパーティのアプリビルダーを明示的に挙げています。変わるのはネイティブコードがあるかどうかではなく、失敗している部分をどのパッケージが持ち込んだかです。だからこそファイル名の出どころを突き止めることが、どんなアップグレードよりも先に来ます。
確認の手順、正確に
リリース用 APK を開き、lib を展開して中の ABI フォルダを見てください。通常は arm64-v8a と x86_64 です。共有オブジェクトのファイルがひとつでもあれば、アプリはネイティブコードを使っています。.so ファイルも lib フォルダもなければ、この APK はネイティブコードをまったく使っていません。アナライザの Alignment 列はアライメントに問題のあるファイルに警告を表示するので、「何かがおかしい」からファイル名まで最短でたどり着けます。
道具 02
対象かどうかの診断
01 いまアプリは何をターゲットにしていますか。
02 APK Analyzer でリリース用 APK を開いてください。lib フォルダはありますか。
03 アプリを最もよく表しているのはどれですか。
04 リリース用バンドルに bundletool dump config を実行しましたか。
4 KB のバイナリが 16 KB 端末で失敗する理由
メモリページとは、カーネルが一度にマップする最小のブロックです。Android は長く 4 KB ページを使ってきましたが、Android 15 から 16 KB ページで構成された端末をサポートするようになりました。ネイティブライブラリは自分のセグメントがどのアライメントを前提にリンクされたかを記録しており、その値が端末のページサイズより小さいと、ローダーはセグメントをページ境界に置けません。
仕組みはこれだけで、繰り返し目にするあの数字もこれで説明がつきます。アライメントは2の累乗で表され、2**12 は4096バイト、2**14 は16384バイトです。Google のルールは、ネイティブライブラリのすべての LOAD セグメントが 2**14 以上にアライメントされていることです。2**14 でビルドされたライブラリは 4 KB 端末でも 16 KB 端末でも動きます。16384 は 4096 のきれいな倍数だからです。逆に 2**12 でビルドされたライブラリは、小さいページサイズでしか動きません。この非対称性があるので、解決策はいつも「アライメントを上げる」であって「端末を判別する」ではありません。
道具 03
ページの可視化
ライブラリが報告しているアライメント値を選ぶと、16 KB ページを使う端末でそのセグメントが開始できる位置を表示します。
合格
ライブラリの外側には、まったく別の制約がもうひとつあります。APK の中に圧縮せず格納されたネイティブライブラリは、ZIP アーカイブの中でも 16 KB の境界に置かれる必要があります。これはパッケージングの性質で、zipalign で確認し、ビルドプラグインが設定します。中のライブラリがすべて完璧にアライメントされていても、こちらが崩れることがあります。この2つの考えを切り分けて覚えることが、このセクションから持ち帰れる最も役に立つことです。
数字の読み方
llvm-objdump の出力に 2**14 が見えれば合格です。2**13 や 2**12 は不合格です。部分点も「ほぼ大丈夫」もありません。ひとつの ABI のひとつのライブラリに、アライメントされていない LOAD セグメントがひとつあるだけで、アカウントに警告が残ります。
フレームワーク別の最短ルート
フレームワークの準備状況とアプリの要件充足は別の話です。React Native 0.77 と Unity のサポートバージョンは、実際にドキュメント化された基準です。Flutter には検証可能な普遍的最小バージョンがありません。いずれの場合も、アップグレードが直すのはフレームワーク自身のバイナリであって、サードパーティのプラグインは元のまま要件を満たさない状態で残ります。
道具 04
フレームワーク検索
これをしてもまだ失敗しうること
基準を1つの表に
| フレームワーク | ドキュメント上の基準 | 最短の行動 | 確度 |
|---|---|---|---|
| Flutter | 検証済みの普遍的最小バージョンなし、文書化された備えの節目は 3.38（既定 NDK r28） | 現在の安定版、ネイティブプラグイン更新、clean、再ビルド、全ライブラリ確認 | 一部確認 |
| React Native | 0.77 | サポートされた移行手順、その後ネイティブモジュールとベンダー SDK を更新 | 確認済み |
| Unity 6.1 系 | 6000.1 以降 | エディタを上げ、パッケージとプラグインを更新し、再ビルド | 確認済み |
| Unity 6 LTS | 6000.0.38f1 以降 | 上と同じ | 確認済み |
| Unity 2022 LTS | 2022.3.56f1 以降 | 上と同じ | 確認済み |
| Unity 2021 | 2021.3.48f1 以降、拡張 LTS の対象であることが必要 | 対象なら上げる、そうでなければサポート対象のエディタへ移行 | 確認済み |
| Unity Burst | 1.8.21 以降 | lib_burst_generated.so が挙がったら Burst を上げる |
確認済み |
| ネイティブ Android | NDK r28+ と AGP 8.5.1+ | 自分のコードを再コンパイル、ビルド済み依存関係をすべて更新 | 確認済み |
| 古い NDK に固定 | r27 以前 + リンカオプション2つ | max-page-size と common-page-size を追加し、全ライブラリを再ビルド |
動くが推奨ではない |
| Kivy または Python ビルダー | 普遍的に確認されたバージョンなし | ビルダーとレシピを更新し、正確なファイル名を上流に伝える | ベンダー次第 |
| ノーコードビルダー | 普遍的に確認されたバージョンなし | ベンダーの要件充足ビルドスタックで再生成し、ファイル名を伝える | ベンダー次第 |
確度ラベルはこのページのどこでも同じ意味です。確認済みは、現行の一次情報が直接そう述べている場合。一部確認は、信頼できる情報が中心の主張は裏づけるものの、実装の細部までは裏づけない場合。報告ありは、根拠が公式のリリースノートではなくメンテナーの Issue トラッカーや開発者の報告である場合です。
エラーの原因になっているライブラリを正確に特定する
ファイル名が調査のすべてです。libfoo.so が問題のバイナリだと分かった瞬間、問いは「16 KB 対応をどう直すか」ではなく「libfoo.so はどのパッケージが配布していて、より新しいバージョンはあるか」に変わります。後者には答えがあり、前者にはありません。
まず APK Analyzer から
Build > Analyze APK... を開いてリリース用 APK を読み込み、lib を展開してください。中には ABI ごとのフォルダがあり、通常は arm64-v8a と x86_64 です。Alignment 列が、アライメントに問題のあるファイルに警告を表示します。Android Studio 自身の警告と Lint も要件を満たさないネイティブライブラリを指摘するので、同じ事実が複数の場所に現れることがあります。
バージョン番号をひとつでも触る前に、指摘されたファイル名をすべて記録してください。2つの ABI フォルダは別々に確認してください。arm64-v8a は通るのに x86_64 が失敗する、あるいはその逆はごく普通に起こります。別のバイナリであり、別のパイプラインでビルドされている可能性があるからです。
コマンドラインの出力を読む
ターミナルのほうがよければ、Google が提供する check_elf_alignment.sh が APK について ALIGNED または UNALIGNED を報告しますし、llvm-objdump でライブラリ1本を直接調べることもできます。どちらも Android SDK Build-Tools 35.0.0 以降が必要です。出力されたものを下に貼っていただければ、読み解いてお返しします。
道具 05
ELF デコーダ
llvm-objdump -p file.so | grep LOAD、check_elf_alignment.sh、zipalign -c -P 16 の出力を貼ってください。処理はすべてブラウザ内で行われ、どこにもアップロードされません。
どの依存関係が持っているのかを突き止める
Play Console も APK Analyzer もファイル名だけを渡してきて、所有者は教えてくれません。下に入力していただくと、そのバイナリについて分かっていることを根拠の質とあわせてお伝えし、ファイル名がすでに入った検索コマンドまでお渡しします。
道具 06
ライブラリ所有者の検索
./gradlew app:dependencies は解決された依存関係のグラフを表示します。自分で追加した覚えのないライブラリを引き込んだ推移的なパッケージは、こうして見つけます。ただし特定の .so がどの成果物に入っているかを直接教えてはくれないので、怪しい AAR を展開する作業と組み合わせてください。Google が定めた手順ではなく、実務で使う診断の技法です。
ローカルの APK ではなく App Bundle を確認する
手元の APK と、Google Play がバンドルから生成する APK は別々の成果物です。ELF のアライメントは各ライブラリの内部にあり、ZIP のアライメントはアーカイブをどう詰めたかという性質で、バンドルはそのどちらを使うかを Play に伝える設定を持っています。3つは食い違うことがあり、ユーザーが実際にインストールするものを決めるのは最後のひとつだけです。
この問題の最も苛立たしい形はここから生まれます。開発者はすべて上げ、ローカルの APK を確認し、きれいな出力を見て、アップロードするのに警告は残ったままです。確認したことが間違っていたのではありません。Play が評価する対象を一度も確認していなかっただけです。
あなたが確認したもの
手元の app-release.apk自分のマシンで Gradle が直接ビルドし、自分のパッケージング動作が反映されたファイルです。ここで zipalign を通ったことは、このファイルが正しく詰められている証明になります。
Play が評価するもの
app-release.aab から生成された APKバンドルが要求したアライメントを使って Google がビルドしたファイルです。バンドルが 4 KB と言っていれば、ローカルの APK がどれだけきれいでもこちらは間違いです。
ですからアップロードしようとしているバンドルに対して、毎回これを実行してください。
bundletool dump config --bundle=app-release.aab | grep alignment
欲しい結果は PAGE_ALIGNMENT_16K です。PAGE_ALIGNMENT_4K は、バンドルが bundletool にネイティブライブラリを 4 KB の境界でパッケージするよう伝えているという意味なので、Play がそのバンドルからビルドする APK はすべて間違いになります。Google は、Android Gradle Plugin 8.3 から 8.5 がまさにこのずれを生みうると特に警告しています。ローカルのビルドはアライメント済みに見えるのに、Play がバンドルからビルドしたアプリは 16 KB 端末で正しくインストールされません。推奨される解決策は Android Gradle Plugin 8.5.1 以降に上げることです。
自分のファイル名が入ったコマンド一式
ファイル名を一度だけ入力してください。以下のコマンドがすべてその名前で書き換わり、タブごとに合格と見なせる正確な出力を表示します。結果が良かったのかを推測する必要はありません。
道具 07
コマンドラボ
「APK Analyzer がアライメント済みと言っている」で止まらないこと
APK の点検を通ったのは4つのチェックのうちのひとつであって、ゴールではありません。ELF の LOAD アライメント、APK の ZIP アライメント、バンドルの設定、そして Play が実際に生成する成果物の実行時の挙動をすべて確認してください。このうちひとつが失敗するだけで、直したと信じたビルドの後もアカウントに警告が残ります。
AGP と NDK、そして落とし穴
ふたつのバージョンが大部分を担います。NDK r28 以降はネイティブコードを既定で 16 KB にアライメントしてコンパイルし、Android Gradle Plugin 8.5.1 以降は圧縮されていないネイティブライブラリを 16 KB の ZIP 境界に正しく配置します。ただしどちらも、依存関係にコンパイル済みで入ってきたバイナリを直すことはできません。
危険な中間地帯が Android Gradle Plugin 8.3 から 8.5 です。この範囲では、ローカルのビルドが完全に正しく見えても bundletool が Play 向けにバンドルから作る APK を ZIP アライメントしないことがあり、結果についての Google の表現ははっきりしています。そのバンドルからビルドされたアプリは正しくインストールされません。8.5.0 をお使いで、思いつく限りのチェックをローカルの APK が通っているなら、まず最初に排除すべきはこれです。
道具 08
ツールチェーン診断
ビルド設定の早見表
| 状況 | 設定 | 備考 |
|---|---|---|
| 推奨する NDK | r28 以降 |
既定で 16 KB アライメントのネイティブ出力を生成 |
| 推奨する AGP | 8.5.1 以降 |
圧縮されていないネイティブライブラリを 16 KB の ZIP 境界に配置 |
| NDK r27 以前 | -Wl,-z,max-page-size=16384 |
すべてのネイティブターゲットに必須のリンカオプション |
| NDK r27 以前 | -Wl,-z,common-page-size=16384 |
最大ページサイズのオプションと併用 |
ndk-build |
LOCAL_LDFLAGS += ... |
ネイティブターゲットごとに両方のオプションを適用 |
| CMake | target_link_options(...) |
該当するターゲットごとに両方のオプションを適用 |
| AGP を上げられない | jniLibs.useLegacyPackaging = true |
ネイティブライブラリを圧縮、インストール容量が増加 |
| AGP 8.0 以下 | android.bundle.enableUncompressedNativeLibs=false |
上のオプションと併用する追加のレガシープロパティ |
| 実行時のコード | getpagesize() または sysconf(_SC_PAGESIZE) |
固定の 4096 や PAGE_SIZE 定数の前提を置き換える |
パッケージングでは直せない部分
ご自身の C や C++ がページサイズを前提にしているなら、どんなビルドオプションも助けてくれません。固定の 4096 の値と PAGE_SIZE 定数への依存をなくし、実行時に getpagesize() または sysconf(_SC_PAGESIZE) で実際の値を取得し、すべての mmap() 呼び出しと手でページアライメントしている引数を見直してください。これは、アプリが 16 KB 端末にきれいにインストールされ、バンドルのチェックも通ったうえで、メモリマッピングに最初に触れた瞬間に落ちる種類の失敗です。
作業の順番
パッケージングより先にコンパイラ側を直してください。レガシーパッケージングの回避策を先に適用すると、中のライブラリがまだ 4 KB ページ向けにビルドされたまま APK が zipalign を通り始めます。本当の問題を緑色の結果の裏に隠すことになります。
実際の 16 KB 環境でテストする
テストに意味があるかどうかは、コマンド1行が決めます。adb shell getconf PAGE_SIZE が 16384 を返す必要があります。作業を始めるたびに実行してください。静かに 4 KB モードで起動したエミュレータは、壊れたビルドが何を投げても通してしまいます。
現実的な道が3つ、専門的な道が2つあります。今日すぐ手が届くものを選んでください。ページサイズの失敗を捕まえるという目的では、これらの間に品質の差はありません。
道具 09
テスト環境の選択
限界
そして毎回、どんなテストの前にも
adb shell getconf PAGE_SIZE
出力が 16384 でなければ先に進まないでください。
実際に動かすべきもの
環境が確認できたら、意味のあるテストは「起動するか」ではありません。ネイティブの失敗はネイティブコードに触れる機能に集まるので、そこを意図的に動かしてください。コールドスタート、アプリ内の画面遷移、カメラ、データベースの読み書き、メディアの再生と録音、認証、バックグラウンド処理、機械学習や AR の機能、すべてのネイティブプラグインが関わる画面、そしてご自身のコードでメモリマッピングを使っている部分です。いま上げたライブラリが支えている機能があるなら、その機能こそがテストです。
互換モードは合格ではありません
Android は 4 KB でアライメントされた一部のアプリを互換の経路で 16 KB 端末上で動かすことができ、その際に初回起動で警告が出ることがあります。それでも Google は、信頼性と安定性のために正しい 16 KB アライメントを推奨しています。互換モードが働いたおかげでかろうじて動くアプリは直ったアプリではなく、その状態でリリースするということは、本当の失敗がまだ先に待っているということです。
直して上げたのに警告が生き残る理由
「もう直したのに」というケースはほぼすべて、13の具体的な状況のどれかであり、そのうち11は目の前の成果物だけで証明できます。当てはまる症状を選べば、たいてい読み終わる前に原因が分かります。
道具 10
警告が残るときの診断
このうち2つのケースは、自信のある答えより留保を付けるほうが適切です。Google Play がアップロードされたバンドルを再評価するのにどれだけかかるかを定めた一次情報はありません。ですからアップロード直後に警告が残っている場合、処理時間についてどこかで読んだ特定の数字を信じるのではなく、新しいバージョンコードが最新のリリースと App Bundle の画面に現れているかを確認し、後でもう一度見るのが誠実な対応です。そして互換モードが働いたおかげでかろうじて動くアプリは、直ったのではなく見逃されているだけです。
繰り返し名前が挙がるサードパーティのライブラリ
ここにあるのは報告された事例であって、それぞれがどれだけ多いかの順位でも、特定のバージョンがあなたのビルドを直すという約束でもありません。どのパッケージも、どのリリースでもネイティブの成果物を追加・削除・差し替えできます。最終的な権威はいつも、ご自身のリリース用バンドルに入っているバイナリです。
ファイル名に見覚えがあるときの出発点としてお使いいただき、そのうえでそのプロジェクトの現在のリリースと未解決の Issue で確認してください。根拠がリリースノートではなくメンテナーの Issue トラッカーである場合は、カードにそう書いてあります。
道具 11
報告のあるライブラリ一覧
libobjectbox-jni.so
古い Android のネイティブライブラリが 16 KB 環境で失敗しました。どのバージョンで直ったかは、ここに載せられるほど確認できていません。ObjectBox の現在のリリースノートで 16 KB 対応が入ったバージョンを確認し、バージョンだけを信じずにビルドされた APK 内のバイナリを確かめてください。
同梱される Android ライブラリ
ObjectBox の Dart SDK は自前の Android ライブラリを同梱しています。どのバージョンで直ったかは、ここに載せられるほど確認できていません。ObjectBox の現在のリリースノートを確認したうえで、ビルドが実際に解決して取り込む成果物を確かめてください。
libsqlite3.so
影響を受けた Flutter と AWS Amplify のパッケージングで、古い 3.43.0 の依存関係が現れました。Issue の根拠は、16 KiB 対応が入ったバージョンとして 3.46.1+1 を挙げています。宣言したバージョンだけでなく、実際に解決された依存関係のバージョンを確認してください。フレームワークのパッケージが古いバージョンを固定していることがあります。
sqlcipher-android
古い android-database-sqlcipher パッケージは上流で非推奨となり、メンテナンスされている sqlcipher-android に置き換えられています。修正済みの最小バージョンとして載せられるほど確認されたバージョンはないので、現在メンテナンスされているパッケージへ移行し、バージョン番号を信じるのではなくビルドされたアプリで全 ABI を検証してください。
メディア処理のバイナリ
元の FFmpegKit のリポジトリは運用終了となり、どこでも安全と言える要件充足のリリースは確認できていません。フォークによって品質が異なります。ビルドが正確にどのフォークを解決して取り込むかを特定し、その ABI 成果物を直接確認し、どれかを解決策として採用する前にメンテナンス状況と出どころを検討してください。
Realm と JNI のバイナリ
報告が食い違っています。20.1.0 が指摘され、その後の報告では 20.2.0 が Realm のバイナリひとつは直したものの、別の JNI バイナリは問題のままだったとされています。責任を持って安全なバージョンをひとつ挙げることはできないので、上げたうえで Realm が持ち込むライブラリをひとつずつ確認してください。
libmediapipe_tasks_vision_jni.so
2**12 のアライメントとして報告されています。参照した Issue では修正リリースが確定していないので、互換性はバージョンごとの問題として扱ってください。現在のリリースノートを確認し、上げ、ご自身のビルド内のバイナリを検証してください。
OpenCV Android の成果物
OpenCV 5.0.0 の Android 成果物についてアライメントの問題が報告されました。リポジトリの Issue は CI 側の修正に触れていますが、特定のリリース成果物が安全だとは確定していません。依存している当の AAR をダウンロードし、展開してライブラリをご自身で確認してください。
lib_burst_generated.so
このファイルが指摘されたら Burst パッケージを 1.8.21 以降に更新する、というのが Unity 自身の案内です。この一覧で、Issue の報告ではなくベンダーの公式ドキュメントに裏づけられた唯一の項目です。
libUnityARCore.so、libquack.so など
コミュニティの報告は、エディタを上げても生き残るバイナリとしてこれらを挙げています。それぞれ別のパッケージに属するので、共通して引用できるバージョンはありません。正確なファイル名を手がかりに、どのパッケージを追うか決めてください。
その条件に一致する項目はありません。正常です。この一覧は報告のあった事例を扱うだけで、エコシステムのすべてのライブラリを網羅していません。ライブラリ所有者の検索を使い、ご自身のプロジェクトの中でそのファイルを追跡してください。
この一覧が短いのには理由があります。Issue の件数は声の大きい利用者が多いプロジェクトを示すだけで、どのライブラリが最も多くインストールされているかは教えてくれません。「最も多い原因」の順位表を載せるのは統計を作り出すことです。代わりに一般化できるのは方法のほうです。ファイル名をつかみ、パッケージを探し、そのパッケージの現在のリリースを確認し、自分のビルド内のバイナリを検証してください。
2026年8月31日の API 36 の期限との関係
この2つは、1点だけで交わる互いに独立した Google Play の要件です。ターゲット API レベルを上げると 16 KB の警告が表面化することがあります。この要件が Android 15（API レベル 35）以上をターゲットにするアプリに適用されるからです。レベルを上げることがアライメントのずれを作るわけでも、直すわけでもありません。
Google Play は2026年8月31日から、新規アプリとアプリの更新に Android 16（API レベル 36）をターゲットにすることを求めており、2026年11月1日までの延長を申請できます。これはマニフェストと動作の変更です。一方、16 KB のルールはバイナリ互換性の変更です。月曜に targetSdk を上げて火曜に 16 KB の警告を見た開発者は、何かを壊したわけではありません。ネイティブライブラリはもともと 4 KB ページ向けにビルドされていて、ターゲットレベルが上がったことで、いずれ適用されるチェックの対象範囲にアプリが入っただけです。
要件 A
API 36 をターゲットにする- 期限 2026年8月31日、2026年11月1日まで延長可
- 対象 新規アプリとアプリの更新
- 場所 マニフェストとビルド設定
- 解決方法 ターゲットレベルを上げ、Android 16 の動作変更に対応する
要件 B
16 KB ページサイズへの対応- 期限 2027年2月1日
- 対象 64ビット端末で API 35+ をターゲットにするアプリ
- 場所 バンドルに含まれるネイティブバイナリ
- 解決方法 アライメントがずれたライブラリをすべてビルドし直すか差し替える
実務では、証拠が2つある1回の移行として扱ってください。どのみちターゲットレベルは上げることになります。API 36 の締め切りに追われている最中に見つけるのではなく、ネイティブライブラリの点検を同じリリースに組み込んでください。端末フォームファクタごとのレベル、例外、延長の仕組みについてはGoogle Play の API 36 期限の記事を、アカウントから製品版までの流れ全体については2026年の公開要件の記事をご覧ください。
アップロード前のリリース関門
それぞれに合格の根拠がはっきりしたチェックが11個あります。Play に何かおかしいと言われた後ではなくアップロード前にひとつずつ進めれば、終わりの見えないデバッグが終わりの決まったリストに変わります。
道具 12
リリース関門
11件中 0件クリア
まだ何も証明されていません。たまたま開いていた最後のビルドではなく、実際にアップロードするビルドから始めてください。
進捗はこのブラウザにだけ保存されます。どこにも送信されず、ブラウザのデータを消すと一緒に消えます。
11個の関門をすべてクリアしたことは、このページが引用したチェックに照らして技術的にアライメントされていることの証明です。承認の約束ではありません。Google Play は同じアップロードについて、これとは無関係なポリシー、コンテンツ、品質の問題を提起することがあり、どのチェックリストもその部分を代弁できません。
この問題がクローズドテストとぶつかる地点
このページの内容がテスター要件を変えることはありませんし、テスター側の事情がビルドを変えることもありません。2つの問題がぶつかる軸はひとつだけ、時間です。14日間のクローズドテストは止められない時計の上で動き、ネイティブライブラリの調査は誰にも読めない時計の上で動きます。
つらい順番はこう流れます。個人用デベロッパーアカウントでクローズドテストを始め、14日間連続のオプトイン期間が回り始めます。そしてその途中のどこかで、ターゲットレベルを上げた拍子に 16 KB の警告が現れます。開発者はテスターグループをそのまま保ったまま、ネイティブの依存関係をビルドし直すことになります。トラックに新しいビルドをアップロードすること自体は問題なく、Google もテスト中に更新を続けることを推奨しています。進行を壊すのは、テスター側が静かになることです。
その部分を支えるのが PrimeTestLab です。Android 7 から 17 にわたる実機の実在するテスター12人を用意し、14日間ずっとオプトインを維持します。ですからビルドし直している間、相手にするのは崩れていくテストではなく安定したテストです。テストは4～6時間で開始し、これまでに120+か国でアプリ7,400+本をこの方法で進め、成功率99.9%を記録しています。
自分でテスターを集める場合と、任せる場合
| Google の要件 | 自分で集める場合 | 任せる場合 |
|---|---|---|
| オプトイン済みのテスター12人以上 | 実在する人を探し、説明し、追いかけて、誰もオプトアウトしないことを願う | 12人を用意し、期間中ずっと維持します |
| 14日間連続 | 途中で1人抜けるだけで連続期間が途切れる | グループを管理し、期間が途切れないようにします |
| 実機、実在する人 | エミュレータや休眠アカウントが定番の近道であり、失敗の定番の理由 | Android 7 から 17 の実機 |
| 最初のオプトインまでの時間 | 誰が返事をくれるか次第で数日 | 4～6時間でテスト開始 |
| 費用 | ライブラリのビルドし直しで手一杯な、その週のあなたの時間 | $19.99から、別途サービス手数料5% |
| テスト中のビルドし直し | アップロードのたびに更新をお願いし直すことになる | 新しいビルドを自由に上げても、グループはオプトインを維持します |
境界をはっきりさせておきます。こちらはネイティブライブラリを代わりにビルドし直しませんし、この記事もそのサービスを売るためのものではありません。16 KB の作業は開発者の側の仕事で、このセクションより上の内容はすべて、その作業を最短で終えていただくために書いています。こちらが引き受けるのは、その横で同時に走るテスター要件です。そうすれば2つの問題が同じ2週間を奪い合わずに済みます。
順番のコツ
まだクローズドテストを始めておらず、ネイティブライブラリがあると分かっているなら、先にテスター期間を回し、その中でアライメントの作業をしてください。Google の資格期間はひとつの固定されたビルドではなくテスターのオプトインの継続を基準に測られ、テスト中も更新を続けることが推奨されています。ですから2つのスケジュールは積み上げずに重ねられます。その間、トラックとテスターグループはそのままにしておいてください。これだけで1週間まるごと節約できることがよくあります。
よくある質問
Google Play はいま 16 KB 非対応のアプリを却下していますか。
Google の現行ドキュメントは、2027年2月1日から、Android 15（API レベル 35）以上をターゲットにしながら64ビット端末の 16 KB に対応していない更新はリリースできなくなると述べています。その日までは、多くの開発者が目にするのは完全な停止ではなく Play Console の互換性の警告です。引用元の Google のページに書かれた結果は、要件を満たさない更新をリリースできないということであって、すでに公開済みのアプリが自動的に削除されるということではありません。
Google は2027年2月1日と言っているのに、他の記事が2025年11月1日と書いているのはなぜですか。
2025年11月1日は Google が最初に発表した期限で、2026年5月31日はその後の延長日です。2026年8月5日時点で、Google の現行の Android Developers ページと現在の Play Console の警告のスクリーンショットはどちらも2027年2月1日を示しているので、新しい一次情報が基準になります。多くのブログ記事や AI の回答が古い日付を引用し続けているのは、変更前に書かれたからです。
C++ を書いたことがないのに、なぜ自分のアプリが対象なのですか。
ご自身のソースが Dart、JavaScript、Python、Java、Kotlin であっても、フレームワーク、SDK、プラグイン、ゲームエンジン、データベース、メディアコンポーネント、アプリビルダーがネイティブの .so ファイルを追加することがあります。Google のガイダンスも、依存関係を通じて間接的に NDK ライブラリを使うアプリを明示的に含めています。Android Studio で Build から Analyze APK を選んで APK を開いてください。lib の下に .so ファイルがひとつでもあれば、パッケージされたアプリがネイティブコードを使っているということです。
純粋な Kotlin のアプリでも何か変更が必要ですか。
Google によれば、ライブラリと SDK を含めて Java または Kotlin だけを使うアプリは、すでに 16 KB 端末に対応しています。それでも想定外の不具合を見つけるために 16 KB 環境でのテストは推奨されています。純粋な Kotlin だと決める前に、実際のリリース用 APK に lib ディレクトリがないことを確認してください。分析やデータベースの依存関係ひとつで増えることがあります。
Flutter のどのバージョンなら 16 KB ページサイズの警告が解決しますか。
すべての Flutter アプリとプラグインが要件を満たすと保証する単一の Flutter バージョンは、どの公式情報にもありません。Flutter 3.27 のリリースノートは見た目より範囲が狭く、エンジン全体ではなく plugin_ffi テンプレートの 16 KB 対応を扱っています。ドキュメントで確認できる最も強い節目は Flutter 3.38 です。Flutter がこのバージョンへの更新を Play の 16 KB 要件への備えとして明示し、既定の NDK を r28 に切り替えたからです。最も安全なのは、現在の安定版に上げ、ネイティブプラグインをすべて更新し、リリース用バンドルをビルドし直し、出てきた .so ファイルをひとつずつ確認することです。
React Native はどのバージョンから 16 KB ページに対応していますか。
React Native 0.77 が明確な公式の基準です。そのリリース告知で、React Native が 16 KB ページサイズに完全対応する準備ができたと述べられています。ただしコミュニティのネイティブモジュール、ご自身の C++ コード、サードパーティ SDK は今も非対応のバイナリを含む可能性があるので、サポートされた React Native または Expo の移行手順で上げてから、生成された APK を確認してください。
16 KB ページサイズに対応するには Unity のどのバージョンが必要ですか。
Unity は 6000.1 以降、6000.0.38f1 以降、2022.3.56f1 以降、そして対象となる Enterprise または Industry 顧客向けの拡張 LTS では 2021.3.48f1 以降を挙げています。ネイティブプラグインも併せて更新し、Play Console が lib_burst_generated.so を挙げた場合は Burst を 1.8.21 以降に上げてください。サポートされたエディタのバージョンは必要条件ですが十分条件ではありません。サードパーティのプラグインは独自のバイナリを持ち込むからです。
問題になっている .so ファイルを正確に特定するにはどうしますか。
Android Studio で Build から Analyze APK を選んで APK を開き、lib/arm64-v8a と lib/x86_64 を展開して Alignment 列を見てください。アライメントに問題のあるファイルに警告が表示されます。コマンドラインで確かめるなら、Google の check_elf_alignment.sh を APK に対して実行するか、llvm-objdump -p file.so の出力を grep LOAD で絞ってライブラリ1本を調べてください。LOAD のアライメントが 2**14 未満であれば対処が必要です。
APK は通るのに App Bundle が失敗し続けるのはなぜですか。
ライブラリ内部の ELF アライメントと、パッケージされた成果物内部の ZIP アライメントは別々の2つのチェックです。bundletool dump config --bundle=app.aab を実行して alignment を grep してください。PAGE_ALIGNMENT_16K なら合格、PAGE_ALIGNMENT_4K なら生成される APK が今も 4 KB で要求されているという意味です。Google は、Android Gradle Plugin 8.3 から 8.5 がローカルでは正しく見えても Play がバンドルからビルドする APK の ZIP アライメントが適切でないことがあると特に警告しているので、8.5.1 以降に上げてください。
NDK r28 に上げるだけで解決しますか。
いいえ。NDK r28 以降は既定で 16 KB にアライメントしてコンパイルしますが、それはビルド中にコンパイルされるネイティブコードにしか効きません。サードパーティの AAR、プラグイン、ゲームエンジンのパッケージに含まれてくるコンパイル済みの .so ファイルを書き換えることはできません。ビルド済みのネイティブ依存関係は、それ自体を更新するか差し替えるか、ビルドし直して取り込み直す必要があります。
対応端末を持っていなくても 16 KB 対応をテストできますか。
SDK Manager から Google の 16 KB Android エミュレータのシステムイメージを入れるか、Samsung Remote Test Lab で対応端末を予約してください。どれを使うにしても、まず adb shell getconf PAGE_SIZE で環境を確認してください。出力が 16384 でなければ、その後のテストに意味はありません。エミュレータで成功したことは実行時の挙動を示すだけでパッケージングを示さないので、リリース用バンドルの確認も続けてください。
16 KB 対応を直すと、進行中のクローズドテストはリセットされますか。
Google は資格期間を、ひとつの固定されたビルドではなく、テスター12人以上が14日間連続でオプトインしている状態を基準に測っており、テスト中もビルドの更新を続けることを推奨しています。ただしすべてのビルド差し替えの場面を保証すると明記した文書はないので、テストの途中で 16 KB 要件を満たすバンドルに差し替えるときは、テスターグループをそのまま保つのが最も安全です。PrimeTestLab は$19.99から実機の実在するテスター12人を用意し、14日間ずっとグループを維持します。別途サービス手数料5%。
まとめ
要約
Google Play は Android 15（API レベル 35）以上をターゲットにするアプリに、64ビット端末での 16 KB メモリページサイズへの対応を求めています。2027年2月1日からは、要件を満たさない更新をリリースできません。2025年11月1日と2026年5月31日はすでに死んだ日付ですが、検索では今も上位に出てきます。純粋な Java または Kotlin のアプリはすでに要件を満たしています。それ以外はすべて同じ3ステップです。問題の .so の名前を突き止め、そのファイルを含むパッケージを更新し、独立した2つのチェックで成果物を証明してください。すべての ELF LOAD セグメントが 2**14 以上であること、そして App Bundle が PAGE_ALIGNMENT_16K を報告することです。AGP 8.5.1+ と NDK r28+ の組み合わせが最も安全な既定のツールチェーンですが、どちらも他人がコンパイルしたバイナリを直すことはできません。この作業がクローズドテストの最中に降ってきたなら、任せられるのはテスター側です。料金プランを見る →
一次情報
このページで最初に古くなる情報
- 2027年2月1日という日付。Google はこのスケジュールをすでに1回以上動かしています。この日付を前提にリリース計画を立てる前に、ページサイズのガイド末尾にある「Last updated」の表示を確認してください。
- Play Console の文言。Console の文言とメニュー構成はポリシー文書とは別に変わるため、画面で見える見出しがここに再現したものと違う場合があります。
- フレームワークの基準バージョン。Flutter は安定版を頻繁に出し、React Native のサポート方針は変わり続け、Unity の LTS 対象バージョンも変化します。記事に印刷されたバージョンではなく、現在のリリースノートで確認してください。
- 報告のあるライブラリ一覧。どのパッケージも、どのリリースでもネイティブバイナリを追加・差し替え・後退させることがあります。必ずご自身のバンドル内の成果物を確認してください。
- エミュレータイメージの名前。実験的と表示されたイメージは名前が変わったり正式版に昇格したりするので、SDK Manager に見える文字列が一致しないことがあります。
2026年8月9日に Google のドキュメントと照合して確認しました。施行後1か月まで毎月見直します。