Konfiguracja ART

Na tej stronie omówiono sposób konfiguracji ART i jego opcji kompilacji. Omawiane tutaj tematy obejmują konfigurację wstępnej kompilacji obrazu systemu, opcje kompilacji dex2oat oraz sposoby kompromisu między przestrzenią partycji systemowej, przestrzenią partycji danych i wydajnością.

Zobacz ART i Dalvik , format Dalvik Executable i pozostałe strony na source.android.com, aby pracować z ART. Zobacz Weryfikacja zachowania aplikacji w środowisku wykonawczym systemu Android (ART), aby upewnić się, że aplikacje działają prawidłowo.

Jak działa SZTUKA

ART korzysta z kompilacji z wyprzedzeniem (AOT), a począwszy od systemu Android 7, korzysta z hybrydowej kombinacji kompilacji AOT, kompilacji just-in-time (JIT) i interpretacji, a kompilacja AOT może być sterowana profilem. Kombinację wszystkich tych trybów wykonania można konfigurować i zostanie ona omówiona w tej sekcji. Przykładowo urządzenia Pixel są skonfigurowane do pracy w następującym trybie:

  1. Aplikacja jest początkowo instalowana z plikiem metadanych dex ( .dm ) rozpowszechnianym przez Sklep Play, który zawiera profil w chmurze. ART AOT-kompiluje metody wymienione w profilu chmury. Lub, jeśli aplikacja jest zainstalowana bez pliku metadanych dex, nie jest wykonywana żadna kompilacja AOT.
  2. Przy pierwszych kilku uruchomieniach aplikacji interpretowane są metody, które nie są skompilowane przy użyciu narzędzia AOT. Spośród interpretowanych metod te, które są często wykonywane, są następnie kompilowane w JIT. ART generuje profil lokalny na podstawie wykonania i łączy go z profilem w chmurze (jeśli taki istnieje).
  3. Gdy urządzenie jest bezczynne i ładuje się, uruchamiany jest demon kompilacji, który ponownie kompiluje aplikację na podstawie połączonego profilu wygenerowanego podczas kilku pierwszych uruchomień.
  4. W kolejnych uruchomieniach aplikacji ART wykorzystuje artefakty wygenerowane przez demona kompilacji, które zawierają więcej kodu skompilowanego za pomocą narzędzia AOT w porównaniu z artefaktami wygenerowanymi podczas metod, które nie są skompilowane za pomocą narzędzia AOT, są nadal interpretowane lub kompilowane za pomocą JIT. ART aktualizuje instalację profilu na podstawie wykonania, a profil zostanie następnie pobrany przez kolejne uruchomienia demona kompilacji.

ART składa się z kompilatora (narzędzie dex2oat ) i środowiska wykonawczego ( libart.so ), które jest ładowane podczas rozruchu. Narzędzie dex2oat pobiera plik APK i generuje jeden lub więcej plików artefaktów kompilacji, które ładuje środowisko wykonawcze. Liczba plików, ich rozszerzenia i nazwy mogą się zmieniać w zależności od wersji, ale od wersji Androida 8 generowane są następujące pliki:

  • .vdex : zawiera dodatkowe metadane przyspieszające weryfikację, czasami wraz z nieskompresowanym kodem DEX pakietu APK.
  • .odex : zawiera skompilowany przez AOT kod metod w pliku APK.
  • .art (optional) : zawiera wewnętrzne reprezentacje ART niektórych ciągów i klas wymienionych w pliku APK, używane do przyspieszania uruchamiania aplikacji.

Opcje kompilacji

Opcje kompilacji dla ART dzielą się na dwie kategorie:

  1. Konfiguracja systemowej pamięci ROM: jaki kod jest kompilowany przez AOT podczas budowania obrazu systemu.
  2. Konfiguracja środowiska wykonawczego: jak ART kompiluje i uruchamia aplikacje na urządzeniu.

Filtry kompilatora

