ART を設定する

このページでは、Android ランタイム（ART）とそのコンパイル オプションを設定する方法について説明します。ここで扱うトピックは、システム イメージの事前コンパイルの構成、dex2oat のコンパイル オプション、システム パーティションおよびデータ パーティションの容量とパフォーマンスをトレードオフする方法などです。

ART の操作については、ART と Dalvik、および Dalvik 実行可能ファイルの形式をご覧ください。アプリが正しく動作することを確認するには、Android ランタイム（ART）でのアプリの動作確認をご覧ください。

ART の仕組み

ART では、事前（AOT）コンパイルを使用し、Android 7 以降では AOT コンパイル、ジャストインタイム（JIT）コンパイル、インタプリタを組み合わせて使用します。AOT コンパイルは、プロファイル ガイド付きコンパイルとすることも可能です。これらすべての実行モードの組み合わせは構成可能です。以下のセクションではそれについて説明します。たとえば、Google Pixel デバイスの場合は、以下のフローで動作するように構成されています。

1. アプリは最初に、Google Play ストアから配信されるメタデータ（.dm）ファイルとともにインストールされます。このファイルには、クラウド プロファイルが含まれています。このクラウド プロファイルに記載されているメソッドが AOT コンパイルされます。アプリが dex メタデータ ファイルなしでインストールされている場合、AOT コンパイルは行われません。
2. 最初の数回の実行では、AOT コンパイルされていないメソッドは、インタプリタで実行されます。インタプリタで実行されたメソッドのうち、実行される頻度の高いメソッドが JIT コンパイルされます。実行に基づいてローカル プロファイルが生成され、クラウド プロファイルがあれば、それと結合されます。
3. デバイスがアイドル状態で充電中のときに、コンパイル デーモンが実行され、最初の数回の実行時に生成され、結合されたプロファイルに基づいてアプリが再度コンパイルされます。
4. このコンパイル デーモンで生成されたアーティファクトは、その後のアプリの実行で使用されます。このアーティファクトには、生成済みのコードよりも AOT コンパイルが進んだコードが含まれます。AOT コンパイルされていないコードは、インタプリタで実行されるか、JIT コンパイルされます。この実行に基づいて、プロファイルのインストール状態が更新されます。その後のコンパイル デーモンの実行では、このプロファイルが選択されます。

ART は、コンパイラ（dex2oat ツール）と、起動時に読み込まれるランタイム（libart.so）で構成されます。dex2oat ツールは APK ファイルを受け取り、ランタイムが読み込む 1 つ以上のコンパイル アーティファクト ファイルを生成します。ファイルの数や拡張子、名前はリリースによって異なる場合がありますが、Android 8 以降のリリースの場合、以下のファイルが生成されます。

• .vdex: 検証を高速化するための追加のメタデータを含みます。APK の非圧縮 DEX コードが付加されていることもあります。
• .odex: APK 内のメソッドの AOT コンパイル済みコードを含みます。
• .art (optional): アプリの起動を高速化するために使用される、APK にリストされた文字列とクラスの ART 内部表現を格納します。

コンパイル オプション

ART のコンパイル オプションには 2 つのカテゴリがあります。

1. システム ROM 構成: システム イメージのビルド時にどのコードを AOT コンパイルするか。
2. 実行時構成: ART がデバイス上でアプリをどのようにコンパイルして実行するか。

コンパイラ フィルタ

上記の 2 つのカテゴリを構成するコア ART オプションの一つは、コンパイラ フィルタです。コンパイラ フィルタは ART が DEX コードをコンパイルする方法を制御するオプションであり、dex2oat ツールに渡されます。Android 8 以降、4 つのフィルタが公式にサポートされています。

• verify: DEX コードの検証だけを実行します（AOT コンパイルは行いません）。
• quicken: （Android 11 まで）DEX コードの検証を実行し、DEX 命令の一部を最適化してインタプリタのパフォーマンスを向上させます。
• speed: DEX コードの検証を実行し、すべてのメソッドを AOT コンパイルします。
• speed-profile: DEX コードの検証を実行し、プロファイル ファイルにリストされているメソッドを AOT コンパイルします。

