Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

ART konfigurieren

Auf dieser Seite wird beschrieben, wie Sie die Android Runtime (ART) und ihre Kompilierungsoptionen konfigurieren. Zu den hier behandelten Themen gehören die Konfiguration der Vorkompilierung des System-Images, dex2oatKompilierungsoptionen und die Abwägung zwischen Systempartitionsspeicherplatz, Datenpartitionsspeicherplatz und Leistung.

Weitere Informationen zur Arbeit mit ART finden Sie unter ART und Dalvik und Dalvik-Ausführformat. Lesen Sie den Hilfeartikel App-Verhalten in Android Runtime (ART) überprüfen, um sicherzustellen, dass Ihre Apps ordnungsgemäß funktionieren.

Funktionsweise von ART

ART verwendet die Ahead-of-Time-Kompilierung (AOT). Ab Android 7 wird eine hybride Kombination aus AOT-Kompilierung, JIT-Kompilierung (Just-in-Time) und Interpretation verwendet. Die AOT-Kompilierung kann profilbasiert erfolgen. Die Kombination all dieser Ausführungsmodi ist konfigurierbar und wird in diesem Abschnitt erläutert. Pixel-Geräte sind beispielsweise so konfiguriert, dass sie mit dem folgenden Ablauf funktionieren:

Eine Anwendung wird zuerst mit einer vom Play Store bereitgestellten Dex-Metadatendatei (.dm) installiert, die ein Cloud-Profil enthält. ART kompiliert die im Cloud-Profil aufgeführten Methoden AOT. Wenn die Anwendung ohne DEX-Metadatendatei installiert wird, erfolgt keine AOT-Kompilierung.
Bei den ersten paar Malen, wenn die Anwendung ausgeführt wird, werden Methoden, die nicht AOT-kompiliert sind, interpretiert. Unter den interpretierten Methoden werden diejenigen, die häufig ausgeführt werden, dann JIT-kompiliert. ART generiert anhand der Ausführung ein lokales Profil und kombiniert es mit dem Cloud-Profil (falls vorhanden).
Wenn das Gerät inaktiv ist und geladen wird, wird ein Kompilierungs-Daemon ausgeführt, um die Anwendung anhand des kombinierten Profils neu zu kompilieren, das bei den ersten paar Ausführungen generiert wurde.
Bei den nachfolgenden Ausführungen der Anwendung verwendet ART die vom Kompilierungsdaemon generierten Artefakte, die im Vergleich zu denjenigen, die während der ersten Ausführung generiert wurden, mehr AOT-kompilierten Code enthalten. Methoden, die nicht AOT-kompiliert sind, werden weiterhin interpretiert oder JIT-kompiliert. ART aktualisiert die Profilinstallation basierend auf der Ausführung und das Profil wird dann von nachfolgenden Ausführungen des Kompilierungsdaemons übernommen.

ART besteht aus einem Compiler (dem dex2oat-Tool) und einer Laufzeit (libart.so), die beim Starten geladen wird. Das dex2oat-Tool nimmt eine APK-Datei und generiert eine oder mehrere Dateien mit Kompilierungsartefakten, die von der Laufzeit geladen werden. Die Anzahl der Dateien, ihre Erweiterungen und Namen können sich von Release zu Release ändern. Seit der Veröffentlichung von Android 8 werden jedoch die folgenden Dateien generiert:

.vdex: Enthält einige zusätzliche Metadaten, um die Überprüfung zu beschleunigen, manchmal zusammen mit dem unkomprimierten DEX-Code des APK.
.odex: Enthält AOT-kompilierten Code für Methoden im APK.
.art (optional) enthält interne ART-Darstellungen einiger Strings und Klassen, die im APK aufgeführt sind, um das Starten der App zu beschleunigen.

Kompilierungsoptionen

Es gibt zwei Kategorien von Kompilierungsoptionen für ART:

