ART konfigurieren

Auf dieser Seite wird erläutert, wie ART und seine Kompilierungsoptionen konfiguriert werden. Zu den hier behandelten Themen gehören die Konfiguration der Vorkompilierung des Systemabbilds, die dex2oat-Kompilierungsoptionen und die Frage, wie Sie den Speicherplatz der Systempartition, den Speicherplatz der Datenpartition und die Leistung ausgleichen können.

Siehe ART und Dalvik , das ausführbare Dalvik-Format und die restlichen Seiten auf source.android.com, um mit ART zu arbeiten. Siehe Überprüfen des App-Verhaltens in der Android-Laufzeit (ART) , um sicherzustellen, dass Ihre Apps ordnungsgemäß funktionieren.

Wie KUNST funktioniert

ART verwendet AOT-Kompilierung (Ahead-of-Time) und ab Android 7.0 (Nougat oder N) eine Hybridkombination aus AOT, Just-in-Time-Kompilierung (JIT) und profilgeführter Kompilierung. Die Kombination all dieser Kompilierungsmodi ist konfigurierbar und wird in diesem Abschnitt besprochen. Beispielsweise werden Pixel-Geräte mit dem folgenden Kompilierungsablauf konfiguriert:

  1. Eine Anwendung wird zunächst ohne AOT-Kompilierung installiert. Die ersten Male, wenn die Anwendung ausgeführt wird, wird sie interpretiert, und häufig ausgeführte Methoden werden JIT-kompiliert.
  2. Wenn das Gerät im Leerlauf ist und lädt, wird ein Kompilierungs-Daemon ausgeführt, um häufig verwendeten Code auf der Grundlage eines Profils zu kompilieren, das während der ersten Läufe generiert wurde.
  3. Beim nächsten Neustart einer Anwendung wird der profilgeführte Code verwendet, und es wird vermieden, zur Laufzeit JIT-Kompilierung für bereits kompilierte Methoden durchzuführen. Methoden, die während der neuen Läufe JIT-kompiliert werden, werden dem Profil hinzugefügt, das dann vom Kompilierungs-Daemon abgeholt wird.

ART besteht aus einem Compiler (dem Tool dex2oat ) und einer Laufzeitumgebung ( libart.so ), die zum Starten von Zygote geladen wird. Das dex2oat Tool nimmt eine APK-Datei und generiert eine oder mehrere Kompilierungsartefaktdateien, die die Laufzeit lädt. Die Anzahl der Dateien, ihre Erweiterungen und Namen können sich zwischen den Versionen ändern, aber ab der Version von Android 8 werden folgende Dateien generiert:

  • .vdex : enthält den unkomprimierten DEX-Code der APK mit einigen zusätzlichen Metadaten zur Beschleunigung der Überprüfung.
  • .odex : enthält AOT-kompilierten Code für Methoden in der APK.
  • .art (optional) : enthält ART-interne Darstellungen einiger Zeichenfolgen und Klassen, die in der APK aufgeführt sind und zur Beschleunigung des Anwendungsstarts verwendet werden.

Zusammenstellungsoptionen

Zusammenstellungsoptionen für ART sind in zwei Kategorien unterteilt:

  1. System-ROM-Konfiguration: Welcher Code wird beim Erstellen eines Systemabbilds AOT-kompiliert.
  2. Laufzeitkonfiguration: wie ART Anwendungen auf einem Gerät kompiliert und ausführt.

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

  • verify : Führen Sie nur die DEX-Code-Verifizierung aus.
  • quicken : (entfernt seit Android 12) Führen Sie die DEX-Code-Überprüfung aus und optimieren Sie einige DEX-Anweisungen, um eine bessere Interpreterleistung zu erzielen.
  • speed : Führen Sie die DEX-Code-Überprüfung aus und kompilieren Sie alle Methoden AOT.
  • speed-profile : Führen Sie die in einer Profildatei aufgelisteten DEX-Code-Verifizierungs- und AOT-Kompilierungsmethoden aus.

System-ROM-Konfiguration