システム ROM 構成

プリインストールのライブラリとアプリは、システム イメージのビルド時に AOT コンパイルされます。このプロセスを dexpreopt と呼びます。このようなコンパイルされたファイル（特にブート クラスパス）は、すべての依存関係が変更されない限り、使用できます。

注: デバイスにシステム モジュールのアップデートが適用された場合、ブート クラスパスが次のアップデートで変更される可能性が高く、この場合、すべて dexpreopt ファイルが古くなり、使用できなくなります。

dexpreopt の構成に使用できる ART ビルド オプションは多数あります。これらのオプションを構成する方法は、システム イメージの使用可能な保存容量と、プリインストールされたアプリの数に応じて決まります。システム ROM にコンパイルされる JAR / APK は、以下の 4 つのカテゴリに分けられます。

• ブート クラスパス コード: デフォルトでは、speed-profile コンパイラ フィルタでコンパイルされます。
• システム サーバーコード（このドキュメントの後半の PRODUCT_SYSTEM_SERVER_JARS、PRODUCT_APEX_SYSTEM_SERVER_JARS、PRODUCT_STANDALONE_SYSTEM_SERVER_JARS、PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS を参照）:
  • （Android 14 以降）デフォルトでは、speed-profile コンパイラ フィルタでコンパイルされます。プロファイルが指定されていない場合は、speed コンパイラ フィルタでコンパイルされます。
  • （Android 13 まで）デフォルトでは、speed コンパイラ フィルタでコンパイルされます。
  PRODUCT_SYSTEM_SERVER_COMPILER_FILTER で構成できます（このドキュメントの後半を参照）。
• プロダクト固有のコアアプリ（このドキュメントの後半の PRODUCT_DEXPREOPT_SPEED_APPS を参照）: デフォルトでは、speed コンパイラ フィルタでコンパイルされます。
• 他のすべてのアプリ: デフォルトでは、speed-profile コンパイラ フィルタでコンパイルされます。プロファイルが指定されていない場合は、verify コンパイラ フィルタでコンパイルされます。

  PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER で構成できます（このドキュメントの後半を参照）。

メイクファイル オプション

• WITH_DEXPREOPT

dex2oat がシステム イメージにインストールされた DEX コードで呼び出されるかどうか。デフォルトで有効。

• DONT_DEXPREOPT_PREBUILTS（Android 5 以降）

DONT_DEXPREOPT_PREBUILTS を有効にすると、事前ビルド済みアプリの dexpreopt を回避できます。そのようなアプリには、Android.mk に include $(BUILD_PREBUILT) が指定されているアプリがあります。Google Play でアップデートされる可能性がある事前ビルド済みアプリの dexpreopt をスキップすると、システム イメージの容量は節約されますが、初回の起動時間が長くなります。このオプションは、Android.bp で定義された事前ビルド済みアプリには効果を持ちません。

• PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER（Android 9 以降）

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER は、dexpreopt 済みアプリのデフォルトのコンパイラ フィルタを指定します。そのようなアプリは、Android.bp で定義されているか、Android.mk に include $(BUILD_PREBUILT) が指定されています。コンパイラ フィルタを指定しないと、デフォルト値は speed-profile になります。値が指定されず、プロファイルが指定されていない場合は、verify になります。

• WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY （Android 8 MR1 以降）

WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY を有効にすると、ブート クラスパスとシステム サーバーの JAR だけに dexpreopt が行われます。

• LOCAL_DEX_PREOPT

モジュール定義内で LOCAL_DEX_PREOPT オプションを指定することにより、個別のアプリ単位で dexpreopt を有効 / 無効にすることもできます。これは、Google Play のアップデートによりシステム イメージ内の dexpreopt 済みコードが古くなる場合に備えて、アップデートを即座に受信する可能性があるアプリの dexpreopt を無効にするのに有用な場合があります。また、データ パーティションに新しいバージョンのアプリがすでに存在する場合は、メジャー バージョン アップグレード OTA の容量を節約するためにも役立ちます。