System-ROM-Konfiguration: Welcher Code wird beim Erstellen eines System-Images AOT-kompiliert?
Laufzeitkonfiguration: Beschreibt, wie ART Apps auf einem Gerät kompiliert und ausführt.

Compilerfilter

Eine wichtige ART-Option zum Konfigurieren dieser beiden Kategorien sind Compilerfilter. Compilerfilter steuern, wie ART DEX-Code kompiliert. Sie sind eine Option, die an das dex2oat-Tool übergeben wird. Ab Android 8 werden vier offiziell unterstützte Filter angeboten:

verify: Es wird nur die DEX-Codeüberprüfung ausgeführt (keine AOT-Kompilierung).
quicken: (Android 11 oder niedriger) Führt eine DEX-Codeüberprüfung durch und optimiert einige DEX-Anweisungen, um die Interpreterleistung zu verbessern.
speed: Führt die DEX-Codeüberprüfung durch und kompiliert alle Methoden mit AOT. Die Ladung von Klassen wird für keine Klassen optimiert.
speed-profile: Führt die DEX-Codeüberprüfung aus, kompiliert die im Profil aufgeführten Methoden mit AOT und optimiert die Klassenladevorgänge für Klassen im Profil.

System-ROM-Konfiguration

Vorinstallierte Bibliotheken und Apps werden beim Erstellen eines System-Images AOT-kompiliert. Dieser Vorgang wird als dexpreopt bezeichnet. Diese kompilierten Dateien können verwendet werden, solange alle Abhängigkeiten unverändert bleiben, insbesondere der Boot-Classpath.

Hinweis:Wenn auf dem Gerät Systemmodul-Updates installiert werden, ändert sich der Boot-ClassPath höchstwahrscheinlich bei der nächsten Aktualisierung. Dadurch werden alle dexpreopt-Dateien ungültig und können nicht mehr verwendet werden.

Es gibt eine Reihe von ART-Build-Optionen, mit denen dexpreopt konfiguriert werden kann. Wie Sie diese Optionen konfigurieren, hängt vom verfügbaren Speicherplatz für das System-Image und der Anzahl der vorinstallierten Anwendungen ab. Die JARs/APKs, die in ein System-ROM kompiliert werden, lassen sich in vier Kategorien unterteilen:

Boot-Classpath-Code: Wird standardmäßig mit dem speed-profile-Compilerfilter kompiliert.
Systemservercode (siehe PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS und PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS weiter unten in diesem Dokument):
- (Android 14 und höher) Standardmäßig mit dem speed-profile-Compilerfilter oder mit dem speed-Compilerfilter kompiliert, wenn kein Profil angegeben ist.
- (Android 13 und niedriger) Standardmäßig mit dem Compilerfilter speed kompiliert.
Über PRODUCT_SYSTEM_SERVER_COMPILER_FILTER konfigurierbar (siehe weiter unten in diesem Dokument).
Produktspezifische Kern-Apps (siehe PRODUCT_DEXPREOPT_SPEED_APPS weiter unten in diesem Dokument): werden standardmäßig mit dem Compilerfilter speed kompiliert.
Alle anderen Apps: Standardmäßig mit dem speed-profile-Compilerfilter oder mit dem verify-Compilerfilter kompiliert, wenn kein Profil angegeben ist.
Über PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER konfigurierbar (siehe weiter unten in diesem Dokument).

Makefile-Optionen

WITH_DEXPREOPT

Gibt an, ob dex2oat auf DEX-Code aufgerufen wird, der im System-Image installiert ist. Standardmäßig aktiviert.

DONT_DEXPREOPT_PREBUILTS (Android 5 und höher)

