このページは Cloud Translation API によって翻訳されました。

16 KB ページサイズのサポート

これまで、Android は 4 KB のメモリページサイズしかサポートしていませんでした。システムメモリのパフォーマンスを最適化 Android デバイスでは通常、これが行われています。Android 15 以降、AOSP は 16 KB（16 KB）のページサイズを使用するように設定されているデバイス。アプリで NDK ライブラリを直接使用している場合は、または SDK を介して間接的に行う場合、アプリを再ビルドして 16 KB のデバイスで使用できます。

デバイスメーカーは次々と、より多くのデバイスで物理メモリ（RAM）に加え、これらのデバイスの多くに 16 KB（ページサイズを拡大して、デバイスのパフォーマンスを最適化します。追加しています 16 KB ページサイズのデバイスをサポートしているため、アプリはこれらの関連するパフォーマンスの恩恵をアプリに提供するため改善されています。16 KB デバイスでは、再コンパイルしないとアプリが動作しない可能性があります将来の Android リリースで製品化される際の要件です。

アプリのサポートを追加できるように、アプリが影響を受ける場合は、アプリを再構築し（該当する場合）、アプリをテストエミュレータ（Android 15 を含む）を使用した 16 KB 環境 Android Emulator 用のシステムイメージ）を作成します。

メリットとパフォーマンスの向上

16 KB のページサイズで構成されたデバイスでは、平均でメモリ使用量が若干増加しますが、システムとアプリの両方でさまざまなパフォーマンスが向上します。

システムのメモリ負荷が高いときのアプリ起動時間の短縮: 平均 3.16% 短縮、テストした一部のアプリでは大幅な改善（最大 30%）
アプリ起動時の消費電力の削減: 平均 4.56% 削減
カメラの起動が速くなる: ホットスタートが平均 4.48%、コールドスタートが平均 6.60% 高速化
システムの起動時間の短縮: 平均で 8%（約 950 ミリ秒）短縮

これらの改善は初期テストに基づくものであり、実際のデバイスでの結果は異なる可能性があります。テストを継続する中で、アプリの潜在的な収益増加に関する追加の分析情報を提供していきます。

アプリが影響を受けるかどうかを確認する

アプリがネイティブコードを使用している場合は、16 KB デバイスをサポートするようにアプリを再ビルドする必要があります。アプリがネイティブコードを使用しているかどうか不明な場合は、APK アナライザを使用してネイティブコードが存在するかどうかを特定し、検出された共有ライブラリの ELF セグメントの配置をチェックします。

ライブラリや SDK もすべて含めて、Java プログラミング言語または Kotlin で記述されたコードだけを使用しているアプリは、すでに 16 KB デバイスをサポートしています。ただし、16 KB 環境でアプリをテストし、アプリの動作に予期しないリグレッションがないことを確認することをおすすめします。

アプリがネイティブコードを使用しているか？

次のいずれかに該当する場合は、アプリでネイティブコードを使用しています。

アプリで C/C++（ネイティブ）コードを使用している。アプリで Android NDK を使用している場合は、アプリでネイティブコードを使用しています。
アプリが、それらを使用するサードパーティのネイティブライブラリまたは依存関係（SDK など）とリンクしている。
アプリが、デバイス上のネイティブライブラリを使用するサードパーティ製アプリビルダーでビルドされている。

APK Analyzer を使用してネイティブライブラリを特定する

APK Analyzer は、ビルドされた APK のさまざまな要素を評価するためのツールです。アプリがネイティブコードとライブラリのどちらを使用しているかを確認する手順は次のとおりです。

Android Studio を開き、[File] > [Open] をクリックして任意のプロジェクトを選択します。
メニューバーで、[Build] > [Analyze APK...] をクリックします。
分析する APK を選択します。
lib フォルダ内を調べます。共有オブジェクト（.so）ファイルがある場合はここにホストされています。共有オブジェクトファイルが存在する場合、アプリはネイティブコードを使用しています。共有オブジェクトファイルが存在しない場合や、lib フォルダが存在しない場合、アプリはネイティブコードを使用していません。

共有ライブラリの ELF セグメントのアライメントを確認する

共有ライブラリについては、16 KB ELF アライメントを使用して、共有ライブラリの ELF セグメントが適切にアライメントされていることを確認します。Linux または macOS で開発している場合は、次のセクションで説明するように check_elf_alignment.sh スクリプトを使用できます。コマンドラインツールを直接使用することもできます。

check_elf_alignment.sh スクリプトを使用する（Linux または macOS）

check_elf_alignment.sh スクリプトを使用して ELF セグメントの配置を確認する手順は次のとおりです。