LOCAL_DEX_PREOPT では、true または false の値を使用して dexpreopt を有効または無効にできます。また、dexpreopt で APK または JAR ファイルから classes.dex ファイルを除去すべきでない場合は、nostripping を指定できます。通常、このファイルは dexpreopt 後に不要になるため削除されます。サードパーティ APK 署名を有効なまま残すには、この nostripping オプションを指定する必要があります。

• PRODUCT_DEX_PREOPT_BOOT_FLAGS

ブートイメージをコンパイルする方法を制御するオプションを dex2oat に渡します。これにより、カスタマイズ済みイメージクラス リスト、コンパイル済みクラスリスト、コンパイラ フィルタを指定できます。

• PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

ブートイメージ以外のすべてをコンパイルする方法を制御するオプションを dex2oat に渡します。

• PRODUCT_DEX_PREOPT_MODULE_CONFIGS

特定のモジュールとプロダクト構成を対象とする dex2oat オプションを渡す機能を提供します。これは、プロダクトの device.mk ファイルで $(call add-product-dex-preopt-module-config,<modules>,<option>) により設定されます。<modules> は、JAR ファイルでは LOCAL_MODULE、APK ファイルでは LOCAL_PACKAGE の名前のリストです。

• PRODUCT_DEXPREOPT_SPEED_APPS（Android 8 以降）

プロダクトのコアとして識別され、speed コンパイラ フィルタでコンパイルすることが望ましいアプリのリスト。たとえば、SystemUI などの永続アプリがプロファイル ガイド付きコンパイルを使用できるのは次回のリブート時に限られます。したがって、プロダクトではそのようなアプリが常に AOT コンパイルされるようにする方が適切な場合があります。

• PRODUCT_SYSTEM_SERVER_APPS（Android 8 以降）

システム サーバーによって読み込まれるアプリのリスト。デフォルトでは、これらのアプリは speed コンパイラ フィルタでコンパイルされます。

• PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD（Android 8 以降）

ART のデバッグ バージョンをデバイス上に配置するかどうか。デフォルトでは、userdebug および eng ビルドに対して有効になっています。この動作は、オプションを true または false に明示的に設定することでオーバーライドできます。

デフォルトでは、デバイスは非デバッグ バージョン（libart.so）を使用します。デバッグ バージョンに切り替えるには、システム プロパティ persist.sys.dalvik.vm.lib.2 を libartd.so に設定します。

• WITH_DEXPREOPT_PIC（Android 7 まで）

Android 5.1.0 から Android 6.0.1 までのリリースの場合、WITH_DEXPREOPT_PIC を指定することで、位置独立コード（PIC）を有効化できます。これにより、イメージからコンパイルされたコードを /system から /data/dalvik-cache に再配置する必要がなくなり、データ パーティションの容量を節約できます。ただし、位置依存コードを利用する最適化が無効化されるため、実行時の影響がわずかにあります。一般的に、/data 内の容量の節約が求められるデバイスでは、PIC コンパイルを有効にしてください。

Android 7.0 で、PIC コンパイルはデフォルトで有効化されるようになりました。

• WITH_DEXPREOPT_BOOT_IMG_ONLY（Android 7 MR1 まで）

このオプションは、WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY（システム サーバー JAR の事前最適化も行います）に置き換えられました。

• PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

このオプションは、システム サーバーのコンパイラ フィルタを指定します。