Wenn Sie DONT_DEXPREOPT_PREBUILTS aktivieren, werden die Prebuilts nicht dexpoptiert. Das sind Apps, in deren Android.mk include $(BUILD_PREBUILT) angegeben ist. Wenn Sie das Überspringen von Dexpreopt für vorgefertigte Apps, die wahrscheinlich über Google Play aktualisiert werden, aktivieren, sparen Sie Speicherplatz im System-Image, verlängern aber die Zeit für den ersten Start. Diese Option hat keine Auswirkungen auf vorkonfigurierte Apps, die in Android.bp definiert sind.

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 oder höher)

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER gibt den Standardcompilerfilter für dexpreoptierte Anwendungen an. Diese Apps sind in Android.bp definiert oder haben include $(BUILD_PREBUILT) in ihrer Android.mk angegeben. Wenn kein Wert angegeben ist, gilt der Standardwert speed-profile. Ist kein Wert angegeben und auch kein Profil vorhanden, gilt der Standardwert verify.

WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (seit Android 8 MR1)

Wenn Sie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY aktivieren, werden nur die Boot-ClassPath- und Systemserver-JAR-Dateien dexpreoptiert.

LOCAL_DEX_PREOPT

Dexpreopt kann auch für einzelne Apps aktiviert oder deaktiviert werden, indem Sie die Option LOCAL_DEX_PREOPT in der Moduldefinition angeben. Dies kann nützlich sein, um die Dexpreopt-Funktion für Apps zu deaktivieren, die möglicherweise sofort Google Play-Updates erhalten, da die Updates den dexpreoptierten Code im System-Image obsolet machen würden. Dies ist auch nützlich, um bei Over-the-air-Upgrades auf Hauptversionen Speicherplatz zu sparen, da Nutzer möglicherweise bereits neuere Versionen von Apps in der Datenpartition haben.

LOCAL_DEX_PREOPT unterstützt die Werte true oder false, um dexpreopt bzw. zu aktivieren oder zu deaktivieren. Außerdem kann nostripping angegeben werden, wenn dexpreopt die classes.dex-Datei nicht aus der APK- oder JAR-Datei entfernen soll. Normalerweise wird diese Datei entfernt, da sie nach dexpreopt nicht mehr benötigt wird. Diese letzte Option ist jedoch erforderlich, damit APK-Signaturen von Drittanbietern gültig bleiben.

PRODUCT_DEX_PREOPT_BOOT_FLAGS

Übergibt Optionen an dex2oat, um zu steuern, wie das Boot-Image kompiliert wird. Sie können damit benutzerdefinierte Listen von Bildklassen, Listen von kompilierten Klassen und Compilerfilter angeben.

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

Übergibt Optionen an dex2oat, um zu steuern, wie alles außer dem Boot-Image kompiliert wird.

PRODUCT_DEX_PREOPT_MODULE_CONFIGS

Ermöglicht das Übergeben von dex2oat-Optionen für ein bestimmtes Modul und eine bestimmte Produktkonfiguration. Sie wird in der device.mk-Datei eines Produkts durch $(call add-product-dex-preopt-module-config,<modules>,<option>) festgelegt. <modules> ist eine Liste von LOCAL_MODULE- und LOCAL_PACKAGE-Namen für JAR- und APK-Dateien.

PRODUCT_DEXPREOPT_SPEED_APPS (seit Android 8)

Liste der Apps, die als für die Produkte zentral eingestuft wurden und die mit dem speed-Compilerfilter kompiliert werden sollten. Beispielsweise können persistente Apps wie SystemUI die profilbasierte Kompilierung erst beim nächsten Neustart nutzen. Daher ist es für das Produkt möglicherweise besser, wenn diese Apps immer AOT-kompiliert werden.

PRODUCT_SYSTEM_SERVER_APPS (seit Android 8)

Liste der Apps, die vom Systemserver geladen werden. Diese Apps werden standardmäßig mit dem Compilerfilter speed kompiliert.

PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (seit Android 8)

Gibt an, ob eine Debugversion von ART auf dem Gerät enthalten sein soll. Diese Funktion ist standardmäßig für Userdebug- und eng-Builds aktiviert. Das Verhalten kann überschrieben werden, indem Sie die Option explizit auf true oder false festlegen.