check_elf_alignment.sh スクリプトをファイルに保存します。
アプリの APK ファイルでスクリプトを実行します。
```
check_elf_alignment.sh APK_NAME.apk
```
このスクリプトは、すべての arm64-v8a 共有ライブラリに対して ALIGNED または UNALIGNED を出力します。
arm64-v8a または x86_64 共有ライブラリが UNALIGNED の場合は、これらのライブラリのパッケージを更新してから、アプリを再コンパイルし、このセクションの手順に沿って再テストする必要があります。

コマンドラインツールを直接使用する

コマンドラインツールを直接使用して ELF セグメントの配置を確認する手順は次のとおりです。

Android Studio の SDK Manager または sdkmanager コマンドラインツールを使用して、Android SDK Build-Tools バージョン 35.0.0 以降と Android NDK の両方がインストールされていることを確認します。

アプリの APK ファイルを展開します。

Linux または macOS

unzip APK_NAME.apk -d /tmp/my_apk_out

Windows（PowerShell）

Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out

APK ファイルを展開した一時ディレクトリで、lib ディレクトリの内容を確認して、共有オブジェクト（.so）ファイルがないか確認します。これは、APK Analyzer を使用してネイティブライブラリを特定する際に表示された共有オブジェクトファイルと同じです。共有オブジェクトファイルごとに次のコマンドを実行します。
Linux または macOS
```
SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
```
Windows（PowerShell）
```
SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
```
ここで、SDK_ROOT_LOCATION は Android SDK をインストールしたディレクトリのパス、SHARED_OBJECT_FILE はチェックする共有オブジェクトファイルの名前、NDK_VERSION はインストールした Android NDK のバージョン（28.0.12433566 など）です。出力は、チェックするファイルごとに次のようになります。
```
LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
```
出力行を確認して、負荷セグメントの値が 2**14 未満でないことを確認します。読み込みセグメントが 2**13、2**12、またはそれより低い値の場合は、該当するライブラリのパッケージを更新してから、アプリを再コンパイルし、このセクションの手順に沿って再テストする必要があります。
次に、アプリの APK ファイルで zipalign コマンドラインツールを実行します。
Linux または macOS
```
SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
```
Windows（PowerShell）
```
SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
```
ここで、SDK_ROOT_LOCATION は Android SDK をインストールしたディレクトリのパス、APK_NAME はアプリの APK ファイルの名前です。すべての共有ライブラリが正しく配置されている場合、出力の最後の行に「検証成功」と表示されます。

検証に失敗した場合は、一部の共有ライブラリを再調整する必要があります。そのため、それらのライブラリのパッケージを更新してから、アプリを再コンパイルし、このセクションの手順に沿って再テストする必要があります。

16 KB デバイスをサポートするアプリをビルドする

16 KB デバイスをサポートするには、ネイティブコードを使用するアプリで、以下のセクションで説明する手順を完了する必要があります。AGP バージョン 8.5.1 以降と NDK バージョン r28 以降にアップデートし、16 KB 互換のビルド済み依存関係を使用すると、アプリはデフォルトで 16 KB 互換になります。

共有ライブラリのパッケージを更新する

AGP バージョン 8.5.1 以降にアップグレードし、圧縮されていない共有ライブラリを使用することをおすすめします。

AGP バージョン 8.5.1 以降

16 KB デバイスでは、圧縮されていない共有ライブラリが付属するアプリを 16 KB の ZIP アライメント境界に配置する必要があります。これを行うには、Android Gradle プラグイン（AGP）バージョン 8.5.1 以降にアップグレードする必要があります。アップグレードプロセスの詳細については、Android Gradle プラグインの Upgrade Assistant セクションをご覧ください。

AGP バージョン 8.5 以前

AGP をバージョン 8.5.1 以降にアップグレードできない場合は、圧縮共有ライブラリの使用に切り替えることもできます。調整されていない共有ライブラリによるアプリのインストールに関する問題を回避するため、アプリをパッケージ化するときに Gradle が共有ライブラリを圧縮するように Gradle の構成を更新します。

Groovy

build.gradle ファイルに次のオプションを追加します。

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

Kotlin

build.gradle.kts ファイルに次のオプションを追加します。

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

16 KB ELF アライメントを使用してアプリをコンパイルする

16 KB デバイスでアプリを実行するには、共有ライブラリの ELF セグメントを 16 KB ELF アライメントを使用して適切にアライメントする必要があります。

16 KB ELF アライメントを使用してアプリをコンパイルするには、使用している Android NDK のバージョンに応じて、次のいずれかのセクションの手順を完了します。

Android NDK r28 以降

NDK バージョン r28 以降では、デフォルトで 16 KB アライメントでコンパイルされます。