• （Android 14 以降）指定していない場合、speed-profile コンパイラ フィルタが使用されます。プロファイルが指定されていない場合は、speed コンパイラ フィルタが使用されます。
• （Android 13 まで）指定していない場合、speed コンパイラ フィルタが使用されます。
• speed に設定すると、speed コンパイラ フィルタが使用されます。
• speed-profile に設定すると、speed-profile コンパイラ フィルタが使用されます。プロファイルが指定されていない場合は、verify コンパイラ フィルタが使用されます。
• verify に設定すると、verify コンパイラ フィルタが使用されます。
• PRODUCT_SYSTEM_SERVER_JARS、PRODUCT_APEX_SYSTEM_SERVER_JARS、PRODUCT_STANDALONE_SYSTEM_SERVER_JARS、PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

以下は、システム サーバーによって読み込まれる JAR のリストです。JAR は、PRODUCT_SYSTEM_SERVER_COMPILER_FILTER で指定されたコンパイラ フィルタでコンパイルされます。

• （必須）PRODUCT_SYSTEM_SERVER_JARS: プラットフォーム上のシステム サーバー クラスパス JAR のリスト（SYSTEMSERVERCLASSPATH の一部）。システム サーバー クラスパス JAR をこのリストに追加する必要があります。リストにシステム サーバー クラスパス JAR を追加しないと、それらの JAR が読み込まれなくなります。
• （必須）PRODUCT_APEX_SYSTEM_SERVER_JARS: APEX を介して配信されたシステム サーバー クラスパス JAR のリスト（SYSTEMSERVERCLASSPATH の一部）。形式は <apex name>:<jar name> です。APEX システム サーバー クラスパス JAR をこのリストに追加する必要があります。このリストに APEX システム サーバー クラスパス JAR を追加しないと、それらの JAR が読み込まれなくなります。
• （省略可、Android 13 まで）PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: システム サーバーが個別のクラスローダーを使用して動的に読み込む JAR のリスト（SystemServiceManager.startServiceFromJar を使用）。このリストへのスタンドアロン システム サーバー JAR の追加は必須ではありませんが、JAR がコンパイルされ、ランタイム パフォーマンスが良好になるため、強く推奨されます。
• （必須、Android 13 以降）PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: システム サーバーが個別のクラスローダーを使用して動的に読み込む APEX で配信される JAR のリスト（SystemServiceManager.startServiceFromJar を介するか、<apex-system-service> として宣言されます）。形式は <apex name>:<jar name> です。スタンドアロン APEX システム サーバー JAR をこのリストに追加する必要があります。このリストにスタンドアロン APEX システム サーバー JAR を追加しないと、起動エラーが発生します。

ブート クラスパス構成

プリロード済みクラスリストは、起動時に Zygote が初期化するクラスのリストです。これにより、各アプリでクラス初期化子を個別に実行する必要がなくなり、初期化子の起動の高速化とメモリ内でのページの共有が可能になります。プリロード済みクラスリスト ファイルは、デフォルトでは frameworks/base/config/preloaded-classes にあり、一般的なスマートフォンで使用できるようにチューニングされたリストを含んでいます。ウェアラブル デバイスなどの他のデバイスではこれと異なる場合があり、それに応じてチューニングする必要があります。あまりにも多くのクラスを追加すると、使用されないクラスを読み込む際にメモリが浪費されるため、慎重にチューニングする必要があります。追加するクラスが少なすぎると、各アプリがそれ自身のコピーを持つことが必要になり、この場合もメモリが浪費されます。

使用例（プロダクトの device.mk 内）:

PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

注: デフォルトを build/target/product/base.mk から取得するプロダクト構成 Makefile を継承する前に、この行を挿入してください。

実行時構成

JIT オプション

以下のオプションは、ART JIT コンパイラが利用できる場合に限り、Android リリースに影響します。

