ART konfigurieren

Auf dieser Seite wird die Konfiguration der Android-Laufzeit (ART) und ihrer Kompilierungsoptionen erläutert. Themen die hier enthalten sind, die Konfiguration der Vorkompilierung des System-Images dex2oat Kompilierungsoptionen und den Ausgleich von Systempartitions- und Datenpartitionsspeichern die Leistung.

Informationen zur Arbeit mit ART finden Sie unter ART und Dalvik und das ausführbare Format von Dalvik. Weitere Informationen finden Sie unter Überprüfen App-Verhalten in Android Runtime (ART), um sicherzustellen, dass Ihre Apps funktionieren ordnungsgemäß funktioniert.

So funktioniert ART

ART verwendet eine Pre-of-Time-Kompilierung (AOT) und ab Android 7 verwendet eine Hybridkombination aus AOT-Kompilierung, Just-in-Time-Kompilierung (JIT) und Interpretation. und die AOT-Kompilierung kann profilgesteuert werden. Die Kombination all dieser Ausführungsmodi konfigurierbar sind und werden in diesem Abschnitt erläutert. Pixel-Geräte sind beispielsweise so konfiguriert, wie im Folgenden beschrieben:

  1. Eine Anwendung wird anfangs mit einer DEX-Metadatendatei (.dm) installiert, die über Play Store, der ein Cloud-Profil enthält. ART AOT kompiliert die in der Cloud aufgeführten Methoden zu erstellen. Wenn die Anwendung ohne DEX-Metadatendatei installiert wird, ist keine AOT-Kompilierung durchgeführt wurde.
  2. In den ersten paar Ausführungen der Anwendung werden nicht durch AOT kompilierte Methoden interpretiert. Unter den interpretierten Methoden werden die häufig ausgeführten Methoden dann per JIT kompiliert. Kunst generiert basierend auf der Ausführung ein lokales Profil und kombiniert es mit dem Cloud-Profil (falls eines existiert).
  3. Wenn das Gerät inaktiv ist und aufgeladen wird, wird ein Kompilierungs-Daemon ausgeführt, um die Anwendung neu zu kompilieren. basierend auf dem kombinierten Profil, das während der ersten Ausführungen erstellt wurde.
  4. In den nachfolgenden Ausführungen der Anwendung verwendet ART die von der Kompilierung generierten Artefakte Daemon, der mehr AOT-kompilierten Code enthält als der, der während Nicht mit AOT kompilierte Methoden werden trotzdem interpretiert oder mit JIT kompiliert. ART aktualisiert das Profil und das Profil wird von nachfolgenden Durchläufen den Kompilierungs-Daemon.

ART besteht aus einem Compiler (dem dex2oat-Tool) und einer Laufzeit. (libart.so), der während des Startvorgangs geladen wird. Die Das dex2oat-Tool generiert aus einer APK-Datei Kompilierungsartefaktdateien, die von der Laufzeit geladen werden. Die Anzahl der Dateien, ihre Erweiterungen und Namen können sich je nach Version ändern, ab dem Android 8. Diese Dateien werden generiert:

  • .vdex: enthält zusätzliche Metadaten, um die Überprüfung zu beschleunigen, manchmal zusammen mit durch den unkomprimierten DEX-Code des APK.
  • .odex: enthält AOT-kompilierten Code für Methoden in den APK
  • .art (optional) enthält interne ART-Elemente Darstellungen einiger im APK aufgeführter Strings und Klassen zur Beschleunigung App-Start.

Kompilierungsoptionen

Es gibt zwei Kategorien von Kompilierungsoptionen für ART:

  1. System-ROM-Konfiguration: Welcher Code wird bei der Erstellung eines System-Image.
  2. Laufzeitkonfiguration: wie ART Apps kompiliert und auf einem .

Compiler-Filter

