Google Play 16 KBページサイズ要件に関する技術的詳細報告書

第1章 16 KBページサイズ採用の戦略的必然性
1. 1.1 公式要件：期限と適用範囲
2. 1.2 背景にある「なぜ」：プラットフォームレベルでのパフォーマンス向上イニシアチブ
第2章基礎概念：現代Androidにおけるメモリ管理
第3章 16 KB準拠のための包括的ガイド
第4章厳格な検証：テストとバリデーションのプロトコル
1. 4.1 テスト環境の構築
2. 4.2 テストの実行と分析
第5章将来展望と高度な考察

第1章 16 KBページサイズ採用の戦略的必然性

1.1 公式要件：期限と適用範囲

Google Playは、Androidエコシステムのパフォーマンスと効率性を向上させるための新たな技術要件を導入しました。この要件の中核は、メモリ管理の基本単位である「ページサイズ」の移行です。具体的には、2025年11月1日以降、Google Playに提出される全ての新規アプリおよび既存アプリのアップデートで、Android 15（APIレベル35）以上をターゲットとするものは、64ビットデバイス上で16 KBのページサイズをサポートすることが義務付けられます。

この要件が直接影響を及ぼすのは、ネイティブコード、すなわちC/C++で記述されたコードを含むアプリケーションです。これには、Android NDKを直接使用して開発されたコードだけでなく、ネイティブライブラリを含むサードパーティ製のSDKやライブラリに依存している場合も含まれます。

一方で、Javaプログラミング言語またはKotlinのみで記述され、ネイティブコードへの依存関係が一切ないアプリケーションは、原則として既に対応済みと見なされます。しかし、予期せぬ挙動の後退（リグレッション）がないことを確認するため、これらのアプリについても16 KB環境でのテストが強く推奨されています。

この要件の最も重要な点は、非準拠のアプリケーションが将来的に16 KBページサイズで構成されたデバイス上で正常に動作しなくなる可能性があるという事実です。具体的には、アプリのインストール失敗や、起動直後あるいは実行中のクラッシュといった致命的な問題が発生する可能性があります。したがって、この要件への対応は、将来のAndroidデバイスにおけるアプリの可用性を確保するための不可欠な措置となります。

1.2 背景にある「なぜ」：プラットフォームレベルでのパフォーマンス向上イニシアチブ

この16 KBページサイズへの移行は、単なる開発者への負担を強いるための官僚的な規定ではありません。これは、GoogleがAndroidプラットフォーム全体のパフォーマンスを底上げするための戦略的な一手です。この変更の背景には、近年のスマートフォンにおけるハードウェアの進化、特に搭載RAM（Random Access Memory）の大容量化という明確なトレンドがあります。

従来の4 KBページサイズは、RAMが比較的小さかった時代のデバイスに最適化されていましたが、大容量RAMが標準となった現代のデバイスでは、メモリ管理のオーバーヘッドが相対的に大きくなり、非効率性が目立つようになっていました。

Googleが実施した広範なテストによれば、16 KBページサイズへの移行は、ユーザー体験に直結する具体的かつ測定可能なパフォーマンス向上をもたらします。報告されている主な改善点は以下の通りです。

アプリ起動時間の短縮：メモリへの負荷が高い状況下で、アプリの起動時間が平均で3.16%、一部のアプリでは最大30%も高速化されることが確認されています。
電力効率の向上：アプリ起動時の消費電力が平均で4.5%削減され、バッテリー持続時間の改善に貢献します。
カメラ起動の高速化：カメラの起動時間が、ホットスタートで平均4.5%、コールドスタートでは平均6.6%短縮されます。
システム起動の高速化：Androidデバイス自体の起動時間が約8%（およそ0.8秒から950ミリ秒）速くなります。

これらの具体的な数値は、16 KBページサイズへの移行が抽象的な技術的変更ではなく、エンドユーザーが日常的に体感できるレベルでの快適性向上に直接つながることを明確に示しています。

この要件は、孤立したポリシーとして登場したわけではありません。これは、AOSP（Android Open Source Project）内部で数年にわたり進められてきたアーキテクチャ進化の集大成であり、ハードウェアエコシステムの進化に対する直接的な応答です。この動きは、Androidが競合プラットフォームとの性能差を埋めるための重要なステップと位置づけられます。事実、AppleのiOSは、2013年に発表されたA7チップ搭載のiPhone 5Sで既に16 KBページサイズを導入しており、Androidはこの点で後れを取っていました。