Jedną z podstawowych opcji ART umożliwiających skonfigurowanie tych dwóch kategorii są filtry kompilatora . Filtry kompilatora sterują sposobem, w jaki ART kompiluje kod DEX i są opcją przekazywaną do narzędzia dex2oat . Począwszy od Androida 8, istnieją cztery oficjalnie obsługiwane filtry:

  • verify : uruchamiaj tylko weryfikację kodu DEX (bez kompilacji AOT).
  • quicken : (do Androida 11) uruchom weryfikację kodu DEX i zoptymalizuj niektóre instrukcje DEX, aby uzyskać lepszą wydajność interpretera.
  • speed : uruchom weryfikację kodu DEX i skompiluj wszystkie metody AOT.
  • speed-profile : uruchom weryfikację kodu DEX i metody kompilacji AOT wymienione w pliku profilu.

Konfiguracja systemowej pamięci ROM

Wstępnie zainstalowane biblioteki i aplikacje są kompilowane metodą AOT podczas tworzenia obrazu systemu. Proces ten nazywa się dexpreopt .

Dostępnych jest wiele opcji kompilacji ART do konfiguracji dexpreopt. Sposób skonfigurowania tych opcji zależy od dostępnej przestrzeni dyskowej dla obrazu systemu i liczby preinstalowanych aplikacji. Pliki JAR/APK skompilowane w systemową pamięć ROM można podzielić na cztery kategorie:

  • Kod ścieżki klasy rozruchowej: domyślnie skompilowany z filtrem kompilatora speed-profile .
  • Kod serwera systemowego (patrz PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS w dalszej części tego dokumentu):
    • (od Androida 14) domyślnie skompilowany z filtrem kompilatora speed-profile lub skompilowany z filtrem kompilatora speed , jeśli profil nie jest dostępny.
    • (do Androida 13) domyślnie skompilowany z filtrem kompilatora speed .
    Konfigurowalne poprzez PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (patrz dalej w tym dokumencie).
  • Podstawowe aplikacje specyficzne dla produktu (patrz PRODUCT_DEXPREOPT_SPEED_APPS w dalszej części tego dokumentu): domyślnie skompilowane z filtrem kompilatora speed .
  • Wszystkie inne aplikacje: domyślnie skompilowane z filtrem kompilatora speed-profile lub skompilowane z filtrem kompilatora verify , jeśli profil nie jest dostępny.

    Konfigurowalne poprzez PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (patrz dalej w tym dokumencie).