Eine ART-Hauptoption zum Konfigurieren dieser beiden Kategorien ist der Compiler Filter. Compiler-Filter bestimmen, wie ART den DEX-Code kompiliert. an das dex2oat-Tool übergeben. Ab Android 8 gibt es vier offiziell unterstützte Filter:

  • verify: Führt nur die DEX-Codeüberprüfung aus (keine AOT-Kompilierung).
  • quicken: (bis Android 11) DEX-Code ausführen überprüfen und einige DEX-Anweisungen optimieren, um eine bessere Dolmetscherleistung zu erzielen.
  • speed: Führen Sie die DEX-Codeüberprüfung aus und kompilieren Sie alle Methoden mithilfe von AOT.
  • speed-profile: Methoden zur DEX-Codeüberprüfung und AOT-Kompilierung ausführen die in einer Profildatei aufgeführt sind.

System-ROM-Konfiguration

Vorinstallierte Bibliotheken und Apps werden beim Erstellen eines System-Images automatisch kompiliert. Dieses wird als dexpreopt bezeichnet. Solche kompilierten Dateien sind nutzbar, solange alle Abhängigkeiten unverändert bleiben, insbesondere der Boot-Klassenpfad.

Hinweis:Wenn das Gerät Systemmodul aktualisiert, dann ist der Boot-Klassenpfad wird sich bei der nächsten Aktualisierung wahrscheinlich ändern, wodurch alle dexpreopt-Dateien veraltet und unbrauchbar werden.

Für die Konfiguration von dexpreopt stehen mehrere ART-Build-Optionen zur Verfügung. Konfiguration Diese Optionen hängen vom verfügbaren Speicherplatz für das System-Image und der Anzahl vorinstallierten Apps installiert. Die JARs/APKs, die in ein System-ROM kompiliert werden, können in vier unterteilt werden. Kategorien:

  • Bootklassenpfadcode: mit dem Compiler speed-profile kompiliert nach Standardeinstellung.
  • Systemservercode (siehe PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS weiter unten in diesem Dokument): <ph type="x-smartling-placeholder">
      </ph>
    • (Android 14 und höher) Kompiliert mit speed-profile ist standardmäßig der Compiler-Filter oder wird mit dem Compiler-Filter speed kompiliert, wenn ein Profil nicht angegeben.
    • (Android 13 und niedriger) Kompiliert mit speed Compiler-Filter standardmäßig.
    Konfigurierbar über PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (weitere Informationen später in diesem Dokument).
  • Produktspezifische Haupt-Apps (siehe PRODUCT_DEXPREOPT_SPEED_APPS weiter unten in dieser document): Standardmäßig mit dem Compiler-Filter speed kompiliert.
  • Alle anderen Apps: standardmäßig mit dem Compiler-Filter speed-profile kompiliert oder mit dem Compiler-Filter verify kompiliert werden, wenn kein Profil angegeben ist.

    Konfigurierbar über PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (weitere Informationen weiter unten) Dokument).