この移行への道筋は段階的に敷かれてきました。まず、最新のARM CPUは長年にわたり、4 KBより大きなページサイズをサポートしていました。次に、デバイスメーカーが搭載RAMを増やし続けたことで、従来の4 KBページによるメモリ管理の非効率性が顕在化しました。

これを受け、OSレベルでの対応としてAndroid 15が「ページサイズ非依存（page-size-agnostic）」となり、4 KBと16 KBの両方のページサイズで効率的に動作する基盤が整いました。そして最終段階として、今回のGoogle Playポリシーが導入され、アプリケーションエコシステム全体をハードウェアとOSの進化に整合させるための強制力として機能しているのです。これは恣意的なルールではなく、長期的なプラットフォーム戦略の論理的な帰結と言えます。

第2章基礎概念：現代Androidにおけるメモリ管理

2.1 仮想メモリ、ページ、そしてMMU

16 KBページサイズ要件の技術的背景を深く理解するためには、現代のオペレーティングシステム（OS）におけるメモリ管理の基本概念を把握することが不可欠です。その中核をなすのが「仮想メモリ」という抽象化技術です。

仮想メモリは、各アプリケーションに対して、他のプロセスから完全に独立した、広大で連続的なプライベートアドレス空間を提供します。これにより、アプリケーションは物理メモリの実際の搭載量や複雑な配置を意識することなく、あたかもメモリ全体を独占しているかのように動作できます。

この仮想メモリシステムを効率的に管理するため、OSは仮想アドレス空間と物理RAMの両方を「ページ」および「フレーム」と呼ばれる固定サイズのブロックに分割します。仮想メモリのブロックが「ページ」、物理RAMのブロックが「フレーム」であり、両者は常に同じサイズに設定されます。Androidでは、歴史的にこのサイズが4 KB（4096バイト）に固定されてきました。

そして、この仮想アドレスから物理アドレスへの変換という重要な役割を担うのが、「メモリ管理ユニット（MMU）」と呼ばれるCPUに内蔵された専用ハードウェアです。アプリケーションが特定のメモリアドレスにアクセスしようとすると、MMUが介入し、OSが管理する変換テーブルを参照して、対応する物理RAM上のアドレスを特定します。

2.2 ボトルネック：ページテーブルとTLB（Translation Lookaside Buffer）

MMUがアドレス変換を行う際に参照するのが、「ページテーブル」です。ページテーブルは、OSがプロセスごとに管理する巨大なマップであり、アプリケーションの各仮想ページが物理RAMのどのフレームに対応付けられているかを記録しています。アプリケーションがコードを実行する中でメモリアクセスを行うたびに、MMUはこのページテーブルを辿って目的の物理アドレスを見つけ出す必要があります。

しかし、ページテーブルはメインメモリ（RAM）上に存在するため、毎回アクセスするのは非常に低速です。このプロセスがパフォーマンスの深刻なボトルネックとなるのを防ぐために、CPUには「TLB（Translation Lookaside Buffer）」と呼ばれる、小規模かつ高速な専用のハードウェアキャッシュが搭載されています。TLBは、最近使用された仮想アドレスと物理アドレスの変換結果を一時的に保持します。

アプリケーションが必要とするアドレス変換情報がTLB内に存在する場合、これを「TLBヒット」と呼びます。TLBヒットが発生すると、アドレス変換は瞬時に完了し、低速なページテーブルへのアクセスを完全に回避できます。これがパフォーマンスにおける「高速経路（Fast Path）」です。

一方、必要な情報がTLB内に存在しない場合、「TLBミス」が発生します。TLBミスが起きると、CPUは動作を一時停止し、メインメモリ上のページテーブルを階層的に辿って目的の情報を探し出す「ページウォーク」と呼ばれる低速な処理を実行せざるを得ません。このページウォークこそが、CPUのストール（待機状態）を引き起こし、システム全体のパフォーマンスを低下させる主要な原因となります。

2.3 16 KBの利点：オーバーヘッドとTLBミスの削減

16 KBページサイズの導入は、まさにこのTLBミスの問題を解決するためにあります。ページサイズを従来の4 KBから16 KBへと4倍に拡大することで、システムは同じメモリ量を管理するために必要なページの数を4分の1に削減できます。