• dalvik.vm.usejit: JIT を有効にするかどうか。
• dalvik.vm.jitinitialsize（デフォルトは 64K）: コード キャッシュの初期容量。コード キャッシュは定期的に GC が行われ、必要に応じて増加します。
• dalvik.vm.jitmaxsize（デフォルトは 64M）: コード キャッシュの最大容量。
• dalvik.vm.jitthreshold（デフォルトは 10000）: メソッドを JIT コンパイルするためにメソッドの「ホットネス」カウンタが渡さなければならないしきい値。「ホットネス」カウンタはランタイム内部の指標です。呼び出しの数や後方ブランチなどの要素を含みます。
• dalvik.vm.usejitprofiles（Android 13 まで）: JIT プロファイルが有効になっているかどうか。このオプションは dalvik.vm.usejit が false であっても使用できます。false の場合、コンパイラ フィルタ speed-profile はメソッドを AOT コンパイルせず、verify と同じになります。Android 14 以降、JIT プロファイルは常に有効であり、オフにはできません。
• dalvik.vm.jitprithreadweight（デフォルトは dalvik.vm.jitthreshold / 20）: アプリの UI スレッドの JIT「サンプル」の重み付け（jitthreshold を参照）。アプリを操作する際のユーザー エクスペリエンスに直接影響するメソッドのコンパイルを高速化するために使用します。
• dalvik.vm.jittransitionweight（デフォルトは dalvik.vm.jitthreshold/ 10）: コンパイル コードとインタプリタ間を遷移するメソッド呼び出しの重み付け。高コストの遷移を最小限に抑えるため、関係するメソッドだけをコンパイルすることができます。

dex2oat オプション

これらのオプションはオンデバイス コンパイル（別名 dexopt）に影響を与え、また一部は dexpreopt にも影響しますが、システム ROM 構成で説明したオプションは dexpreopt にのみ影響します。

リソース使用量を制御するオプション:

• dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set（Android 11 まで）: ブートイメージに使用されるスレッド数と CPU コアのセット（後述）。
• dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
  • （Android 11 まで）起動時にブートイメージ以外のすべてに使用されるスレッド数と CPU コアのセット（後述）。
  • （Android 12 以降）起動時にブートイメージを含めたすべてのものに使用されるスレッド数と CPU コアのセット（後述）。
    • 特に Android 14 以降では、ART サービスの優先度分類 PRIORITY_BOOT に対応します。
• dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
  • （Android 11 から Android 13 まで）クラウド バックアップからの復元に使用されるスレッド数と CPU コアのセット（後述）。
  • （Android 14 以降）クラウド バックアップからの復元も含め、通常よりもレイテンシの影響が大きいものすべてに使用されるスレッド数と CPU コアのセット（後述）。
    • 特に ART サービスの優先度分類 PRIORITY_INTERACTIVE_FAST に対応します。
• dalvik.vm.background-dex2oat-threads/dalvik.vm.background-dex2oat-cpu-set（Android 14 以降）: バックグラウンドで使用するスレッド数と CPU コアのセット（後述）。
  • 特に ART サービスの優先度分類 PRIORITY_BACKGROUND に対応します。
• dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: 他のすべてに使用されるスレッド数と CPU コアのセット。

CPU コアのセットは、カンマ区切りの CPU ID リストで指定します。たとえば、CPU コア 0～3 で dex2oat を実行する場合は、次のように設定します。

dalvik.vm.dex2oat-cpu-set=0,1,2,3

CPU アフィニティ プロパティを設定する場合、不要なメモリ競合や I/O 競合を避けるため、選択した CPU 数に一致するように、dex2oat スレッド数に対応するプロパティをマッチングすることをおすすめします。

dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

システム プロパティ以外にも、タスク プロパティを使用しても dex2oat のリソース使用量を制御することができます（cgroup 抽象化レイヤを参照）。

以下のタスク プロファイルがサポートされています。

• Dex2OatBackground（Android 14 以降）（デフォルトで Dex2OatBootComplete を継承）: バックグラウンドで使用されるリソースを制御します。
  • 特に ART サービスの優先度分類 PRIORITY_BACKGROUND に対応します。
• Dex2OatBootComplete:
  • （Android 13 まで）起動後のすべてに使用されるリソースを制御します。
  • （Android 14 以降）起動後かつバックグラウンド以外のすべてに使用されるリソースを制御します。
    • 特に ART サービスの優先度分類の PRIORITY_INTERACTIVE_FAST と PRIORITY_INTERACTIVE に対応します。