Standardmäßig verwendet das Gerät die Version ohne Debugging (libart.so). Wenn Sie wechseln möchten, setzen Sie die Systemeigenschaft persist.sys.dalvik.vm.lib.2 auf libartd.so.

WITH_DEXPREOPT_PIC (bis Android 7)

Unter Android 5.1.0 bis Android 6.0.1 kann WITH_DEXPREOPT_PIC angegeben werden, um Positionsunabhängigen Code (PIC) zu aktivieren. Dadurch muss der kompilierte Code aus dem Image nicht von /system nach /data/dalvik-cache verschoben werden, was Platz in der Datenpartition spart. Dies hat jedoch geringfügige Auswirkungen auf die Laufzeit, da eine Optimierung deaktiviert wird, die standortabhängigen Code nutzt. Geräte, die Speicherplatz in /data sparen möchten, sollten in der Regel die PIC-Kompilierung aktivieren.

In Android 7.0 war die PIC-Kompilierung standardmäßig aktiviert.

WITH_DEXPREOPT_BOOT_IMG_ONLY (bis Android 7 MR1)

Diese Option wurde durch WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY ersetzt, mit der auch die JAR-Dateien des Systemservers vorab ausgewählt werden.

PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

Mit dieser Option wird der Compilerfilter für den Systemserver angegeben.

(Android 14 und höher) Wenn nicht angegeben, wird der Compilerfilter speed-profile oder der Compilerfilter speed verwendet, wenn kein Profil angegeben ist.
(Android 13 und niedriger) Wenn keine Angabe erfolgt, wird der speed-Compilerfilter verwendet.
Wenn speed festgelegt ist, wird der speed-Compilerfilter verwendet.
Wenn speed-profile festgelegt ist, wird der speed-profile-Compilerfilter verwendet. Andernfalls wird der verify-Compilerfilter verwendet, wenn kein Profil angegeben ist.
Wenn verify festgelegt ist, wird der verify-Compilerfilter verwendet.

PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

Im Folgenden finden Sie Listen der JAR-Dateien, die vom Systemserver geladen werden. Die JAR-Dateien werden mit dem von PRODUCT_SYSTEM_SERVER_COMPILER_FILTER angegebenen Compilerfilter kompiliert.