この変更は、いくつかの連鎖的な利点をもたらします。第一に、管理するページ数が減ることで、ページテーブル自体のサイズが小さくなり、OSのメモリ管理にかかるオーバーヘッド（付帯的なコスト）が軽減されます。

そして最も重要な利点が、「TLBリーチ」の劇的な拡大です。TLBリーチとは、TLBが持つ限られたエントリ数でカバーできる総メモリ領域のことです。例えば、TLBに1024個のエントリがあると仮定します。4 KBページの場合、カバーできるメモリ領域は $1024 \times 4 KB = 4 MB$ です。

しかし、16 KBページの場合、同じエントリ数で $1024 \times 16 KB = 16 MB$ のメモリ領域をカバーできます。TLBリーチが4倍になることで、アプリケーションが実行中に必要とするアドレス変換情報がTLB内に存在する確率（TLBヒット率）が大幅に向上し、パフォーマンス低下の原因となるTLBミスとページウォークの発生頻度が劇的に減少します。

もちろん、この移行にはトレードオフも存在します。ページサイズが大きくなると、ページの末尾に未使用の領域が残りやすくなる「内部断片化」によって、メモリの無駄がわずかに増加する可能性があります。しかし、潤沢なRAMを搭載する現代のデバイスにおいては、このわずかなメモリ消費増は、システム全体のパフォーマンスと電力効率の大幅な向上という多大な利益と引き換えに十分に許容できる代償であると結論付けられています。

この16 KBへの移行は、本質的にCPUとメモリ間のインターフェースという、現代のコンピューティングにおける中核的なボトルネックの効率を改善するための取り組みです。Googleが報告するパフォーマンス向上は、個々のアプリが単独で「速く」なった結果ではなく、システム全体がメモリ管理という非生産的な「事務処理」に費やす時間が削減された結果として現れるものです。

TLBミスやページウォークは、システムのバックグラウンドで絶えず発生し、全てのプロセスに影響を与える低レベルなアーキテクチャ上の処理です。ページサイズを拡大することで、これらのコストの高い処理の発生頻度を減らし、CPUが本来の計算処理に集中できる時間を増やすことができます。したがって、アプリ起動の高速化やバッテリー寿命の改善といったユーザーが体感する変化は、より健全で効率的なシステム基盤がもたらす直接的な恩恵なのです。開発者は自らのアプリを修正するだけでなく、デバイス全体のパフォーマンス環境の向上に貢献していると言えます。

第3章 16 KB準拠のための包括的ガイド

このセクションでは、アプリケーションを16 KBページサイズ要件に準拠させるための実践的なワークフローを段階的に解説します。

3.1 初期診断：ネイティブコードの特定とアライメント不整合の検出

準拠作業の第一歩は、自身のアプリケーションが影響を受けるかどうかを正確に診断することです。

ステップ1：影響の有無を確認する改めて、影響を受けるアプリの基準を確認します。C/C++コードの使用、Android NDKの利用、またはネイティブライブラリを含むサードパーティSDKへの依存、これらのいずれかに該当する場合、対応が必要です。
ステップ2：APKを検査する最も簡単で迅速な確認方法は、Android Studioに搭載されているAPK Analyzerを使用することです。生成されたAPKファイルをAPK Analyzerで開き、libフォルダ内に.so（共有オブジェクト）ファイルが存在するかどうかを確認します。.soファイルの存在は、アプリがネイティブコードを含んでいることを示す明確な証拠です。また、Google Play ConsoleのApp Bundle Explorerも、アップロードされたApp Bundleの16 KB準拠状況を直接表示する機能を提供しており、ここで警告が表示されていないかを確認することも有効です。
ステップ3：ELFアライメントを検証する.soファイルが存在するだけでは不十分です。重要なのは、それらのファイルのELF（Executable and Linkable Format）セグメントが16 KB境界に正しくアライメント（配置）されているかという点です。
- 自動チェック：Android Studioは、16 KBに準拠していないライブラリがプロジェクトに含まれている場合、ビルド時に警告を表示したり、Lintチェックで問題を指摘したりする機能を備えています。これらの自動検出機能を活用することが推奨されます。
- 手動でのコマンドライン検証：より詳細な確認を行うには、NDKに含まれるllvm-objdumpツールを使用します。以下のコマンドを実行し、出力を確認します。
  Bash
  llvm-objdump -p /path/to/your/library.so | grep LOAD
  出力の各行の末尾にあるalignの値に注目します。align 2**12は4 KB（ $2^{12} = 4096$ ）アライメントを意味し、これは非準拠です。準拠するためには、この値がalign 2**14（16 KB、 $2^{14} = 16384$ ）以上である必要があります。また、LinuxまたはmacOS環境では、公式に提供されている
  
  check_elf_alignment.shスクリプトを使用してAPK内の全ての.soファイルを一括でチェックすることも可能です。