Es gibt eine Reihe von ART-Build-Optionen zum Konfigurieren eines System-ROM. Wie Sie diese Optionen konfigurieren, hängt vom verfügbaren Speicherplatz für das Systemabbild und der Anzahl der vorinstallierten Anwendungen ab. Die JARs/APKs, die in ein System-ROM kompiliert werden, können in vier Kategorien unterteilt werden:

  • Boot-Classpath-Code: standardmäßig mit dem speed-profile Compiler-Filter kompiliert.
  • 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):
    • (seit Android 14 (AOSP experimentell)) standardmäßig mit dem Compiler-Filter für speed kompiliert oder mit dem Compiler-Filter für Geschwindigkeit kompiliert, wenn kein speed-profile bereitgestellt wird.
    • (bis Android 13) standardmäßig mit dem speed Compiler-Filter kompiliert.
    Konfigurierbar über PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (siehe weiter unten in diesem Dokument).
  • Produktspezifische Kernanwendungen (siehe PRODUCT_DEXPREOPT_SPEED_APPS in diesem Dokument): standardmäßig mit dem speed Compiler-Filter kompiliert.
  • Alle anderen Anwendungen: standardmäßig mit dem speed-profile Compilerfilter kompiliert oder mit dem verify -Compilerfilter kompiliert, wenn kein Profil bereitgestellt wird.

    Konfigurierbar über PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (siehe weiter unten in diesem Dokument).