Opcje pliku Makefile

  • WITH_DEXPREOPT

    • Określa, czy dex2oat jest wywoływany w kodzie DEX zainstalowanym w obrazie systemu. Domyślnie włączone.

  • DONT_DEXPREOPT_PREBUILTS (od Androida 5)

    • Włączenie DONT_DEXPREOPT_PREBUILTS zapobiega dexpreopcji gotowych kompilacji. Są to aplikacje, które include $(BUILD_PREBUILT) określone w pliku Android.mk . Pomijanie opcji dexpreopt gotowych aplikacji, które prawdopodobnie zostaną zaktualizowane za pośrednictwem Google Play, oszczędza miejsce w obrazie systemu, ale wydłuża czas pierwszego uruchomienia. Należy pamiętać, że ta opcja nie ma wpływu na gotowe aplikacje zdefiniowane w Android.bp .

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (od Androida 9)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER określa domyślny filtr kompilatora dla aplikacji z opcją dexpreopted. Te aplikacje są zdefiniowane w Android.bp lub include $(BUILD_PREBUILT) określone w pliku Android.mk . Jeśli nie określono, wartością domyślną jest speed-profile lub verify , czy wartość nie jest określona i nie podano profilu.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (od Androida 8 MR1)

    • Włączenie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY powoduje, że dexpreopcja dotyczy tylko ścieżki klas rozruchowych i plików jar serwera systemowego.

  • LOCAL_DEX_PREOPT

    • Dexpreopt można także włączyć lub wyłączyć dla poszczególnych aplikacji, określając opcję LOCAL_DEX_PREOPT w definicji modułu. Może to być przydatne do wyłączania dexpreopt aplikacji, które mogą natychmiast otrzymywać aktualizacje Google Play, ponieważ aktualizacje spowodowałyby, że kod dexpreopt w obrazie systemu stałby się przestarzały. Jest to również przydatne, aby zaoszczędzić miejsce na głównych aktualizacjach OTA, ponieważ użytkownicy mogą już mieć nowsze wersje aplikacji na partycji danych.

    LOCAL_DEX_PREOPT obsługuje wartości „true” lub „false”, aby odpowiednio włączyć lub wyłączyć dexpreopt. Ponadto można określić opcję „nostripping”, jeśli dexpreopt nie powinien usuwać classes.dex z pliku APK lub JAR. Zwykle ten plik jest usuwany, ponieważ nie jest już potrzebny po dexpreopt, ale ta ostatnia opcja jest konieczna, aby podpisy plików APK innych firm pozostały ważne.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Przekazuje opcje do dex2oat w celu kontrolowania sposobu kompilacji obrazu rozruchowego. Można go używać do określania niestandardowych list klas obrazów, list skompilowanych klas i filtrów kompilatora.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Przekazuje opcje do dex2oat w celu kontrolowania sposobu kompilowania wszystkiego poza obrazem startowym.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Zapewnia możliwość przekazywania opcji dex2oat dla konkretnej konfiguracji modułu i produktu. Jest ona ustawiana w pliku device.mk produktu za pomocą $(call add-product-dex-preopt-module-config,<modules>,<option>) gdzie <modules> to lista nazw LOCAL_MODULE i LOCAL_PACKAGE dla plików JAR i APK odpowiednio pliki.

  • PRODUCT_DEXPREOPT_SPEED_APPS (od Androida 8)

    • Lista aplikacji, które zostały zidentyfikowane jako podstawowe produkty i które należy skompilować za pomocą filtra kompilatora speed . Na przykład trwałe aplikacje, takie jak SystemUI, mają szansę skorzystać z kompilacji opartej na profilu dopiero przy następnym ponownym uruchomieniu komputera, dlatego może być lepszym rozwiązaniem, jeśli produkt będzie zawsze kompilowany przy użyciu narzędzia AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (od Androida 8)

    • Lista aplikacji ładowanych przez serwer systemu. Aplikacje te są domyślnie kompilowane z filtrem kompilatora speed .

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (od Androida 8)

    • Określa, czy na urządzeniu ma znajdować się wersja debugowana ART. Domyślnie jest to włączone w przypadku debugowania użytkownika i kompilacji eng. Zachowanie można zastąpić, jawnie ustawiając opcję na true lub false .

    Domyślnie urządzenie korzysta z wersji bez debugowania ( libart.so ). Aby przełączyć, ustaw właściwość systemową persist.sys.dalvik.vm.lib.2 na libartd.so .

  • WITH_DEXPREOPT_PIC (do Androida 7)

    • W systemie Android od 5.1.0 do 6.0.1 można określić opcję WITH_DEXPREOPT_PIC , aby włączyć kod niezależny od pozycji (PIC). Dzięki temu skompilowany kod z obrazu nie musi być przenoszony z /system do /data/dalvik-cache, oszczędzając miejsce na partycji danych. Ma to jednak niewielki wpływ na czas wykonania, ponieważ wyłącza optymalizację wykorzystującą kod zależny od pozycji. Zazwyczaj urządzenia chcące zaoszczędzić miejsce w /data powinny włączyć kompilację PIC.

    W systemie Android 7.0 kompilacja PIC była domyślnie włączona.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (do Androida 7 MR1)

    • Ta opcja została zastąpiona opcją WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, która również wstępnie wybiera pliki jar serwera systemowego.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Ta opcja określa filtr kompilatora dla serwera systemowego.

    • (od Androida 14) Jeśli nie określono, używany jest filtr kompilatora speed-profile lub filtr kompilatora speed , jeśli profil nie jest dostępny.
    • (do Androida 13) Jeśli nie określono, używany jest filtr kompilatora speed .
    • Jeśli ustawiono na speed , używany jest filtr kompilatora speed .
    • Jeśli jest ustawiony na speed-profile , używany jest filtr kompilatora speed-profile lub filtr kompilatora verify , jeśli profil nie jest podany.
    • Jeśli ustawione na verify , używany jest filtr kompilatora verify .

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • Poniżej znajdują się listy słoików ładowanych przez serwer systemowy. Słoiki są kompilowane przy użyciu filtra kompilatora określonego przez PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (wymagane) PRODUCT_SYSTEM_SERVER_JARS : Lista słoików ścieżek klas serwera systemowego na platformie (tj. jako część SYSTEMSERVERCLASSPATH ). Wymagane jest dodanie słoików ścieżek klas serwera systemowego do tej listy. Niedodanie słoików ze ścieżką klas serwera systemowego do listy spowoduje, że te słoiki nie zostaną załadowane.
    • (wymagane) PRODUCT_APEX_SYSTEM_SERVER_JARS : Lista słoików ścieżki klas serwera systemowego dostarczanych przez apex (tj. jako część SYSTEMSERVERCLASSPATH ). Format to <apex name>:<jar name> . Wymagane jest dodanie słoików ścieżek klas serwera Apex do tej listy. Niedodanie słoików ze ścieżką klas serwera systemu Apex do tej listy spowoduje, że te słoiki nie zostaną załadowane.
    • (opcjonalne, od wersji Androida 13) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : Lista słoików ładowanych dynamicznie przez serwer systemowy przy użyciu oddzielnych modułów ładujących klasy (poprzez SystemServiceManager.startServiceFromJar ). Dodanie samodzielnych słoików serwera systemowego do tej listy nie jest wymagane, ale zdecydowanie zalecane, ponieważ powoduje to kompilację słoików, a zatem dobrą wydajność środowiska wykonawczego.
    • (wymagane, od Androida 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : Lista słoików dostarczanych przez apex, które serwer systemowy ładuje dynamicznie przy użyciu oddzielnych modułów ładujących klasy (tj. poprzez SystemServiceManager.startServiceFromJar lub zadeklarowanych jako <apex-system-service> ). Format to <apex name>:<jar name> . Wymagane jest dodanie do tej listy samodzielnych słoików serwera systemu Apex. Niedodanie samodzielnych słoików serwera systemu Apex do tej listy spowoduje błąd rozruchu.

    Konfiguracja ścieżki klas rozruchowych

    • Wstępnie załadowana lista zajęć

      • Wstępnie załadowana lista klas to lista klas, które zygota inicjuje podczas uruchamiania. Dzięki temu każda aplikacja nie musi oddzielnie uruchamiać inicjatorów klas, co pozwala im szybciej uruchamiać się i udostępniać strony w pamięci. Plik listy wstępnie załadowanych klas znajduje się domyślnie w frameworks/base/config/preloaded-classes i zawiera listę dostosowaną do typowego użycia telefonu. Może się to różnić w przypadku innych urządzeń, takich jak urządzenia do noszenia, i należy je odpowiednio dostroić. Zachowaj ostrożność podczas dostrajania tego; dodanie zbyt wielu klas marnuje pamięć, gdy ładowane są nieużywane klasy. Dodanie zbyt małej liczby klas zmusza każdą aplikację do posiadania własnej kopii, co ponownie marnuje pamięć.

      Przykładowe użycie (w pliku urządzenia.mk):

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

      Uwaga: tę linię należy umieścić przed dziedziczeniem plików makefile konfiguracji produktu, które otrzymają plik domyślny z: build/target/product/base.mk

    Konfiguracja środowiska wykonawczego

    Opcje JIT

    Poniższe opcje dotyczą wersji Androida tylko wtedy, gdy dostępny jest kompilator ART JIT.

    • dalvik.vm.usejit : Określa, czy JIT jest włączony.
    • dalvik.vm.jitinitialsize (domyślnie 64 KB): Początkowa pojemność pamięci podręcznej kodu. Pamięć podręczna kodu będzie regularnie GC i zwiększana w razie potrzeby.
    • dalvik.vm.jitmaxsize (domyślnie 64M): Maksymalna pojemność pamięci podręcznej kodu.
    • dalvik.vm.jitthreshold (domyślnie 10000): Próg, który musi przekroczyć licznik „gorącej” metody, aby metoda mogła zostać skompilowana za pomocą JIT. Licznik „gorącej temperatury” jest metryką wewnętrzną środowiska wykonawczego. Obejmuje liczbę połączeń, rozgałęzień wstecznych i inne czynniki.
    • dalvik.vm.usejitprofiles (do Androida 13): czy włączone są profile JIT; można tego użyć nawet jeśli dalvik.vm.usejit ma wartość false. Należy zauważyć, że jeśli wartość ta jest fałszywa, speed-profile filtra kompilatora nie kompiluje żadnej metody AOT i jest równoważny verify . Od wersji Androida 14 profile JIT są zawsze włączone i nie można ich wyłączyć.
    • dalvik.vm.jitprithreadweight (domyślnie dalvik.vm.jitthreshold / 20): waga „próbek” JIT (patrz jitthreshold) dla wątku interfejsu użytkownika aplikacji. Użyj, aby przyspieszyć kompilację metod, które bezpośrednio wpływają na wygodę użytkownika podczas interakcji z aplikacją.
    • dalvik.vm.jittransitionweight (domyślnie dalvik.vm.jitthreshold / 10): Waga wywołania metody, która przechodzi między kodem kompilacji a interpreterem. Pomaga to upewnić się, że stosowane metody są skompilowane w celu zminimalizowania przejść (które są kosztowne).

    Opcje Dex2oat

    Opcje te wpływają na kompilację na urządzeniu (inaczej dexopt ), a kilka z nich wpływa również na dexpreopt, podczas gdy opcje omówione powyżej w sekcji Konfiguracja systemowej pamięci ROM wpływają tylko na dexpreopt.

    Opcje kontroli wykorzystania zasobów:

    • dalvik.vm.image-dex2oat-threads / dalvik.vm.image-dex2oat-cpu-set (do Androida 11): liczba wątków i zestaw rdzeni procesora (patrz poniżej) używanych do obrazów rozruchowych.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (do Androida 11) Liczba wątków i zestaw rdzeni procesora (patrz poniżej), które mają być używane podczas rozruchu do wszystkiego innego niż obrazy rozruchowe.
      • (od Androida 12) Liczba wątków i zestaw rdzeni procesora (patrz poniżej), które mają być używane podczas rozruchu do wszystkiego, łącznie z obrazami rozruchowymi.
        • W szczególności od Androida 14 odpowiada to klasie priorytetu PRIORITY_BOOT w usłudze ART.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (od Androida 11 do Androida 13) Liczba wątków i zestaw rdzeni procesora (patrz poniżej) używanych do przywracania z kopii zapasowej w chmurze.
      • (od Androida 14) Liczba wątków i zestaw rdzeni procesora (patrz poniżej), które można wykorzystać do wszystkiego, co jest bardziej wrażliwe na opóźnienia niż zwykle, w tym do przywracania z kopii zapasowej w chmurze.
        • W szczególności odpowiada to klasie priorytetu PRIORITY_INTERACTIVE_FAST w usłudze ART.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (od Androida 14): liczba wątków i zestaw rdzeni procesora (patrz poniżej), które mają być używane w tle.
      • W szczególności odpowiada to klasie priorytetu PRIORITY_BACKGROUND w usłudze ART.
    • dalvik.vm.dex2oat-threads / dalvik.vm.dex2oat-cpu-set : Liczba wątków i zestaw rdzeni procesora używanych do wszystkich innych zadań.

    Zestaw rdzeni procesora należy określić jako listę identyfikatorów procesora oddzielonych przecinkami. Na przykład, aby uruchomić na dex2oat na rdzeniach procesora 0-3, ustaw:

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

    Podczas ustawiania właściwości powinowactwa procesora zalecamy dopasowanie odpowiedniej właściwości liczby wątków dex2oat do liczby wybranych procesorów, aby uniknąć niepotrzebnej rywalizacji o pamięć i we/wy:

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

    Oprócz powyższych właściwości systemu można także używać profili zadań do kontrolowania wykorzystania zasobów dex2oat (zobacz Warstwa abstrakcji grupy Cgroup ).

    Obsługiwane profile zadań to:

    • Dex2OatBackground (od Androida 14) (domyślnie dziedziczy Dex2OatBootComplete ): kontroluje zasoby, które mają być używane w tle.
      • W szczególności odpowiada to klasie priorytetu PRIORITY_BACKGROUND w usłudze ART.
    • Dex2OatBootComplete :
      • (do Androida 13) Kontroluje zasoby używane do wszystkiego po uruchomieniu.
      • (od Androida 14) Kontroluje zasoby używane do wszystkiego po uruchomieniu, a nie w tle.
        • W szczególności odpowiada to klasie priorytetu PRIORITY_INTERACTIVE_FAST i PRIORITY_INTERACTIVE w usłudze ART.

    Jeśli zostaną określone zarówno właściwości systemu, jak i profile zadań, oba zaczną obowiązywać.

    Opcje kontrolowania rozmiaru sterty:

    • dalvik.vm.image-dex2oat-Xms : Początkowy rozmiar sterty dla obrazów rozruchowych.
    • dalvik.vm.image-dex2oat-Xmx : Maksymalny rozmiar sterty dla obrazów rozruchowych.
    • dalvik.vm.dex2oat-Xms : Początkowy rozmiar sterty dla wszystkiego innego.
    • dalvik.vm.dex2oat-Xmx : Maksymalny rozmiar sterty dla wszystkiego innego.

    Nie należy zmniejszać opcji kontrolujących początkowy i maksymalny rozmiar sterty dla dex2oat , ponieważ mogą one ograniczać liczbę aplikacji, które można skompilować.

    Opcje sterujące filtrem kompilatora:

    • dalvik.vm.image-dex2oat-filter (do wersji Androida 11): filtr kompilatora dla obrazów rozruchowych. Od wersji Androida 12 filtr kompilatora dla obrazów rozruchowych ma zawsze speed-profile i nie można go zmienić.
    • dalvik.vm.systemservercompilerfilter (od Androida 13): filtr kompilatora dla serwera systemowego. Zobacz PRODUCT_SYSTEM_SERVER_COMPILER_FILTER .
    • dalvik.vm.systemuicompilerfilter (od Androida 13): filtr kompilatora dla pakietu System UI.
    • dalvik.vm.dex2oat-filter (do Androida 6): filtr kompilatora do wszystkiego innego.
    • pm.dexopt.<reason> (od Androida 7): Filtr kompilatora do wszystkiego innego. Zobacz Konfiguracja usługi ART dla Androida 14 i nowszych lub Konfiguracja Menedżera pakietów dla Androida 13 i starszych.

    Inne opcje kontrolowania kompilacji wszystkiego innego niż obrazy rozruchowe:

    • dalvik.vm.dex2oat-very-large (od wersji Androida 7.1): Minimalny całkowity rozmiar pliku dex w bajtach umożliwiający wyłączenie kompilacji AOT.
    • dalvik.vm.dex2oat-swap (od Androida 7.1) (domyślnie: true): Umożliwia użycie pliku wymiany dla dex2oat. Pomoże to uniknąć awarii związanych z brakiem pamięci. Należy pamiętać, że nawet jeśli ta opcja jest włączona, dex2oat użyje pliku wymiany tylko pod pewnymi warunkami, np. gdy liczba plików dex jest duża, a warunki mogą ulec zmianie.
    • dalvik.vm.ps-min-first-save-ms (od wersji Androida 12): Minimalny czas oczekiwania, zanim środowisko wykonawcze wygeneruje profil aplikacji przy pierwszym uruchomieniu aplikacji.
    • dalvik.vm.ps-min-save-period-ms (od Androida 12): Minimalny czas oczekiwania przed aktualizacją profilu aplikacji.
    • dalvik.vm.dex2oat64.enabled (od wersji Androida 11) (domyślnie: false): Określa, czy używać 64-bitowej wersji dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (od Androida 12) (domyślnie: 20): Minimalny procent nowych klas w profilu, od 0 do 100, powodujący ponowną kompilację. Ma zastosowanie tylko do kompilacji opartej na profilu ( speed-profile ), zazwyczaj podczas dexoptu w tle. Należy pamiętać, że oprócz progu procentowego istnieje również próg wynoszący co najmniej 50 nowych klas i nie można go konfigurować.
    • dalvik.vm.bgdexopt.new-methods-percent (od Androida 12) (domyślnie: 20): Minimalny procent (od 0 do 100) nowych metod w profilu, które powodują ponowną kompilację. Ma zastosowanie tylko do kompilacji opartej na profilu ( speed-profile ), zazwyczaj podczas dexoptu w tle. Należy pamiętać, że oprócz progu procentowego istnieje również próg wynoszący co najmniej 100 nowych metod i nie można go konfigurować.
    • dalvik.vm.dex2oat-max-image-block-size (od Androida 10) (domyślnie: 524288) Maksymalny rozmiar pełnego bloku dla skompresowanych obrazów. Duży obraz jest dzielony na zestaw pełnych bloków w taki sposób, że żaden blok nie jest większy niż maksymalny rozmiar.
    • dalvik.vm.dex2oat-resolve-startup-strings (od Androida 10) (domyślnie: true) Jeśli ma wartość true, powoduje, że dex2oat rozpoznaje wszystkie const-strings, do których odwołują się metody oznaczone w profilu jako „startup”.
    • debug.generate-debug-info (domyślnie: false) Określa, czy generować informacje debugowania dla natywnego debugowania, takie jak informacje o rozwijaniu stosu, symbole ELF i sekcje karłów.
    • dalvik.vm.dex2oat-minidebuginfo (od Androida 9) (domyślnie: true) Określa, czy generować minimalną ilość informacji debugowania skompresowanych przy użyciu protokołu LZMA, niezbędnych do wydrukowania śladów wstecznych.

    Opcje usług ART

    Od wersji Androida 14 kompilacją AOT dla aplikacji (inaczej dexopt) zajmuje się usługa ART. Aby uzyskać informacje na temat konfigurowania usługi ART, zobacz Konfiguracja usługi ART .

    Opcje menedżera pakietów

    Przed wersją Androida 14 kompilacja AOT dla aplikacji (inaczej dexopt) jest obsługiwana przez menedżera pakietów. Aby uzyskać informacje na temat konfigurowania menedżera pakietów dla dexopt, zobacz Konfiguracja menedżera pakietów .

    Konfiguracja specyficzna dla A/B

    Konfiguracja ROMu

    Począwszy od Androida 7.0, urządzenia mogą korzystać z dwóch partycji systemowych, aby umożliwić aktualizacje systemu A/B . Aby zaoszczędzić na rozmiarze partycji systemowej, wstępnie wybrane pliki można zainstalować na nieużywanej drugiej partycji systemowej. Następnie są one kopiowane na partycję danych przy pierwszym uruchomieniu.

    Przykładowe użycie (w device-common.mk ):

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

    Oraz w BoardConfig.mk urządzenia:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Należy pamiętać, że kod ścieżki klasy rozruchowej, kod serwera systemowego i podstawowe aplikacje specyficzne dla produktu zawsze kompilują się do partycji systemowej. Domyślnie wszystkie pozostałe aplikacje są kompilowane na nieużywanej drugiej partycji systemowej. Można to kontrolować za pomocą SYSTEM_OTHER_ODEX_FILTER , który ma domyślnie wartość:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Tło OTA dexopt

    Na urządzeniach obsługujących A/B aplikacje można kompilować w tle przed ponownym uruchomieniem z nowym obrazem systemu. Zobacz Kompilacja aplikacji w tle , aby opcjonalnie dołączyć skrypt kompilacji i pliki binarne do obrazu systemu. Filtr kompilacji używany do tej kompilacji jest kontrolowany za pomocą:

    pm.dexopt.ab-ota=speed-profile

    Zalecamy użycie speed-profile , aby skorzystać z kompilacji sterowanej profilem i zaoszczędzić na pamięci.