3.2 ツールチェーンの近代化：準拠したビルド環境の構築

多くの場合、16 KB準拠を達成するための最も効果的かつ簡単な方法は、開発ツールチェーンを最新バージョンに更新することです。以下のバージョンへのアップグレードが必須となります。

Android Gradle Plugin (AGP) 8.5.1以上 ：このバージョン以降のAGPは、パッケージング時に非圧縮の共有ライブラリに対して自動的に16 KBアライメントを適用します。
Android NDK r28以上 ：このバージョン以降のNDKは、デフォルトで16 KBアライメントを有効にしてネイティブコードをコンパイルします。

多くのプロジェクトでは、これらのツールチェーンに更新し、プロジェクトをクリーンビルドするだけで問題が解決します。古いビルドツールを使い続けることは、準拠を困難にするだけでなく、セキュリティや他の互換性の問題を引き起こす可能性もあるため、この機会に近代化を図ることが強く推奨されます。

3.3 ビルドシステムの設定：リンカへの指示の実装

何らかの理由で直ちにNDKを更新できない場合や、ビルドプロセスを明示的に制御する必要がある場合は、ビルドスクリプトにリンカフラグを追加することで対応します。

CMake (CMakeLists.txt)：

CMake

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE "-Wl,-z,max-page-size=16384")

ndk-build (Android.mk)：

Makefile

LOCAL_LDFLAGS += "-Wl,-z,max-page-size=16384"

Gradle (build.gradle/.kts、古いNDK向け)：NDK r27を使用している場合は、以下のように引数を渡すことで対応できます。

Kotlin

// build.gradle.kts
android {
    defaultConfig {
        externalNativeBuild {
            cmake {
                arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
            }
        }
    }
}

パッケージングオプション：android.packagingOptions.jniLibs.useLegacyPackaging = trueという設定があります。これはネイティブライブラリをAPK内で圧縮するもので、アライメントが不整合なライブラリに起因するインストール時の問題を回避できる場合があります。しかし、これは根本的な解決策ではなく、インストールには成功しても実行時にクラッシュするリスクは残ります。最善の策は、アライメント自体を正しく修正することです。

ビルドシステム	NDKバージョン	必要なフラグ/設定	変更対象ファイル
CMake / ndk-build	NDK r28 以上	(デフォルトで有効、対応不要)	–
CMake	NDK r27	`-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON`	`build.gradle` / `.kts`
ndk-build	NDK r27	`APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true`	`Application.mk`
CMake	NDK r26 以下	`-Wl,-z,max-page-size=16384`	`CMakeLists.txt`
ndk-build	NDK r26 以下	`-Wl,-z,max-page-size=16384`	`Android.mk`

3.4 コードレベルの適応：ページサイズ非依存のネイティブコード記述

低レベルなメモリ操作を行うカスタムネイティブコードを記述している開発者は、コード自体の修正が必要になる場合があります。

ハードコードされた仮定の排除：最も重要な原則は、ページサイズが4096バイトであると決めつけないことです。コード内の#define PAGE_SIZE 4096のような定義や、4096という数値を直接使用している箇所は全て排除する必要があります。
動的なページサイズ検出：ページサイズは、必ず実行時にOSから取得するようにします。C/C++コードでは、<unistd.h>をインクルードし、getpagesize()関数またはsysconf(_SC_PAGESIZE)関数を使用します。
メモリのアライメント：ページ境界にアライメントされたメモリを確保する必要がある場合は、malloc()の代わりにposix_memalign()を使用し、アライメント値としてgetpagesize()の戻り値を指定します。
APIの利用：特に注意が必要なのがmmap()のようなAPIです。mmap()のoffset引数は、システムのページサイズの倍数でなければなりません。例えば、8192というオフセットは4 KBページシステムでは有効ですが、16 KBページシステムでは無効となり、mmap()呼び出しが失敗します。この失敗を適切に処理しない場合、アプリケーションのクラッシュに直結します。