Android NDK r27

Android NDK バージョン r27 以降で 16 KB アライメントの共有ライブラリのコンパイルをサポートするには、ndk-build、build.gradle、build.gradle.kts、またはリンカーフラグを次のように更新する必要があります。

ndk-build

Application.mk で次のように変更します。

APP_SUPPORT_FLEXIBLE_PAGE_SIZES := true

Groovy

build.gradle ファイルで、引数 -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON を設定します。

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments "-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON"
      }
    }
  }
}

Kotlin

build.gradle.kts ファイルで、引数 -DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON を設定します。

android {
  ...
  defaultConfig {
    ...
    // This block is different from the one you use to link Gradle
    // to your CMake or ndk-build script.
    externalNativeBuild {
      // For ndk-build, instead use the ndkBuild block.
      cmake {
        // Passes optional arguments to CMake.
        arguments += listOf("-DANDROID_SUPPORT_FLEXIBLE_PAGE_SIZES=ON")
      }
    }
  }
}

他のビルドシステム

次のリンカーフラグを指定します。

-Wl,-z,max-page-size=16384

Android NDK r26 以前

Android NDK バージョン r26 以前で 16 KB アライメントの共有ライブラリのコンパイルをサポートするには、次のように ndk-build または cmake の構成を更新する必要があります。

ndk-build

16 KB ELF アライメントを有効にするように Android.mk を更新します。

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

CMake

16 KB ELF アライメントを有効にするように CMakeLists.txt を更新します。

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

重要: アプリが NDK r26 以前の C++ 標準ライブラリ（libc++_shared.so）に動的にリンクする場合でも、その一部が 16 KB アライメントでない場合でも、ここで他のすべてのライブラリのアライメントを更新し、PAGE_SIZE に依存しないようにコードを更新する必要があります。16 KB デバイスでそれらの古いバージョンの NDK をテストするために、LTS NDK バージョン r23 と r25 のカナリアリリースが、16 KB アライメントの libc++_shared.so ライブラリとともに Android CI で利用できます。いずれにしても、Android NDK r27 以降に移行して、16 KB ELF アライメントバージョンの C++ 標準ライブラリに更新することをおすすめします。そうでない場合、16 KB デバイスにアプリをインストールできなくなります。

新しい Android NDK に移行できない場合は、アプリを更新して C++ 標準ライブラリを共有ライブラリに静的にコンパイルできる場合があります。C++ 標準ライブラリに静的にリンクする方法については、C++ ライブラリサポートのセクションを参照してください。また、重要な考慮事項のセクションも必ずご覧ください。

特定のページサイズを参照するコードインスタンスを確認する

アプリが 16 KB アライメントであっても、コード内の特定の場所がデバイスが特定のページサイズを使用していると想定している場合、アプリでエラーが発生する可能性があります。これを回避するには、次の手順を完了します。

デバイスのページサイズが 4 KB（4096）であることを前提とするコードロジック内の PAGE_SIZE 定数またはインスタンスを参照するハードコードされた依存関係をすべて削除します。

代わりに getpagesize() または sysconf(_SC_PAGESIZE) を使用してください。
ページ境界に合わせた引数を必要とする mmap() などの API の使用箇所を探し、必要に応じて代替手段に置き換えます。

アプリで PAGE_SIZE を基盤となるページサイズに関連付けられていない便利な値として使用している場合、16 KB モードで使用してもアプリが破損することはありません。ただし、この値が MAP_FIXED なしで mmap でカーネルに渡されると、カーネルはページ全体を使用するため、メモリが浪費されます。このような理由から、NDK r27 以降で 16 KB モードが有効になっている場合、PAGE_SIZE は未定義になります。

アプリがこのように PAGE_SIZE を使用していて、この値をカーネルに直接渡さない場合は、PAGE_SIZE を使用する代わりに、新しい名前の新しい変数を作成して、他の目的で使用され、実際のメモリページを反映していないことを示します。

SDK で 16 KB のサポートを確認する

多くの SDK は 16 KB のページサイズに対応しています（特に、自分でビルドする場合や最新のビルド済みファイルを入手する場合）。ただし、一部の SDK ビルド済みまたは SDK バージョンは 16 KB に対応していないため、16 KB で使用するバージョンを判断するには、各 SDK プロバイダのウェブサイトを確認する必要があります。

16 KB 環境でアプリをテストする

16 KB デバイスをサポートするようにアプリをビルドしたら、16 KB 環境でアプリをテストして、アプリにリグレッションが発生していないか確認します。手順は次のとおりです。