Makefile-Optionen

  • WITH_DEXPREOPT

    • Gibt an, ob dex2oat in dem auf dem System-Image installierten DEX-Code aufgerufen wird. Standardmäßig aktiviert.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 und höher)

    • Wenn Sie DONT_DEXPREOPT_PREBUILTS aktivieren, werden die vordefinierten dexpreopted. Das sind Apps mit include $(BUILD_PREBUILT) die in der Android.mk angegeben sind. Überspringen Bereitstellung vorkonfigurierter Apps, die wahrscheinlich über Google Play aktualisiert werden spart Speicherplatz im System-Image, erhöht aber den Zeitaufwand für den ersten Start. Diese Option hat keine Auswirkungen vordefinierten Apps, die in Android.bp definiert sind.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9) und höher)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER gibt den Standard-Compilerfilter an für dexpreoptierte Anwendungen. Diese Apps sind in Android.bp definiert oder wurden include $(BUILD_PREBUILT) wurde in der Android.mk angegeben. Wenn keine Angabe erfolgt, gilt Folgendes: Der Standardwert ist speed-profile oder verify, wenn kein Wert angegeben ist und es wird kein Profil bereitgestellt.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (seit Android 8 MR1)

    • Wenn Sie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY aktivieren, wird nur die Boot-Klassenpfad und Systemserver-JAR-Dateien.

  • LOCAL_DEX_PREOPT

    • Dexpreopt kann auch für einzelne Anwendungen aktiviert oder deaktiviert werden. Angabe der Option LOCAL_DEX_PREOPT in der Moduldefinition Dies kann nützlich sein, um das Entfernen von Apps zu deaktivieren, die sofort Google Play-Updates erhalten, da durch diese Updates Code im System-Image veraltet ist. Dies ist auch nützlich, um Platz bei wichtigen OTAs mit Versionsupgrade, da Nutzer möglicherweise bereits neuere Versionen von Apps im Datenpartitionierung.

    LOCAL_DEX_PREOPT unterstützt die Werte true oder false, dexpreopt aktivieren bzw. deaktivieren. Außerdem kann nostripping wird angegeben, wenn bei der dexpreopt-Funktion classes.dex nicht entfernt werden soll. aus der APK- oder JAR-Datei. Normalerweise wird diese Datei entfernt, nach dem Expreopting nicht mehr gebraucht. Diese letzte Option ist jedoch erforderlich, Gültigkeit von Drittanbieter-APK-Signaturen zulassen.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Gibt Optionen an dex2oat weiter, um zu steuern, wie das Boot-Image ist kompiliert werden. Damit können benutzerdefinierte Bildklassenlisten, kompilierte Klassenlisten und Compilerfilter.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

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

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Bietet die Möglichkeit, dex2oat-Optionen für eine bestimmte und die Produktkonfiguration. Sie wird in der device.mk-Datei von $(call add-product-dex-preopt-module-config,<modules>,<option>) Dabei ist <modules> eine Liste von LOCAL_MODULE und LOCAL_PACKAGE-Namen für JAR- bzw. APK-Dateien.

  • PRODUCT_DEXPREOPT_SPEED_APPS (seit Android 8)

    • Liste der Apps, die als zentraler Bestandteil der Produkte identifiziert wurden die mit dem Compiler-Filter speed kompiliert werden können. Für können persistente Anwendungen wie SystemUI profilgestützte Kompilierung nur beim nächsten Neustart. Daher ist es besser für den damit diese Apps immer automatisch kompiliert werden.

  • PRODUCT_SYSTEM_SERVER_APPS (seit Android 8)

    • Liste der Apps, die vom Systemserver geladen werden. Diese Apps werden standardmäßig mit dem Compiler-Filter speed kompiliert.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (seit Android 8.

    • Gibt an, ob auf dem Gerät eine Debug-Version von ART enthalten sein soll. Standardmäßig ist dies aktiviert ist. Das Verhalten kann explizit überschrieben werden, Festlegen der Option auf true oder false.

    Standardmäßig verwendet das Gerät die Nicht-Debug-Version (libart.so). Legen Sie zum Wechseln 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 den positionsunabhängigen Code (Position-Independent Code, PIC) zu aktivieren. In diesem Zusammenhang muss der Code des Bildes nicht vom /system in /data/dalvik-cache, wodurch Speicherplatz in der Datenpartition gespart wird. Es gibt jedoch leichte Auswirkungen auf die Laufzeit, da dadurch eine Optimierung deaktiviert wird, die von positionsabhängigem Code. Normalerweise werden Geräte, die in /data Speicherplatz sparen möchten, die PIC-Kompilierung aktivieren sollten.

    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 JARs 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 die speed-profile Compiler-Filter oder der speed-Compiler-Filter wird verwendet, wenn ein Profil nicht bereitgestellt.
    • (Android 13 und niedriger) Wenn nicht angegeben, der Compiler speed -Filter verwendet wird.
    • Wenn speed festgelegt ist, wird der Compilerfilter speed verwendet.
    • Wenn speed-profile festgelegt ist, wird der Compiler-Filter speed-profile verwendet, oder der Compiler-Filter verify wird verwendet, wenn kein Profil angegeben ist.
    • Wenn verify festgelegt ist, wird der Compilerfilter verify 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 JARs, die vom Systemserver geladen werden. Die JARs werden mit dem Compilerfilter angegeben durch PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Erforderlich) PRODUCT_SYSTEM_SERVER_JARS: Liste der Klassenpfad-JARs des Systemservers aktiviert der Plattform (d. h. als Teil von SYSTEMSERVERCLASSPATH). Systemserver wird hinzugefügt Klassenpfad-JARs zu dieser Liste sind erforderlich. Klassenpfad-JARs für Systemserver konnten nicht der Liste hinzugefügt werden werden diese JARs nicht geladen.
    • (Erforderlich) PRODUCT_APEX_SYSTEM_SERVER_JARS: Liste der Klassenpfad-JARs für Systemserver mit APEX ausgeliefert (d. h. als Teil von SYSTEMSERVERCLASSPATH). Das Format ist <apex name>:<jar name> Klassenpfad-JARs für APEX-Systemserver werden hinzugefügt zu Diese Liste ist erforderlich. Wenn Sie dieser Liste keine APEX-Systemserver-Klassenpfad-JARs hinzufügen, führt das zu dass diese JARs nicht geladen werden.
    • (Optional, Android 13 und niedriger) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: Liste der JARs, die vom Systemserver geladen werden dynamisch mit separaten Classloadern (durch SystemServiceManager.startServiceFromJar). Hinzufügen eigenständiger Systemserver-JARs zu Diese Liste ist nicht erforderlich, wird aber dringend empfohlen, da sie die JARs kompiliert und und eine gute Laufzeit haben.
    • (erforderlich, seit Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: Liste mit Mit APEX gelieferte JARs, die vom Systemserver dynamisch mit separaten Classloadern geladen werden (die ist, durch SystemServiceManager.startServiceFromJar oder deklariert als <apex-system-service>. Das Format ist <apex name>:<jar name>. Hinzufügen eigenständiger APEX-Systemserver-JARs zu Diese Liste ist erforderlich. Wenn keine eigenständigen APEX-Systemserver-JARs zu dieser Liste hinzugefügt werden, wird Folgendes ausgegeben: Startfehler.

    Konfiguration des Boot-Klassenpfads

    Die Liste der vorinstallierten Klassen enthält die Klassen, in denen Zygote initialisiert wird. Start-up. Dadurch müssen die einzelnen Apps diese Klasseninitialisierer nicht mehr ausführen. Dadurch können sie schneller gestartet und Seiten im Arbeitsspeicher gemeinsam genutzt werden. Die Die Datei mit der vorinstallierten Kursliste befindet sich unter frameworks/base/config/preloaded-classes und enthält eine Liste mit Informationen zu den typischen Smartphone-Nutzungen. Dies könnte unterscheiden sich bei anderen Geräten wie Wearables und müssen entsprechend anpassen. Seien Sie bei der Feinabstimmung vorsichtig: Zu viele Klassenverschwendung wenn nicht verwendete Klassen geladen werden. Wenn Sie zu wenige Klassen hinzufügen, eine eigene Kopie erstellen, was auch viel Arbeitsspeicher verschwendet.

    Verwendungsbeispiel (in der device.mk des Produkts):

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

    Hinweis:Diese Zeile muss vor Alle Makefiles der Produktkonfiguration werden übernommen, die das Standard-Makefiles abrufen. build/target/product/base.mk

    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 JIT aktiviert ist.
    • dalvik.vm.jitinitialsize (Standard: 64 K): Die anfängliche Kapazität im Code-Cache gespeichert. Der Code-Cache führt regelmäßig eine automatische Speicherbereinigung durch und erhöht sich bei Bedarf.
    • dalvik.vm.jitmaxsize (Standard: 64 M): Die maximale Kapazität des Code-Cache.
    • dalvik.vm.jitthreshold (Standardwert 10.000): Der Schwellenwert, an dem die „Wärme“ muss der Zähler einer Methode für die JIT-Kompilierung der Methode. Die „Wärme“ Zähler ist ein interner Messwert zur Laufzeit hinzugefügt. Sie enthält die Anzahl der Aufrufe, Rückwärtszweige und andere Faktoren.
    • dalvik.vm.usejitprofiles (bis Android 13): Gibt an, ob oder JIT-Profile sind nicht aktiviert. Dies kann auch dann verwendet werden, wenn dalvik.vm.usejit „false“ ist. Wenn dies auf "false" gesetzt ist, gilt für den Compiler-Filter speed-profile keine Methode mithilfe von AOT kompiliert und entspricht verify. Seit JIT-Profile unter Android 14 sind immer aktiviert und können nicht deaktiviert werden.
    • dalvik.vm.jitprithreadweight (Standardeinstellung: dalvik.vm.jitthreshold / 20): Die Gewichtung der JIT-„Proben“. (siehe Jitthreshold) für den Anwendungs-UI-Thread. Zum Beschleunigen der Kompilierung die sich direkt auf die User Experience auswirken,
    • dalvik.vm.jittransitionweight (Standardeinstellung: dalvik.vm.jitthreshold / 10): Die Gewichtung der Methode -Aufruf, der zwischen Kompilierungscode und Interpreter wechselt. Das hilft, Stellen Sie sicher, dass die beteiligten Methoden kompiliert sind, um Übergänge (die teuer sein).

    Dex2oat-Optionen

    Diese Optionen wirken sich auf die Kompilierung auf dem Gerät aus (auch Dexopt genannt). Einige davon betreffen auch dexpreopt. Die Optionen, die oben im Abschnitt System-ROM-Konfiguration erläutert wurden, auf dexpreopt.

    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 Anzahl der CPU-Kerne (siehe unten) für Boot-Images verwendet werden.
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set: <ph type="x-smartling-placeholder">
        </ph>
      • (bis Android 11) Anzahl der Threads und CPU-Kerne (siehe unten) zur Verwendung während des Bootvorgangs für alles außer Boot-Images.
      • (seit Android 12) Anzahl der Threads und CPU-Kerne (siehe unten) zur Verwendung während des Bootvorgangs für alle Elemente, einschließlich Boot-Images.
        • Insbesondere entspricht dies seit Android 14 dem Prioritätsklasse PRIORITY_BOOT in ART Service.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set: <ph type="x-smartling-placeholder">
        </ph>
      • (seit Android 11 bis Android 13) Anzahl der Threads und CPU-Kerne (siehe unten) für die Wiederherstellung aus der Cloud Back-up.
      • (seit Android 14) Anzahl der Threads und CPU-Kerne (siehe unten) für alles, was latenzempfindlicher als normal ist, einschließlich Wiederherstellung aus einer Cloud-Sicherung.
        • Insbesondere entspricht dies der Prioritätsklasse, PRIORITY_INTERACTIVE_FAST in ART Service.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (seit Android 14): Die Anzahl der Threads und die Anzahl der CPU-Kerne (siehe unten) zur Verwendung im Hintergrund.
      • Insbesondere entspricht dies der Prioritätsklasse PRIORITY_BACKGROUND in ART-Dienst.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Die Anzahl der Threads und die Gruppe von CPU-Kernen, die für alles andere verwendet werden sollen.

    Ein Satz von CPU-Kernen sollte als durch Kommas getrennte Liste von CPU-IDs angegeben werden. Zum Ausführen einer auf dex2oat auf CPU-Kernen 0–3 eingestellt:

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

    Beim Festlegen der CPU-Affinitätseigenschaften empfiehlt es sich, das entsprechende Attribut für die Anzahl der Dex2oat-Threads, die der Anzahl der ausgewählten CPUs entsprechen, um unnötigen Arbeitsspeicher und E/A-Vorgänge zu vermeiden Konflikt: 

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

    Zusätzlich zu den oben genannten Systemeigenschaften können Sie mit Aufgabenprofilen auch den Ressourcennutzung von dex2oat (siehe Cgroup-Abstraktionsebene)

    Unterstützte Aufgabenprofile sind:

    • Dex2OatBackground (seit Android 14) (übernimmt standardmäßig Dex2OatBootComplete): Steuert die Ressourcen, die im Hintergrund verwendet werden sollen.
      • Insbesondere entspricht dies der Prioritätsklasse PRIORITY_BACKGROUND in ART-Dienst.
    • Dex2OatBootComplete: <ph type="x-smartling-placeholder">
        </ph>
      • (bis Android 13) Steuert die Ressource, die für alle Elemente verwendet werden soll nach dem Booten.
      • (seit Android 14) Steuert die Ressource, die für alles verwendet wird und nicht im Hintergrund.
        • Insbesondere entspricht dies der Prioritätsklasse, PRIORITY_INTERACTIVE_FAST und PRIORITY_INTERACTIVE in ART Dienst.

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

    Optionen zum Steuern der Heap-Größe:

    • dalvik.vm.image-dex2oat-Xms: 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: Anfängliche Heap-Größe für alles andere.
    • dalvik.vm.dex2oat-Xmx: Maximale Heap-Größe für alles andere.

    Die Optionen, die die anfängliche und maximale Heap-Größe für dex2oat sollten nicht reduziert werden, weil dadurch Anwendungen kompiliert werden können.

    Optionen zum Steuern des Compiler-Filters:

    • dalvik.vm.image-dex2oat-filter (bis Android 11): Der Compilerfilter für Boot-Images. Seit Android 12 hat der Compiler Der Filter für Boot-Images ist 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 älter oder Paketmanager-Konfiguration für Android 13 und niedriger.

    Weitere Optionen zur Steuerung der Kompilierung aller Daten außer Boot-Images:

    • dalvik.vm.dex2oat-very-large (seit Android 7.1): Mindestgesamtgröße DEX-Datei in Bytes deaktiviert, um die AOT-Kompilierung zu deaktivieren.
    • dalvik.vm.dex2oat-swap (seit Android 7.1) (Standardeinstellung: true): Ermöglicht die Verwendung von Swaps für dex2oat. Dies kann dazu beitragen, Abstürze mit unzureichendem Arbeitsspeicher zu vermeiden. Auch wenn diese Option aktiviert ist, verwendet dex2oat eine Auslagerungsdatei nur unter bestimmten Bedingungen, z. B. wenn die Nummer der DEX-Dateien ist groß und die Bedingungen können sich ändern.
    • dalvik.vm.ps-min-first-save-ms (seit Android 12): Das Mindestwartezeit, bevor die Laufzeit ein Profil der Anwendung generiert, beim ersten Mal wenn die Anwendung gestartet wird.
    • dalvik.vm.ps-min-save-period-ms (seit Android 12): Das Mindestwartezeit, bevor das Profil der Anwendung aktualisiert wird.
    • dalvik.vm.dex2oat64.enabled (seit Android 11) (Standardeinstellung: false): Gibt an, 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 neuer Klassen in einem Profil, um eine Neukompilierung auszulösen. Gilt nur für die profilgestützte Kompilierung (speed-profile), in der Regel während Hintergrunddexopt. Außerdem gilt ein Grenzwert von mindestens 50 neuen Klassen zusätzlich zu den der prozentuale Schwellenwert und ist nicht konfigurierbar.
    • dalvik.vm.bgdexopt.new-methods-percent (seit Android 12) (Standard: 20): Der Mindestprozentsatz zwischen 0 und 100 neuer Methoden in einem Profil zum Auslösen einer Neukompilierung. Gilt nur für die profilgestützte Kompilierung (speed-profile), in der Regel während Hintergrunddexopt. Außerdem gilt ein Grenzwert von mindestens 100 neuen Methoden. auf den prozentualen Schwellenwert an. Dieser Parameter kann nicht konfiguriert werden.
    • dalvik.vm.dex2oat-max-image-block-size (seit Android 10) (Standard: 524288) Maximale feste Blockgröße für komprimierte Bilder. Ein großes Bild wird in einen Satz dass kein Block größer als die maximale Größe ist.
    • dalvik.vm.dex2oat-resolve-startup-strings (seit Android 10) (Standardeinstellung: true) Falls wahr, löst dex2oat alle const-Strings auf, auf die von Methoden verwiesen wird, die als „Starten“ im Profil.
    • debug.generate-debug-info (Standardeinstellung: false) Gibt an, ob Informationen zur Fehlerbehebung für das native Debugging generiert werden sollen, z. B. für die Stack-Entspannung Informationen, ELF-Symbole und Zwergabschnitte.
    • dalvik.vm.dex2oat-minidebuginfo (seit Android 9) (Standardeinstellung: true) Legt fest, ob eine minimale Menge an LZMA-komprimierten Debug-Informationen generiert werden soll, die für Backtraces drucken.

    ART Service-Optionen

    Seit Android 14 ist die On-Device-OTA-Kompilierung für Apps (auch Dexopt genannt) von ART Service verarbeitet werden. Informationen zum Konfigurieren des ART-Dienstes finden Sie unter Konfiguration des ART-Dienstes.

    Paketmanager-Optionen

    Vor Android 14 ist die On-Device-AOT-Kompilierung für Apps (auch Dexopt genannt) auf dem Gerät Paketmanager verarbeitet werden. Informationen zum Konfigurieren des Paketmanagers für Dexopt Siehe Paketmanager-Konfiguration.

    A/B-spezifische Konfiguration

    ROM-Konfiguration

    Ab Android 7.0 können Geräte zwei Systempartitionen verwenden, um A/B-Systemupdates Um die Größe der Systempartition zu sparen, können Sie die vorab optimierten Dateien in folgendem Verzeichnis installieren: die nicht verwendete zweite Systempartition. Anschließend werden sie in die Datenpartition kopiert. beim ersten Start.

    Verwendungsbeispiel (in device-common.mk):

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

    Und im BoardConfig.mk des Geräts:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Beachten Sie, dass der Bootklassenpfadcode, der Systemservercode und der produktspezifische Core Anwendungen werden immer in der Systempartition kompiliert. Standardmäßig werden alle anderen Anwendungen werden in die nicht verwendete zweite Systempartition kompiliert. Dabei kann es sich um gesteuert mit dem SYSTEM_OTHER_ODEX_FILTER, der einen Wert hat, der Standardwert:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Hintergrund-OTA-Entfernung

    Auf A/B-fähigen Geräten können Anwendungen vor dem Neustart im Hintergrund kompiliert werden. Dazu verwenden Sie die Funktion neuen System-Image. Siehe App-Kompilierung in background, um optional das Kompilierungsskript und die Binärdateien in das System-Image aufzunehmen. Die Der für diese Kompilierung verwendete Kompilierungsfilter wird mit folgendem Befehl gesteuert:

    pm.dexopt.ab-ota=speed-profile

    Wir empfehlen die Verwendung von speed-profile, um die Vorteile des geführten Profils zu nutzen. kompilieren und Speicherplatz 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. Standardmäßig wird diese Property JDWP-Threads werden nur für debug-fähige Apps erstellt. Um JDWP-Threads für beide zu aktivieren Debug-fähige und nicht Debug-fähige Apps, persist.debug.dalvik.vm.jdwp.enabled festlegen an 1. Das Gerät muss neu gestartet werden, damit die Änderungen an der Eigenschaft wirksam werden.

    Wenn Sie Fehler in einer nicht Debug-fähigen App in einem NutzerDebug-Build beheben möchten, aktivieren Sie JDWP, indem Sie folgenden Befehl ausführen: Befehl:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    <ph type="x-smartling-placeholder"> Bei Geräten mit Android 13 und niedriger erstellt die Laufzeit JDWP Threads für debug-fähige und nicht debugfähige Apps in Builds für Nutzer-Fehlerbehebungen. Es ist also möglich, um einen Debugger hinzuzufügen oder ein Profil für eine Anwendung in Builds für die Fehlerbehebung zu verwenden.