3.5 依存関係チェーンの管理：サードパーティSDKとライブラリ

多くの場合、準拠作業で最も困難なのが、自社でコントロールできないサードパーティ製の依存関係への対応です。

依存関係の監査：セクション3.1で解説した手法を用い、アプリに含まれる全てのサードパーティSDKおよびプリビルドの.soファイルが16 KB準拠であるかを徹底的に監査します。
全ての依存関係を更新：最も基本的な解決策は、利用している全てのライブラリを最新バージョンに更新することです。Unity、Flutter、React Nativeといった主要なフレームワークやSDKの提供元は、既に対応済みのバージョンをリリースしています。
ベンダーへの問い合わせ：最新バージョンに更新しても問題が解決しない場合や、更新版が提供されていない場合は、SDKの提供元に連絡し、16 KB対応のタイムラインについて問い合わせる必要があります。
「放棄された」ライブラリの問題：更新が停止してしまったライブラリ（いわゆる「abandonware」）に依存している場合、深刻な問題となります。例えば、広く使われていたffmpeg-kitのオリジナル版は更新が停止しており、16 KB非対応です。このような場合、開発者は、コミュニティによってメンテナンスされているフォークを探す、自らライブラリをフォークしてパッチを適用する、あるいは準拠している代替ライブラリに乗り換える、といった対応を迫られます。これはプロジェクトの重大なリスクとなり得るため、早期の特定が不可欠です。

この16 KB要件への対応は、単にリンカフラグを追加する作業にとどまりません。これは、Androidのネイティブ開発ツールチェーン全体を近代化し、技術的負債を返済する絶好の機会と捉えるべきです。最新のAGPとNDKへの移行は、開発者を古いビルドツールから脱却させます。サードパーティ依存関係の監査は、ソフトウェアサプライチェーン全体を見直すきっかけとなります。

そして、ページサイズ非依存のコードを記述するプラクティスは、将来のアーキテクチャ変更にも耐えうる、より堅牢で移植性の高いネイティブコード文化を育みます。この変化を積極的に受け入れるチームは、コンプライアンスを達成するだけでなく、将来の技術的変化に対してより有利な立場を築くことができるでしょう。

第4章厳格な検証：テストとバリデーションのプロトコル

16 KB準拠のAPKをビルドすることは、戦いの半分に過ぎません。ビルドが成功しても、実行時に問題が発生する可能性があるため、徹底的なテストと検証が不可欠です。

4.1 テスト環境の構築

正確な検証を行うためには、まず16 KBページサイズで動作するテスト環境を構築する必要があります。

Android Emulator：Android StudioのSDK Managerから、Android 15の16 KBページサイズ対応システムイメージをダウンロードし、それを使用してAndroid仮想デバイス（AVD）を作成します。これが最も手軽で推奨される方法です。古いエミュレータイメージを使用する場合は、config.iniファイルにkernel.parameters = androidboot.page_shift=14という行を追加する設定が必要になることがあります ¹。
物理デバイス：Pixel 8やそれ以降の互換デバイスにAndroid 15 QPR1以降をインストールしている場合、「開発者向けオプション」から16 KBページサイズモードを有効にしてテストできます。物理デバイスでのテストは、より現実世界に近い条件下での動作検証を可能にします。
クラウドベースのテストラボ：Samsung Remote Test Labのようなクラウドサービスを利用することで、多種多様な物理デバイスを所有していなくても、リモートで16 KB環境でのテストを実施できます。
環境の確認：テストを開始する前に、対象のデバイスやエミュレータが実際に16 KBページサイズで動作していることを確認することが極めて重要です。以下のADBコマンドを実行し、その出力を確認します。
Bash
```
adb shell getconf PAGE_SIZE
```
出力が16384であれば、環境は正しく設定されています。4096が返された場合は、設定を見直す必要があります。

4.2 テストの実行と分析

テスト環境が整ったら、構造化されたテスト計画に従って検証を進めます。以下のチェックリストは、網羅的な検証を実施するためのガイドラインとなります。