(Erforderlich) PRODUCT_SYSTEM_SERVER_JARS: Liste der Klassenpfad-JAR-Dateien des Systemservers auf der Plattform (d. h. als Teil von SYSTEMSERVERCLASSPATH). Es ist erforderlich, dieser Liste Klassenpfad-JAR-Dateien des Systemservers hinzuzufügen. Wenn Sie der Liste keine JAR-Dateien des Systemserver-Klassenpfads hinzufügen, werden diese JAR-Dateien nicht geladen.
(Erforderlich) PRODUCT_APEX_SYSTEM_SERVER_JARS: Liste der JAR-Dateien des Systemserver-Klassenpfads, die mit APEX bereitgestellt werden (d. h. als Teil von SYSTEMSERVERCLASSPATH). Das Format ist <apex name>:<jar name>. Es ist erforderlich, dieser Liste JAR-Dateien für den APEX-Systemserver-Klassenpfad hinzuzufügen. Wenn Sie dieser Liste keine JAR-Dateien für den Klassenpfad des APEX-Systemservers hinzufügen, werden diese JAR-Dateien nicht geladen.
Optional, Android 13 und niedriger: PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: Liste der JARs, die der Systemserver dynamisch mithilfe separater Classloader (über SystemServiceManager.startServiceFromJar) lädt. Das Hinzufügen eigenständiger Systemserver-JARs zu dieser Liste ist nicht erforderlich, wird aber dringend empfohlen, da die JARs dadurch kompiliert werden und daher eine gute Laufzeitleistung haben.
(erforderlich seit Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: Liste der JAR-Dateien, die mit APEX bereitgestellt werden und vom Systemserver dynamisch mithilfe separater Classloader geladen werden (d. h. über SystemServiceManager.startServiceFromJar oder als <apex-system-service> deklariert). Das Format ist <apex name>:<jar name>. Es ist erforderlich, dieser Liste JAR-Dateien für eigenständige APEX-Systemserver hinzuzufügen. Wenn Sie dieser Liste keine eigenständigen JAR-Dateien für APEX-Systemserver hinzufügen, führt dies zu einem Bootfehler.

Boot-Classpath-Konfiguration

Die Liste der vorab geladenen Klassen enthält Klassen, die von Zygote beim Start initialisiert werden. So muss jede App diese Klasseninitialisierer nicht separat ausführen, wodurch sie schneller gestartet werden und Seiten im Arbeitsspeicher gemeinsam nutzen können. Die Datei mit der Liste der vorab geladenen Klassen befindet sich standardmäßig unter frameworks/base/config/preloaded-classes. Sie enthält eine Liste, die für die typische Nutzung des Smartphones optimiert ist. Bei anderen Geräten wie Wearables kann das anders sein und muss entsprechend angepasst werden. Seien Sie bei der Optimierung vorsichtig: Wenn Sie zu viele Klassen hinzufügen, wird Speicher verschwendet, wenn nicht verwendete Klassen geladen werden. Wenn Sie zu wenige Klassen hinzufügen, muss jede App eine eigene Kopie haben, was wiederum Speicher verschwendet.

Beispiel für die Verwendung (in der device.mk des Produkts):

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

Hinweis:Diese Zeile muss vor dem Übernehmen von Makefiles für die Produktkonfiguration platziert werden, die die Standarddatei von build/target/product/base.mk erhalten.

Laufzeitkonfiguration

JIT-Optionen

Die folgenden Optionen wirken sich nur auf Android-Releases aus, bei denen der ART-JIT-Compiler verfügbar ist.

dalvik.vm.usejit: Gibt an, ob die JIT-Kompilierung aktiviert ist.
dalvik.vm.jitinitialsize (Standard: 64 KB): Die anfängliche Kapazität des Code-Cache. Der Codecache wird regelmäßig GC und bei Bedarf erhöht.
dalvik.vm.jitmaxsize (Standard: 64 Mio.): Die maximale Kapazität des Code-Cache.
dalvik.vm.jitthreshold (Standardwert: 10.000): Der Grenzwert, den der „Hotness“-Zähler einer Methode erreichen muss, damit die Methode JIT-kompiliert wird. Der „Hotness“-Zähler ist ein Messwert, der der Laufzeit intern ist. Dazu gehören die Anzahl der Aufrufe, Rücksprünge und andere Faktoren.
dalvik.vm.usejitprofiles (bis Android 13): Gibt an, ob JIT-Profile aktiviert sind. Dieser Parameter kann auch verwendet werden, wenn dalvik.vm.usejit auf „falsch“ gesetzt ist. Wenn dies falsch ist, wird mit dem Compilerfilter speed-profile keine Methode AOT-kompiliert und er entspricht verify. Seit Android 14 sind JIT-Profile immer aktiviert und können nicht deaktiviert werden.
dalvik.vm.jitprithreadweight (Standard: dalvik.vm.jitthreshold / 20): Das Gewicht der JIT-„Samples“ (siehe jitthreshold) für den UI-Thread der Anwendung. Beschleunigt die Kompilierung von Methoden, die sich direkt auf die Nutzererfahrung bei der Interaktion mit der App auswirken.
dalvik.vm.jittransitionweight (Standardwert: dalvik.vm.jitthreshold ÷ 10): Das Gewicht der Methode, die zwischen Compile-Code und Interpreter wechselt. So können die beteiligten Methoden so kompiliert werden, dass Übergänge (die teuer sind) minimiert werden.

Dex2oat-Optionen

Diese Optionen wirken sich auf die On-Device-Kompilierung (dexopt) und einige davon auch auf dexpreopt aus. Die Optionen, die im Abschnitt System-ROM-Konfiguration oben beschrieben wurden, wirken sich dagegen nur auf dexpreopt aus.

Optionen zur Steuerung der Ressourcennutzung:

dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (bis Android 11): Die Anzahl der Threads und die CPU-Kerne (siehe unten), die für Boot-Images verwendet werden sollen.
dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
- (Bis Android 11) Die Anzahl der Threads und die CPU-Kerne (siehe unten), die während des Bootens für alle anderen Prozesse als Boot-Images verwendet werden sollen.
- (Seit Android 12) Die Anzahl der Threads und die CPU-Kerne (siehe unten), die während des Bootens für alles verwendet werden, einschließlich Boot-Images.
  - Seit Android 14 entspricht dies der Prioritätsklasse PRIORITY_BOOT im ART-Dienst.
dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
- (seit Android 11 bis Android 13) Die Anzahl der Threads und die CPU-Kerne (siehe unten), die für die Wiederherstellung aus der Cloud-Sicherung verwendet werden sollen.
- (Seit Android 14) Die Anzahl der Threads und die CPU-Kerne (siehe unten), die für alle Vorgänge verwendet werden sollen, die empfindlicher gegenüber Latenz sind als normal, einschließlich der Wiederherstellung aus einem Cloud-Back-up.
  - Dies entspricht der Prioritätsklasse PRIORITY_INTERACTIVE_FAST im ART-Dienst.
dalvik.vm.background-dex2oat-threads/dalvik.vm.background-dex2oat-cpu-set (seit Android 14): Die Anzahl der Threads und die CPU-Kerne (siehe unten), die im Hintergrund verwendet werden sollen.
- Dies entspricht der Prioritätsklasse PRIORITY_BACKGROUND im ART-Dienst.
dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Die Anzahl der Threads und die CPU-Kerne, die für alles andere verwendet werden sollen.

CPU-Kerne sollten als durch Kommas getrennte Liste von CPU-IDs angegeben werden. Wenn Sie dex2oat beispielsweise auf den CPU-Kernen 0–3 ausführen möchten, legen Sie Folgendes fest:

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

Wenn Sie die CPU-Affinitätseigenschaften festlegen, empfehlen wir, die entsprechende Property für die Anzahl der dex2oat-Threads an die Anzahl der ausgewählten CPUs anzupassen, um unnötigen Arbeitsspeicher- und I/O-Konflikt zu vermeiden:

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

Zusätzlich zu den oben genannten Systemeigenschaften können Sie auch Aufgabenprofile verwenden, um die Ressourcennutzung von dex2oat zu steuern (siehe Cgroup Abstraction Layer).

Folgende Aufgabenprofile werden unterstützt:

Dex2OatBackground (seit Android 14) (standardmäßig wird Dex2OatBootComplete übernommen): Steuert die Ressourcen, die im Hintergrund verwendet werden sollen.
- Dies entspricht der Prioritätsklasse PRIORITY_BACKGROUND im ART-Dienst.
Dex2OatBootComplete:
- (bis Android 13) Steuert die Ressource, die nach dem Start für alle Prozesse verwendet werden soll.
- (seit Android 14) Steuert die Ressource, die nach dem Start und nicht im Hintergrund verwendet werden soll.
  - Dies entspricht den Prioritätsklassen PRIORITY_INTERACTIVE_FAST und PRIORITY_INTERACTIVE im ART-Dienst.

Wenn sowohl Systemeigenschaften als auch Aufgabenprofile angegeben sind, werden beide angewendet.

Optionen zum Steuern der Heap-Größe:

dalvik.vm.image-dex2oat-Xms: Die anfängliche Heap-Größe für Boot-Images.
dalvik.vm.image-dex2oat-Xmx: Maximale Heap-Größe für Boot-Images.
dalvik.vm.dex2oat-Xms: Die anfängliche Heap-Größe für alles andere.
dalvik.vm.dex2oat-Xmx: Maximale Heap-Größe für alle anderen Elemente.

Die Optionen, die die initiale und maximale Heap-Größe für dex2oat steuern, sollten nicht reduziert werden, da dies die Anzahl der Anwendungen einschränken könnte, die kompiliert werden können.

Optionen zur Steuerung des Compilerfilters:

dalvik.vm.image-dex2oat-filter (bis Android 11): Der Compilerfilter für Boot-Images. Seit Android 12 ist der Compilerfilter für Boot-Images immer speed-profile und kann nicht geändert werden.
dalvik.vm.systemservercompilerfilter (seit Android 13): Der Compilerfilter für den Systemserver. Weitere Informationen finden Sie unter PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
dalvik.vm.systemuicompilerfilter (seit Android 13): Der Compilerfilter für das System-UI-Paket.
dalvik.vm.dex2oat-filter (bis Android 6): Der Compilerfilter für alles andere.
pm.dexopt.<reason> (seit Android 7): Der Compilerfilter für alles andere. Weitere Informationen finden Sie unter ART-Dienstkonfiguration für Android 14 und höher oder Paketmanagerkonfiguration für Android 13 und niedriger.

Weitere Optionen zur Steuerung der Kompilierung aller anderen Elemente als Boot-Images:

dalvik.vm.dex2oat-very-large (seit Android 7.1): Minimale Gesamtgröße der Dex-Datei in Byte, um die AOT-Kompilierung zu deaktivieren.
dalvik.vm.dex2oat-swap (seit Android 7.1) (Standard: „wahr“): Ermöglicht die Verwendung einer Auslagerungsdatei für dex2oat. So lassen sich Abstürze aufgrund von fehlendem Arbeitsspeicher vermeiden. Auch wenn diese Option aktiviert ist, verwendet dex2oat eine Auslagerungsdatei nur unter bestimmten Bedingungen, z. B. wenn die Anzahl der dex-Dateien groß ist. Diese Bedingungen können sich ändern.
dalvik.vm.ps-min-first-save-ms (seit Android 12): Mindestdauer, die gewartet werden muss, bevor die Laufzeit ein Profil der Anwendung generiert, wenn die Anwendung zum ersten Mal gestartet wird.
dalvik.vm.ps-min-save-period-ms (seit Android 12): Die Mindestzeit, die vor dem Aktualisieren des App-Profils verstreichen muss.
dalvik.vm.dex2oat64.enabled (seit Android 11) (Standard: „false“): ob die 64-Bit-Version von dex2oat verwendet werden soll.
dalvik.vm.bgdexopt.new-classes-percent (seit Android 12) (Standard: 20): Der Mindestprozentsatz (zwischen 0 und 100) der neuen Klassen in einem Profil, der eine Neukompilierung auslöst. Gilt nur für die profilbasierte Kompilierung (speed-profile), in der Regel während der DeXOpt im Hintergrund. Zusätzlich zum prozentualen Grenzwert gibt es einen Grenzwert von mindestens 50 neuen Klassen. Dieser ist nicht konfigurierbar.
dalvik.vm.bgdexopt.new-methods-percent (seit Android 12) (Standard: 20): Der Mindestprozentsatz (zwischen 0 und 100) der neuen Methoden in einem Profil, der eine Neukompilierung auslöst. Gilt nur für die profilbasierte Kompilierung (speed-profile), in der Regel während der DeXOpt im Hintergrund. Zusätzlich zum Prozentsatzgrenzwert gibt es einen Grenzwert von mindestens 100 neuen Methoden, der nicht konfigurierbar ist.
dalvik.vm.dex2oat-max-image-block-size (seit Android 10) (Standard: 524288) Maximale Größe eines durchgehenden Blocks für komprimierte Bilder. Ein großes Bild wird in eine Reihe von Vollblöcken aufgeteilt, sodass kein Block größer als die maximale Größe ist.
dalvik.vm.dex2oat-resolve-startup-strings (seit Android 10) (Standard: „wahr“) Wenn „wahr“, löst dex2oat alle Konstantenstrings auf, auf die von Methoden verwiesen wird, die im Profil als „Startup“ gekennzeichnet sind.
debug.generate-debug-info (Standard: „false“) Gibt an, ob Debug-Informationen für die native Fehlerbehebung generiert werden sollen, z. B. Informationen zum Aufheben der Stapelausweitung, ELF-Symbole und Dwarf-Abschnitte.
dalvik.vm.dex2oat-minidebuginfo (seit Android 9) (Standard: „wahr“) Gibt an, ob eine minimale Menge an LZMA-komprimierten Debug-Informationen generiert werden soll, die zum Drucken von Rückverfolgungen erforderlich sind.

ART-Dienstoptionen

ART-Dienst konfigurieren

Optionen für Paketmanager

Paketmanagerkonfiguration

A/B-spezifische Konfiguration

ROM-Konfiguration

Ab Android 7.0 können Geräte zwei Systempartitionen verwenden, um A/B-Systemupdates zu ermöglichen. Um die Größe der Systempartition zu verkleinern, können die vorab ausgewählten Dateien in der nicht verwendeten zweiten Systempartition installiert werden. Sie werden dann beim ersten Start in die Datenpartition kopiert.

Beispielverwendung (in device-common.mk):

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

Und in den BoardConfig.mk-Einstellungen des Geräts:

BOARD_USES_SYSTEM_OTHER_ODEX := true

Der Boot-Classpath-Code, der Systemserver-Code und produktspezifische Kern-Apps werden immer in die Systempartition kompiliert. Standardmäßig werden alle anderen Apps in die nicht verwendete zweite Systempartition kompiliert. Dies kann mit der SYSTEM_OTHER_ODEX_FILTER gesteuert werden, die standardmäßig den Wert

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

OTA-Dexopt im Hintergrund

Auf A/B-fähigen Geräten können Anwendungen vor dem Neustart im Hintergrund mit dem neuen System-Image kompiliert werden. Weitere Informationen zum optionalen Einfügen des Kompilierungsscripts und der Binärdateien in das System-Image finden Sie unter App-Kompilierung im Hintergrund. Der für diese Zusammenstellung verwendete Kompilierungsfilter wird mit folgenden Optionen gesteuert:

pm.dexopt.ab-ota=speed-profile

Wir empfehlen die Verwendung von speed-profile, um die profilbasierte Kompilierung zu nutzen und Speicherplatz zu sparen.

JDWP-Optionen

Die Erstellung von JDWP-Threads (Java Debug Wire Protocol) in Userdebug-Builds wird über die Systemeigenschaft persist.debug.dalvik.vm.jdwp.enabled gesteuert. Standardmäßig ist diese Eigenschaft nicht festgelegt und JDWP-Threads werden nur für debugfähige Apps erstellt. Wenn Sie JDWP-Threads sowohl für debuggbare als auch nicht debuggbare Apps aktivieren möchten, setzen Sie persist.debug.dalvik.vm.jdwp.enabled auf 1. Das Gerät muss neu gestartet werden, damit die Änderungen an der Property wirksam werden.

Wenn Sie eine nicht debuggbare App in einem Userdebug-Build debuggen möchten, aktivieren Sie JDWP mit dem folgenden Befehl:

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

Hinweis:Wenn Sie die persist.debug.dalvik.vm.jdwp.enabled-Eigenschaft auf 1 festlegen, können die Apps nicht mehr debuggt werden. Es ist nur möglich, einen Debugger an den Prozess anzuhängen.