システム プロパティとタスク プロパティの両方が指定された場合、どちらも有効になります。

以下は、ヒープサイズを制御するオプションです。

• dalvik.vm.image-dex2oat-Xms: ブートイメージの初期ヒープサイズ。
• dalvik.vm.image-dex2oat-Xmx: ブートイメージの最大ヒープサイズ。
• dalvik.vm.dex2oat-Xms: その他すべての初期ヒープサイズ。
• dalvik.vm.dex2oat-Xmx: その他すべての最大ヒープサイズ。

dex2oat の初期ヒープサイズと最大ヒープサイズを制御するオプションには、小さい値を指定しないでください。コンパイルできるアプリが制限される可能性があります。

以下は、コンパイル フィルタを制御するオプションです。

• dalvik.vm.image-dex2oat-filter（Android 11）: ブートイメージ用のコンパイル フィルタ。Android 12 以降、ブートイメージ用のコンパイル フィルタは常に speed-profile であり、変更はできません。
• dalvik.vm.systemservercompilerfilter（Android 13 以降）: システム サーバー用のコンパイル フィルタ。PRODUCT_SYSTEM_SERVER_COMPILER_FILTER を参照。
• dalvik.vm.systemuicompilerfilter（Android 13 以降）: システム UI パッケージ用のコンパイル フィルタ。
• dalvik.vm.dex2oat-filter（Android 6 まで）: その他すべてに使用されるコンパイル フィルタ。
• pm.dexopt.<reason>（Android 7 以降）: その他すべてに使用されるコンパイル フィルタ。Android 14 以降の場合は、ART サービス構成を参照してください。Android 13 以前の場合は、パッケージ管理システムの構成を参照してください。

ブートイメージ以外のすべてのコンパイルを制御するその他のオプションは、以下のとおりです。

• dalvik.vm.dex2oat-very-large（Android 7.1 以降）: AOT コンパイルを無効化する最小合計 dex ファイルサイズ（バイト単位）
• dalvik.vm.dex2oat-swap（Android 7.1 以降）（デフォルトは true）: dex2oat にスワップ ファイルを使用することを許可します。この設定をすると、メモリ不足によるクラッシュを防ぐことができます。このオプションがオンの場合でも、dex2oat にスワップ ファイルが使用されるのは、dex ファイルの多いなどの一部の場合のみです。また、この条件は変更される可能性があります。
• dalvik.vm.ps-min-first-save-ms（Android 12 以降）: アプリの初回起動時にランタイムによってアプリのプロファイルが生成されるまでの最小待機時間。
• dalvik.vm.ps-min-save-period-ms（Android 12 以降）: アプリのプロファイルを更新するまでの最小待機時間。
• dalvik.vm.dex2oat64.enabled（Android 11 以降）（デフォルトは false）: 64 ビット版の dex2oat を使用するかどうか。
• dalvik.vm.bgdexopt.new-classes-percent（Android 12 以降）（デフォルトは 20）: プロファイル中の新規クラスのうち、再コンパイルがトリガーされるクラスの割合（0 から 100 まで）。プロファイル ガイド付きコンパイルにのみ（speed-profile）、通常はバックグラウンド dexopt の間に適用されます。なお、この割合のしきい値に加えて、新規クラス最低 50 個のというしきい値もあり、これは変更できません。
• dalvik.vm.bgdexopt.new-methods-percent（Android 12 以降）（デフォルトは 20）: プロファイル中の新規メソッドのうち、再コンパイルがトリガーされるメソッドの割合（0 から 100 まで）。プロファイル ガイド付きコンパイルにのみ（speed-profile）、通常はバックグラウンド dexopt の間に適用されます。なお、この割合のしきい値に加えて、新規メソッド最低 100 個のというしきい値もあり、これは変更できません。
• dalvik.vm.dex2oat-max-image-block-size（Android 10 以降）（デフォルトは 524288） 圧縮イメージの最大ソリッド ブロック サイズ。大きなイメージは、すべてのブロックが最大サイズを超えないように、一連のソリッド ブロックに分割されます。
• dalvik.vm.dex2oat-resolve-startup-strings（Android 10 以降）（デフォルトは true） true の場合、プロファイルで "startup" とマークされているメソッドから参照される定数文字列すべてが dex2oat で解決されます。
• debug.generate-debug-info（デフォルトは false） スタック巻き戻し情報、ELF シンボル、dwarf セクションなどのネイティブ デバッグ用のデバッグ情報を生成するかどうか。
• dalvik.vm.dex2oat-minidebuginfo（Android 9 以降）（デフォルトは true） バックトレースの出力に必要な最小量の LZMA 圧縮済みデバッグ情報を生成するかどうか。