テストカテゴリ	テスト項目	期待される結果
環境設定	`adb shell getconf PAGE_SIZE`でページサイズを確認	`16384`という値が返される
ビルド検証	`llvm-objdump`で全ての`.so`ファイルを分析	全ての`.so`ファイルが`align 2**14`以上を示す
ランタイム安定性	アプリのコア機能フローを実行	クラッシュやANR（Application Not Responding）が発生しない
	Monkeyテストやストレステストを実行	`SIGSEGV`や`SEGV_ACCERR`といったメモリ関連のエラーが発生しない
機能検証	ネイティブSDKを使用する全ての機能をテスト（例：カメラ、AR、ゲームエンジン）	全てのSDK機能が4 KB環境と同様に正常に動作する
パフォーマンス分析	アプリの起動時間（コールド/ホット）をベンチマーク	4 KB環境と同等か、それ以上のパフォーマンスを示す
	メモリ使用パターンをプロファイリング	メモリ使用量が安定しており、許容範囲内に収まっている

このテストフェーズは、単に準拠を確認するだけの作業ではありません。これは、パフォーマンスを最適化するための重要な機会です。Googleが約束したパフォーマンス上の利点が実際に得られているかを確認し、移行プロセス中に意図せず生じたパフォーマンスの低下（リグレッション）を特定するために、4 KBと16 KBの両方の環境でベンチマークを実施することが推奨されます。

これにより、チームは単なる「合否判定」のテストから、より高度な「検証と最適化」のアプローチへと移行できます。このプロセスを通じて、コンプライアンス対応の投資対効果を利害関係者に示し、ユーザー体験が単に維持されるだけでなく、実際に向上したことをデータで証明することが可能になります。

第5章将来展望と高度な考察

5.1 未来はページサイズ非依存

今回の16 KBページサイズ要件は、より柔軟なメモリ管理の未来に向けた第一歩と捉えるべきです。Googleが「ページサイズ非依存（page-size-agnostic）」のコード記述を強調しているのは意図的であり、これは将来的にさらに大きなページサイズ（例えば、一部のツールチェーンでは既に考慮されている64 KBなど）への移行も視野に入れていることを示唆しています。

この要件に対応するためにページサイズを動的に取得し、ハードコードされた値を排除するプラクティスを導入することで、開発者は将来のプラットフォームのアーキテクチャ変更に対して、より迅速かつ容易に対応できるようになります。

5.2 レガシーアプリの長い影

一方で、この変更は、メンテナンスが停止してしまった古いアプリ、特にネイティブコードを使用している「放棄されたアプリ（abandonware）」に大きな影響を与えます。これらのアプリは、新しいAndroidバージョンをターゲットとするアップデートをリリースすることができなくなり、将来的には16 KBページサイズのみをサポートするデバイス上では完全に動作しなくなるでしょう。これは、アプリケーションの長期的な存続のためには、継続的なメンテナンスがいかに重要であるかを浮き彫りにしています。

5.3 結論：投資としてのコンプライアンス

本報告書で詳述したGoogle Playの16 KBページサイズ要件への対応は、単なる義務的なコンプライアンス作業としてではなく、アプリケーションの将来に対する戦略的な投資として捉えるべきです。この移行は、アプリのパフォーマンス、安定性、そして将来のAndroidデバイスとの互換性を確保するための不可欠なステップです。

要約すると、開発者が取るべき行動は明確です。

診断: APK Analyzerやコマンドラインツールを用いて、自らのアプリが影響を受けるか、どのライブラリが非準拠であるかを特定する。
近代化: AGPを8.5.1以上、NDKをr28以上に更新し、ビルド環境を最新の状態に保つ。
修正: 必要に応じてビルドスクリプトを更新し、リンカフラグを追加する。低レベルなメモリ操作を行うコードは、ページサイズを動的に取得するように修正する。
監査: 全てのサードパーティ依存関係を監査し、準拠したバージョンに更新するか、代替策を検討する。
検証: 16 KBページサイズで構成されたエミュレータや物理デバイス上で、機能、安定性、パフォーマンスの徹底的なテストを実施する。

これらの変化を積極的に受け入れ、適切に対応することで、開発者は自らのアプリケーションが現代および未来のAndroidハードウェアの能力を最大限に引き出し、全てのユーザーに対して優れた体験を提供し続けることを保証できるのです。