Makefile-Optionen

  • WITH_DEXPREOPT

    • Ob dex2oat auf DEX-Code aufgerufen wird, der auf dem Systemabbild installiert ist. Standardmäßig aktiviert.

  • DONT_DEXPREOPT_PREBUILTS (seit Android 5)

    • Durch Aktivieren von DONT_DEXPREOPT_PREBUILTS verhindert, dass die vorgefertigten Elemente vorab optimiert werden. Dies sind Apps, für die in ihrer Android.mk include $(BUILD_PREBUILT) angegeben ist. Das Überspringen der Voroptimierung von vorgefertigten Apps, die wahrscheinlich über Google Play aktualisiert werden, spart Platz im Systemabbild, verlängert jedoch die Zeit für den ersten Start. Beachten Sie, dass diese Option keine Auswirkungen auf vorgefertigte Apps hat, die in Android.bp definiert sind.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (seit Android 9)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER gibt den standardmäßigen Compiler-Filter für voroptimierte Anwendungen an. Diese Apps sind in Android.bp definiert oder include $(BUILD_PREBUILT) in ihrer Android.mk . Wenn nicht angegeben, ist der Standardwert speed-profile , oder verify ob der Wert nicht angegeben ist und kein Profil bereitgestellt wird.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (neu in Android 8 MR1)

    • Das Aktivieren WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY optimiert nur den Boot-Klassenpfad und die Systemserver-JAR-Dateien vorab.

  • LOCAL_DEX_PREOPT

    • Die Voroptimierung kann auch auf individueller App-Basis aktiviert oder deaktiviert werden, indem die Option LOCAL_DEX_PREOPT in der Moduldefinition angegeben wird. Dies kann nützlich sein, um die Voroptimierung von Apps zu deaktivieren, die möglicherweise sofort Google Play-Updates erhalten, da die Updates den voroptimierten Code im Systemabbild überflüssig machen würden. Dies ist auch nützlich, um Platz bei OTAs für Hauptversions-Upgrades zu sparen, da Benutzer möglicherweise bereits neuere Versionen von Apps in der Datenpartition haben.

    LOCAL_DEX_PREOPT unterstützt die Werte „true“ oder „false“, um die Voroptimierung zu aktivieren bzw. zu deaktivieren. Außerdem kann „Nostripping“ angegeben werden, wenn die classes.dex die Datei „classes.dex“ nicht aus der APK- oder JAR-Datei entfernen soll. Normalerweise wird diese Datei entfernt, da sie nach der Voroptimierung nicht mehr benötigt wird, aber diese letzte Option ist notwendig, 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. Es kann verwendet werden, um angepasste Bildklassenlisten, kompilierte Klassenlisten und Compilerfilter anzugeben.

  • 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

    • Bietet die Möglichkeit, dex2oat Optionen für ein bestimmtes Modul und eine bestimmte Produktkonfiguration zu übergeben. Es wird in der device.mk -Datei eines Produkts durch $(call add-product-dex-preopt-module-config,<modules>,<option>) festgelegt, wobei <modules> eine Liste von LOCAL_MODULE- und LOCAL_PACKAGE-Namen für JAR und APK ist Dateien bzw.

  • PRODUCT_DEXPREOPT_SPEED_APPS (New in Android 8)

    • Liste der Anwendungen, die als Kern der Produkte identifiziert wurden und die mit dem speed Compiler-Filter kompiliert werden sollten. Beispielsweise erhalten dauerhafte Apps wie SystemUI nur beim nächsten Neustart die Möglichkeit, die profilgeführte Kompilierung zu verwenden, sodass es für das Produkt möglicherweise besser ist, diese Apps immer AOT-kompiliert zu haben.

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android 8)

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

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android 8)

    • Ob eine Debug-Version von ART auf dem Gerät enthalten sein soll. Standardmäßig ist dies für Userdebug- und Eng-Builds aktiviert. Das Verhalten kann überschrieben werden, indem die Option explizit auf true oder false gesetzt wird.

    Standardmäßig verwendet das Gerät die Nicht-Debug-Version ( libart.so ). Setzen Sie zum Umschalten die Systemeigenschaft persist.sys.dalvik.vm.lib.2 auf libartd.so .

  • WITH_DEXPREOPT_PIC (Removed in Android 8)

    • In Android 5.1.0 bis Android 6.0.1 kann WITH_DEXPREOPT_PIC angegeben werden, um positionsunabhängigen Code (PIC) zu aktivieren. Damit muss kompilierter Code aus dem Image nicht von /system nach /data/dalvik-cache verschoben werden, was Platz in der Datenpartition spart. Es gibt jedoch eine geringfügige Auswirkung auf die Laufzeit, da eine Optimierung deaktiviert wird, die positionsabhängigen Code nutzt. Normalerweise sollten Geräte, die Platz in /data sparen möchten, die PIC-Kompilierung aktivieren.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (in Android 8 MR1 entfernt)

    • Diese Option wurde durch WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY ersetzt, das auch die Systemserver-JAR-Dateien vorwählt.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Diese Option gibt den Compilerfilter für den Systemserver an.

    • (seit Android 14 (AOSP experimentell)) Wenn nicht angegeben, wird der speed-profile Compilerfilter verwendet, oder der speed wird verwendet, wenn kein Profil bereitgestellt wird.
    • (bis Android 13) Wenn nicht angegeben, wird der speed Compiler-Filter verwendet.
    • Wenn es auf speed gesetzt ist, wird der speed Compiler-Filter verwendet.
    • Wenn es auf speed-profile gesetzt ist, wird der Compiler-Filter „ speed-profile “ verwendet, oder der Compiler-Filter verify “, wenn kein Profil bereitgestellt wird.
    • Wenn sie auf verify gesetzt ist, wird der verify -Compiler-Filter verwendet.

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • Das Folgende sind Listen von JAR-Dateien, die vom Systemserver geladen werden. Die JAR-Dateien werden mit dem durch PRODUCT_SYSTEM_SERVER_COMPILER_FILTER angegebenen Compilerfilter kompiliert

    • (erforderlich) PRODUCT_SYSTEM_SERVER_JARS : Liste der Klassenpfad-JAR-Dateien des Systemservers auf der Plattform (dh als Teil von SYSTEMSERVERCLASSPATH ). Das Hinzufügen von Klassenpfad-JAR-Dateien des Systemservers zu dieser Liste ist erforderlich. Wenn Klassenpfad-JAR-Dateien des Systemservers nicht zur Liste hinzugefügt werden, werden diese JAR-Dateien nicht geladen.
    • (erforderlich) PRODUCT_APEX_SYSTEM_SERVER_JARS : Liste der Klassenpfad-JAR-Dateien des Systemservers, die über Apex geliefert werden (dh als Teil von SYSTEMSERVERCLASSPATH ). Das Format ist <apex name>:<jar name> . Das Hinzufügen von Klassenpfad-JAR-Dateien des Apex-Systemservers zu dieser Liste ist erforderlich. Wenn Apex-Systemserver-Klassenpfad-JAR-Dateien nicht zu dieser Liste hinzugefügt werden, werden diese JAR-Dateien nicht geladen.
    • (optional, seit Android 13) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : Liste der JAR-Dateien, die der Systemserver mithilfe separater Classloader (über SystemServiceManager.startServiceFromJar ) dynamisch lädt. Das Hinzufügen von eigenständigen Systemserver-JAR-Dateien zu dieser Liste ist nicht erforderlich, wird jedoch dringend empfohlen, da die JAR-Dateien dadurch kompiliert werden und daher eine gute Laufzeitleistung aufweisen.
    • (erforderlich, seit Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : Liste der über Apex bereitgestellten JAR-Dateien, die der Systemserver dynamisch mit separaten Classloadern lädt (z. B. über SystemServiceManager.startServiceFromJar oder als <apex-system-service> deklariert). Das Format ist <apex name>:<jar name> . Das Hinzufügen von eigenständigen Apex-Systemserver-JARs zu dieser Liste ist erforderlich. Wenn dieser Liste keine eigenständigen Apex-Systemserver-JAR-Dateien hinzugefügt werden, führt dies zu einem Startfehler.

    Boot-Classpath-Konfiguration

    • Vorinstallierte Klassenliste

      • Die vorgeladene Klassenliste ist eine Liste von Klassen, die die Zygote beim Start initialisiert. Dadurch muss jede App diese Klasseninitialisierer nicht separat ausführen, sodass sie schneller gestartet und Seiten im Arbeitsspeicher gemeinsam genutzt werden können. Die Listendatei der vorinstallierten Klassen befindet sich standardmäßig unter frameworks/base/config/preloaded-classes und enthält eine Liste, die für die typische Telefonnutzung optimiert ist. Dies kann bei anderen Geräten wie Wearables anders sein und muss entsprechend abgestimmt werden. Seien Sie vorsichtig, wenn Sie dies tunen; Das Hinzufügen zu vieler Klassen verschwendet Speicherplatz, wenn nicht verwendete Klassen geladen werden. Wenn zu wenige Klassen hinzugefügt werden, muss jede App ihre eigene Kopie haben, was wiederum Speicherplatz verschwendet.

      Beispielverwendung (in der Datei „device.mk“ des Produkts):

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

      Hinweis: Diese Zeile muss platziert werden, bevor Produktkonfigurations-Makefiles geerbt werden, die das Standard-Makefile von: 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: ob JIT aktiviert ist oder nicht.
    • dalvik.vm.jitinitialsize (Standard 64 KB): die anfängliche Kapazität des Code-Cache. Der Code-Cache wird regelmäßig GC und bei Bedarf erhöht.
    • dalvik.vm.jitmaxsize (Standard 64 MB): die maximale Kapazität des Code-Cache.
    • dalvik.vm.jitthreshold: (Standard 10000) – Dies ist der Schwellenwert, den der „Hotness“-Zähler einer Methode überschreiten muss, damit die Methode JIT-kompiliert wird. Der "Hotness"-Zähler ist eine interne Metrik der Laufzeit. Es umfasst die Anzahl der Aufrufe, Rückwärtsverzweigungen und andere Faktoren.
    • dalvik.vm.usejitprofiles: ob JIT-Profile aktiviert sind oder nicht; Dies kann auch dann verwendet werden, wenn dalvik.vm.usejit falsch ist. Beachten Sie, dass, wenn dies falsch ist, das speed-profile des Compilerfilters keine AOT-Kompilierung einer Methode durchführt und äquivalent zu verify ist.
    • dalvik.vm.jitprithreadweight (standardmäßig dalvik.vm.jitthreshold / 20) – Die Gewichtung der JIT-„Samples“ (siehe jitthreshold) für den Anwendungs-UI-Thread. Wird verwendet, um die Kompilierung von Methoden zu beschleunigen, die sich direkt auf die Benutzererfahrung bei der Interaktion mit der App auswirken.
    • dalvik.vm.jittransitionweight: (standardmäßig dalvik.vm.jitthreshold / 10) die Gewichtung des Methodenaufrufs, der zwischen Kompiliercode und Interpreter wechselt. Dadurch wird sichergestellt, dass die beteiligten Methoden kompiliert werden, um Übergänge (die teuer sind) zu minimieren.

    Paket-Manager-Optionen

    Seit Android 7.0 gibt es eine generische Möglichkeit, die Ebene der Kompilierung/Verifizierung anzugeben, die in verschiedenen Phasen stattgefunden hat. Die Kompilierungsebenen können über die Systemeigenschaften konfiguriert werden, wobei die Standardwerte sind:

    • pm.dexopt.install=speed-profile

      • Dies ist der Kompilierungsfilter, der beim Installieren von Anwendungen über Google Play verwendet wird. Wir empfehlen, den Installationsfilter auf Geschwindigkeitsprofil einzustellen, um die Verwendung von Profilen aus den dex-Metadatendateien zu ermöglichen. Beachten Sie, dass, wenn ein Profil nicht bereitgestellt wird oder wenn es leer ist, das Geschwindigkeitsprofil der Überprüfung entspricht.

    • pm.dexopt.bg-dexopt=speed-profile

      • Dies ist der Kompilierungsfilter, der verwendet wird, wenn das Gerät im Leerlauf ist, aufgeladen und vollständig aufgeladen wird. Probieren Sie den speed-profile Compilerfilter aus, um die profilgeführte Kompilierung zu nutzen und Speicherplatz zu sparen.

    • pm.dexopt.boot-after-ota=verify

      • Der Kompilierungsfilter, der nach einem Over-the-Air-Update verwendet wird. Wir empfehlen dringend , den Compiler-Filter für diese Option zu verify , um sehr lange Startzeiten zu vermeiden.

    • pm.dexopt.first-boot=verify

    • Der Kompilierungsfilter zum ersten Mal, wenn das Gerät überhaupt bootet. Der hier verwendete Filter wirkt sich nur auf die Bootzeit nach Werk aus. Wir empfehlen die verify dafür, um lange Wartezeiten zu vermeiden, bis ein Benutzer das Telefon zum ersten Mal verwendet. Beachten Sie, dass pm.dexopt.first-boot keine Auswirkung hat, wenn alle Anwendungen im Systemabbild bereits mit verify , speed-profile oder speed mit dem richtigen Class Loader-Kontext kompiliert wurden.

    Dex2oat-Optionen

    Beachten Sie, dass sich diese Optionen auf dex2oat während der Kompilierung auf dem Gerät sowie während der Voroptimierung auswirken, während die meisten der oben besprochenen Optionen nur die Voroptimierung betreffen.

    So steuern dex2oat , während es das Boot-Image kompiliert:

    • dalvik.vm.image-dex2oat-Xms: anfängliche Heap-Größe
    • dalvik.vm.image-dex2oat-Xmx: maximale Heap-Größe
    • dalvik.vm.image-dex2oat-filter: Compiler-Filteroption
    • dalvik.vm.image-dex2oat-threads: Anzahl der zu verwendenden Threads

    So steuern dex2oat , während es alles außer dem Boot-Image kompiliert:

    • dalvik.vm.dex2oat-Xms: anfängliche Heap-Größe
    • dalvik.vm.dex2oat-Xmx: maximale Heap-Größe
    • dalvik.vm.dex2oat-filter: Compiler-Filteroption

    Bei Veröffentlichungen bis Android 6.0 wird eine zusätzliche Option bereitgestellt, um alles außer dem Boot-Image zu kompilieren:

    • dalvik.vm.dex2oat-threads: Anzahl der zu verwendenden Threads

    Ab Android 6.1 werden dies zwei zusätzliche Optionen, um alles außer dem Boot-Image zu kompilieren:

    • dalvik.vm.boot-dex2oat-threads: Anzahl der während des Bootvorgangs zu verwendenden Threads
    • dalvik.vm.dex2oat-threads: Anzahl der nach dem Booten zu verwendenden Threads

    Ab Android 7.1 stehen zwei Optionen zur Verfügung, um zu steuern, wie Speicher verwendet wird, wenn alles außer dem Boot-Image kompiliert wird:

    • dalvik.vm.dex2oat-very-large: minimale Gesamtgröße der dex-Datei in Bytes, um die AOT-Kompilierung zu deaktivieren
    • dalvik.vm.dex2oat-swap: dex2oat-Auslagerungsdatei verwenden (für Geräte mit wenig Speicher)

    Die Optionen, die die anfängliche und maximale Heap-Größe für dex2oat , sollten nicht reduziert werden, da sie einschränken könnten, welche Anwendungen kompiliert werden können.

    Ab Android 11 werden drei CPU-Affinitätsoptionen bereitgestellt, um zu ermöglichen, dass Compiler-Threads auf eine bestimmte Gruppe von CPUs beschränkt werden:

    • dalvik.vm.boot-dex2oat-cpu-set: CPUs, die während des Bootens dex2oat-Threads ausführen
    • dalvik.vm.image-dex2oat-cpu-set: CPUs, auf denen dex2oat ausgeführt wird, während das Boot-Image kompiliert wird
    • dalvik.vm.dex2oat-cpu-set: CPUs, die nach dem Booten dex2oat-Threads ausführen

    Die CPUs sollten als durch Kommas getrennte Liste von CPU-IDs angegeben werden. Um beispielsweise auf den CPUs 0-3 auf dex2oat zu laufen, setzen Sie:

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

    Beim Festlegen der CPU-Affinitätseigenschaften empfehlen wir, die entsprechende Eigenschaft für die Anzahl der dex2oat-Threads an die Anzahl der ausgewählten CPUs anzupassen, um unnötige Speicher- und E/A-Konflikte zu vermeiden:

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

    Ab Android 12 wurden die folgenden Optionen hinzugefügt:

    • dalvik.vm.ps-min-first-save-ms: Die Zeit, die darauf gewartet werden muss, dass die Laufzeit ein Profil der Anwendung generiert, wenn die Anwendung zum ersten Mal gestartet wird
    • dalvik.vm.ps-min-save-period-ms: die Mindestzeit, die gewartet werden muss, bevor das Profil einer App aktualisiert wird
    • dalvik.vm.systemservercompilerfilter: Der Compiler-Filter, den das Gerät beim Neukompilieren des Systemservers verwendet

    A/B-spezifische Konfiguration

    ROM-Konfiguration

    Ab Android 7.0 können Geräte zwei Systempartitionen verwenden, um A/B- Systemupdates zu aktivieren . Um die Größe der Systempartition zu sparen, können die voreingestellten Dateien auf der ungenutzten zweiten Systempartition installiert werden. Sie werden dann beim ersten Booten auf die Datenpartition kopiert.

    Beispielverwendung (in device-common.mk ):

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

    Und in BoardConfig.mk des Geräts:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Beachten Sie, dass Boot-Klassenpfadcode, Systemservercode und produktspezifische Kernanwendungen immer auf der Systempartition kompiliert werden. Standardmäßig werden alle anderen Anwendungen auf die unbenutzte zweite Systempartition kompiliert. Dies kann mit dem SYSTEM_OTHER_ODEX_FILTER gesteuert werden, der standardmäßig einen Wert von hat:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Hintergrund dexopt OTA

    Bei A/B-fähigen Geräten können Anwendungen im Hintergrund kompiliert werden, um sie auf das neue Systemabbild zu aktualisieren. Siehe App-Kompilierung im Hintergrund , um optional das Kompilierungsskript und die Binärdateien in das Systemabbild aufzunehmen. Der für diese Zusammenstellung verwendete Kompilierungsfilter wird gesteuert mit:

    pm.dexopt.ab-ota=speed-profile

    Wir empfehlen die Verwendung von speed-profile , um die Vorteile der profilgeführten Kompilierung zu nutzen und Speicherplatz zu sparen.