ART サービスのオプション

Android 14 以降では、アプリのオンデバイス AOT コンパイル（別名 dexopt）は ART サービスが処理します。ART サービスの構成について詳しくは、ART サービス構成をご覧ください。

パッケージ マネージャーのオプション

Android 14 より前では、アプリのオンデバイス AOT コンパイル（別名 dexopt）はパッケージ管理システムが処理します。dexopt に関するパッケージ管理システムの設定については、パッケージ管理システムの構成を参照してください。

A/B 固有の構成

ROM 構成

Android 7.0 以降では、デバイスで 2 つのシステム パーティションを使用して A/B システム アップデートを有効にできます。システム パーティション サイズを節約するため、使用していない第 2 のシステム パーティションに事前最適化済みファイルをインストールできます。それらのファイルは、初回起動時にデータ パーティションにコピーされます。

使用例（device-common.mk 内）:

PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

デバイスの BoardConfig.mk 内:

BOARD_USES_SYSTEM_OTHER_ODEX := true

ブート クラスパス コード、システム サーバーコード、プロダクト固有のコアアプリは常にシステム パーティションにコンパイルされます。デフォルトでは、他のすべてのアプリは、使用されていない第 2 のシステム パーティションにコンパイルされます。これは SYSTEM_OTHER_ODEX_FILTER で制御できます。そのデフォルト値は次のとおりです。

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

バックグラウンド OTA dexopt

A/B 対応デバイスでは、新しいシステム イメージで再起動する前に、アプリをバックグラウンドでコンパイルできます。オプションとして、コンパイル スクリプトおよびバイナリをシステム イメージに組み込むことができます。バックグラウンドでのアプリのコンパイルをご覧ください。このコンパイルに使用されるコンパイル フィルタは、次のように制御されます。

pm.dexopt.ab-ota=speed-profile

プロファイル ガイド付きコンパイルを利用してストレージの容量を節約するため、speed-profile を使用することをおすすめします。

JDWP オプション

userdebug ビルドでの Java Debug Wire Protocol（JDWP）スレッドの作成は、persist.debug.dalvik.vm.jdwp.enabled システム プロパティで制御されます。デフォルトでは、このプロパティは設定されず、JDWP スレッドはデバッグ可能なアプリでのみ作成されます。JDWP スレッドをデバッグ可能なアプリとデバッグ不可能なアプリの両方で有効にするには、persist.debug.dalvik.vm.jdwp.enabled を 1 に設定します。プロパティの変更を有効にするには、デバイスの再起動が必要です。

userdebug ビルドでデバッグ不可能なアプリをデバッグするには、次のコマンドを実行して JDWP を有効にします。

  adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
  

注: persist.debug.dalvik.vm.jdwp.enabled プロパティを 1 に設定しても、アプリはデバッグ可能にはなりません。デバッガをプロセスにアタッチできるようになるだけです。
Android 13 以前を搭載しているデバイスの場合、ランタイムが userdebug ビルドでデバッグ可能なアプリとデバッグ不可能なアプリの JDWP スレッドを作成します。つまり、userdebug ビルドでデバッガをアタッチしたり、アプリをプロファイルすることが可能です。