Android 15 SDK をセットアップする。
次のいずれかのテスト環境を設定します。
テストデバイスを起動して、次のコマンドを実行し、16 KB 環境を使用していることを確認します。
```
adb shell getconf PAGE_SIZE
```
このコマンドは 16384 の値を返します。
次の zipalign コマンドを実行して、アプリが 16 KB でアライメントされていることを確認します。ここで、APK_NAME はアプリの APK ファイルの名前です。
```
zipalign -c -P 16 -v 4 APK_NAME.apk
```
特定のページサイズを参照するコードインスタンスの変更によって影響を受ける可能性がある領域に重点を置いて、アプリを徹底的にテストします。

16 KB ベースの Android 15 システムイメージを使用して Android Emulator を設定する

Android Emulator を使用して 16 KB 環境をセットアップする手順は次のとおりです。

16 KB ベースの Android 15 エミュレータシステムイメージは、Android Studio Jellyfish | 2023.3.1 以降と互換性があります。ただし、Android 15 ベータ版を利用する場合は、Android Studio の最新のプレビュー版をダウンロードすることをおすすめします。

なお、Android Studio は複数のバージョンを一緒にインストールできるので、Android Studio の既存のバージョンをインストールしたままにしておくことができます。
Android Studio で [Tools] > [SDK Manager] をクリックします。
[SDK Platforms] タブで [Show Package Details] をオンにして、[Android VanillaIceCream Preview] セクションを開き、作成する仮想デバイスに応じて、次のいずれかまたは両方のエミュレータシステムイメージを選択します。
- Google APIs 試験運用版 16 KB ページサイズ ARM 64 v8a システムイメージ
- Google APIs 試験運用版 16k ページサイズ Intel x86_64 Atom システムイメージ
注: サポートされている Google Pixel デバイスをエミュレートする場合は、ARM 64 v8a システムイメージのみが必要です。
[適用] > [OK] をクリックして、選択したシステムイメージをダウンロードします。
手順に沿って Android 15 の仮想デバイスをセットアップし、システムイメージを選択するよう求められたら、ダウンロードした 16 KB のシステムイメージを選択します。自動的に推奨されない場合は、[その他の画像] タブで 16 KB のシステムイメージを確認できます。

デバイスマネージャーで、16 KB の画像の横にある 3 つの点をクリックし、[ディスクに表示] をクリックします。
このフォルダで config.ini ファイルを探します。
config.ini ファイルに次の行を追加して、変更を保存します。
```
kernel.parameters = androidboot.page_shift=14
```
変更を確認するには、次のコマンドを実行します。16384 が返されます。
```
adb shell getconf PAGE_SIZE
```

開発者向けオプションを使用してデバイスで 16 KB モードを有効にする

[16 KB ページサイズで起動] デベロッパーを切り替えオプションでデバイスを 16 KB モードで起動できます。

Android 15 QPR1 以降では、次のことができます。開発者向けオプションを使用する 16 KB モードで起動し、オンデバイステストを実施する。

この開発者向けオプションは、以下のデバイスで利用できます。

Google Pixel 8、Google Pixel 8 Pro（Android 15 QPR1 ベータ版 1 以降を搭載）

64 ビットのサポート

16 KB ページサイズのサポート

メリットとパフォーマンスの向上

アプリが影響を受けるかどうかを確認する

アプリがネイティブ コードを使用しているか？

APK Analyzer を使用してネイティブ ライブラリを特定する

共有ライブラリの ELF セグメントのアライメントを確認する

check_elf_alignment.sh スクリプトを使用する（Linux または macOS）

コマンドライン ツールを直接使用する

Linux または macOS

Windows（PowerShell）

Linux または macOS

Windows（PowerShell）

Linux または macOS

Windows（PowerShell）

16 KB デバイスをサポートするアプリをビルドする

共有ライブラリのパッケージを更新する

AGP バージョン 8.5.1 以降

AGP バージョン 8.5 以前

Groovy

Kotlin

16 KB ELF アライメントを使用してアプリをコンパイルする

Android NDK r28 以降

Android NDK r27

ndk-build

Groovy

Kotlin

他のビルドシステム

Android NDK r26 以前

ndk-build

CMake

特定のページサイズを参照するコード インスタンスを確認する

SDK で 16 KB のサポートを確認する

16 KB 環境でアプリをテストする

16 KB ベースの Android 15 システム イメージを使用して Android Emulator を設定する

開発者向けオプションを使用してデバイスで 16 KB モードを有効にする

アプリがネイティブコードを使用しているか？

APK Analyzer を使用してネイティブライブラリを特定する

コマンドラインツールを直接使用する

特定のページサイズを参照するコードインスタンスを確認する

16 KB ベースの Android 15 システムイメージを使用して Android Emulator を設定する