Skonfiguruj ART

Na tej stronie opisujemy, jak skonfigurować środowisko wykonawcze Androida (ART) i opcje jego kompilacji. Tematy tutaj opisano konfigurację wstępnej kompilacji obrazu systemu, dex2oat opcji kompilacji oraz jak zrównoważyć miejsce na partycji systemowej, przestrzeń partycji danych skuteczność reklam.

Zapoznaj się z materiałami na temat ART i Dalvik oraz formatu wykonywalnego Dalvik dotyczącego pracy z ART. Patrz sekcja Weryfikowanie Działanie aplikacji w środowisku wykonawczym Androida (ART), aby zapewnić prawidłowe działanie aplikacji bez obaw.

Jak działa ART

ART wykorzystuje kompilację danych „przed czasem (AOT)”, a od Androida 7 korzysta z hybrydowego połączenia kompilacji AOT, kompilacji „just-in-time” (JIT) i interpretacji i kompilacji AOT można używać profilowo. Połączenie wszystkich tych trybów konfigurowalne, co zostało omówione w tej sekcji. Na przykład urządzenia Pixel są tak skonfigurowane, działać w taki sposób:

  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 dostępne w chmurze profil. lub jeśli aplikacja jest zainstalowana bez pliku metadanych .dex, kompilacja AOT nie będzie przeprowadzonych przez nas działań.
  2. Podczas kilku pierwszych uruchomień aplikacji interpretowane są metody, które nie zostały skompilowane przez AOT. Najczęściej wykonywane metody są następnie kompilowane przez kompilację JIT. Sztuka tworzy profil lokalny na podstawie wykonania i łączy go z profilem w chmurze (jeśli ).
  3. Gdy urządzenie jest nieaktywne i się ładuje, działa demon kompilacji, aby ponownie skompilować aplikację. na podstawie połączonego profilu wygenerowanego podczas pierwszych kilku uruchomień.
  4. Podczas kolejnych uruchomień aplikacji ART używa artefaktów wygenerowanych przez kompilację które zawierają więcej skompilowanego kodu AOT niż Metody, które nie zostały skompilowane przez AOT, są nadal interpretowane lub skompilowane przez JIT. ART aktualizuje profil instalacji na podstawie wykonania. Profil zostanie pobrany przy kolejnych uruchomieniach demona kompilacji.

ART obejmuje kompilator (narzędzie dex2oat) i środowisko wykonawcze (libart.so) załadowanego podczas uruchamiania. Narzędzie dex2oat pobiera plik APK i wygeneruje co najmniej 1 plik APK plików artefaktów kompilacji wczytywanych przez środowisko wykonawcze. Liczba plików, ich a nazwy mogą się zmieniać w poszczególnych wersjach, ale Android 8, generowane są te pliki:

  • .vdex: zawiera dodatkowe metadane, które przyspieszają weryfikację, czasami zawierają też nieskompresowanym kodem DEX pliku APK.
  • .odex: zawiera skompilowany kod AOT dla metod w funkcji plik APK.
  • .art (optional) zawiera wewnętrzne reklamy ART reprezentacji niektórych ciągów i klas wymienionych w pliku APK, używanych do przyspieszania działania aplikacji uruchamianie aplikacji.

Opcje kompilacji

Istnieją dwie kategorie opcji kompilacji dla ART:

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

Filtry kompilatora

Jedną z podstawowych opcji ART do skonfigurowania tych dwóch kategorii jest kompilator filtrów. Filtry kompilatora określają, jak ART kompiluje kod DEX i jest przekazano do narzędzia dex2oat. Począwszy od Androida 8, istnieją cztery oficjalnie obsługiwane filtry:

  • verify: uruchom tylko weryfikację kodu DEX (bez kompilacji AOT).
  • quicken: (do Androida 11) uruchamianie kodu DEX weryfikacji i optymalizacji niektórych instrukcji DEX, aby poprawić wydajność tłumaczenia.
  • speed: uruchom weryfikację kodu DEX i skompiluj wszystkie metody AOT.
  • speed-profile: uruchamianie metod weryfikacji kodu DEX i kompilacji AOT podane w pliku profilu.

Konfiguracja systemowej pamięci ROM

Wstępnie zainstalowane biblioteki i aplikacje są kompilowane AOT podczas tworzenia obrazu systemu. Ten nazywa się dexpreopt. Takich skompilowanych plików można używać, pod warunkiem że pozostają niezmienione, zwłaszcza w przypadku ścieżki klasy rozruchowej.

Uwaga: jeśli urządzenie modułu aktualizacji, ścieżka klasy rozruchowej będzie może ulec zmianie w następnej aktualizacji, przez co wszystkie pliki dexpreopt są nieaktualne i bezużyteczne.

Dostępnych jest wiele opcji kompilacji ART służących do konfigurowania dexpreopt. Sposób konfiguracji Zależą one od ilości dostępnego miejsca na obraz systemu oraz fabrycznie zainstalowanych aplikacji. Pliki JAR/APK, które powstaje w postaci systemowej pamięci ROM, można podzielić na cztery kategorie:

  • Kod ścieżki klasy uruchamiania: skompilowany za pomocą filtra kompilatora speed-profile za pomocą metody wartość domyślną.
  • Kod serwera systemu (zobacz PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS dalej w tym dokumencie):
    • (Android 14 i nowsze) Zgodność z speed-profile z domyślnym filtrem kompilatora lub skompilowanym z filtrem kompilatora speed, jeśli profil nie został podany.
    • (Android 13 i starsze) Kompilacja z speed kompilatora.
    . Konfigurowalne za pomocą usługi PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (zobacz później w tym dokument).
  • Podstawowe aplikacje związane z konkretnymi usługami (zobacz PRODUCT_DEXPREOPT_SPEED_APPS później w tym document (dokument): skompilowany domyślnie z filtrem kompilatora speed.
  • Wszystkie inne aplikacje: domyślnie skompilowane z filtrem kompilatora speed-profile, lub skompilować z filtrem kompilatora verify, jeśli nie podano profilu.

    Konfigurowalne za pomocą funkcji PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (zobacz później w tej sekcji dokument).

Opcje pliku Makefile

  • WITH_DEXPREOPT

    • Określa, czy funkcja dex2oat jest wywoływana po kodzie DEX zainstalowanym w obrazie systemu. Ta opcja jest domyślnie włączona.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 lub nowszy)

    • Włączenie opcji DONT_DEXPREOPT_PREBUILTS uniemożliwia tworzenie gotowych kompilacji dexpreopted. To są aplikacje z tymi usługami: include $(BUILD_PREBUILT) określone w Android.mk. Pomijanie dexpreopt gotowych aplikacji, które prawdopodobnie będą aktualizowane w Google Play. oszczędza miejsce w obrazie systemu, ale zwiększa czas pierwszego uruchomienia. Ta opcja nie ma żadnego efektu. w gotowych aplikacjach zdefiniowanych w Android.bp.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 i wyższe)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER określa domyślny filtr kompilatora dla dexpreopted. Te aplikacje są zdefiniowane w języku: Android.bp lub mają include $(BUILD_PREBUILT) określono w: Android.mk. Jeśli nie określono inaczej, wartość domyślna to speed-profile lub verify, jeśli wartość jest nieokreślona a profil nie jest podany.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (od Androida 8 MR1)

    • Włączenie opcji WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY spowoduje, że zastosujesz tylko w ścieżce rozruchowej i plikach jar serwera systemu.

  • LOCAL_DEX_PREOPT

    • Funkcję Dexpreopt można też włączyć lub wyłączyć w poszczególnych aplikacjach przez określając opcję LOCAL_DEX_PREOPT w definicji modułu. Może to być przydatne, gdy chcesz wyłączyć dexpreopt dla aplikacji, które mogą natychmiast otrzymywać aktualizacje Google Play, ponieważ spowoduje to wyrenderowanie pliku dexpreopt, w obrazie systemu jest nieaktualny. Pozwala to również zaoszczędzić miejsce na głównych aktualizacji OTA, ponieważ użytkownicy mogą już mieć nowsze wersje aplikacji partycji danych.

    Funkcja LOCAL_DEX_PREOPT obsługuje wartości true lub false do odpowiednio włączyć lub wyłączyć dexpreopt. Ponadto nostripping może jest określony, jeśli dexpreopt nie powinien usuwać parametru classes.dex z pliku APK lub JAR. Zwykle ten plik jest usuwany, ponieważ może być potrzebny dłużej po użyciu dexpreopt, ale ta ostatnia opcja jest niezbędna, pozwalają na zachowanie ważnych podpisów plików APK innych firm.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Opcje przekazywania do dex2oat umożliwiające kontrolowanie obrazu rozruchowego . Może służyć do określania niestandardowych list klas obrazów, skompilowanych a także listy klas i filtry kompilatora.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Przekazuje opcje do dex2oat, aby kontrolować sposób, w jaki wszystko oprócz jest kompilowany.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Umożliwia przekazywanie opcji dex2oat w przypadku określonej oraz konfigurację usługi. Ustawiono go w device.mk plik, którego autorem jest $(call add-product-dex-preopt-module-config,<modules>,<option>) gdzie <modules> to lista pozycji LOCAL_MODULE i LOCAL_PACKAGE nazwy odpowiednio plików JAR i APK.

  • PRODUCT_DEXPREOPT_SPEED_APPS (od Androida 8)

    • listę aplikacji, które zostały uznane za podstawowe dla produktów i które powinny być skompilowane z użyciem filtra kompilatora speed. Dla: trwałe aplikacje, takie jak SystemUI, mogą zostać wykorzystane prowadzoną przez profil tylko przy następnym uruchomieniu, więc może być lepsza aby te aplikacje zawsze były kompilowane według AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (od Androida 8)

    • Lista aplikacji wczytywanych przez serwer systemu. Te aplikacje są domyślnie kompilowane z filtrem kompilatora speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (od Androida 8)

    • Określa, czy na urządzeniu umieścić wersję ART do debugowania. Domyślnie jest to należy włączyć na potrzeby debugowania użytkownika i kompilacji angielskiej. To zachowanie może zostać zastąpione przez ustawiając opcję na true lub false.

    Domyślnie urządzenie używa 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 Androidzie w wersjach od 5.1.0 do 6.0.1 WITH_DEXPREOPT_PIC może musi być określony, aby włączyć kod niezależny od pozycji (PIC). W takim przypadku nie trzeba przenosić kodu z obrazu /system na /data/dalvik-cache, oszczędzając miejsce na partycji danych. Będzie to jednak mieć niewielki wpływ na czas działania, ponieważ wyłączy ono optymalizację wykorzystującą kodu zależnego od pozycji. Zwykle urządzenia, które chcą zaoszczędzić miejsce w aplikacji /data powinien włączyć kompilację PIC.

    W Androidzie 7.0 kompilacja plików PIC była domyślnie włączona.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (do Androida 7 MR1)

    • Ta opcja została zastąpiona przez WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY który także wstępnie przyjmuje pliki JAR serwera systemu.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

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

    • (Android 14 i nowsze) Jeśli nie określono inaczej, speed-profile jest używany filtr kompilatora lub filtr kompilatora speed; dostępna.
    • (Android 13 i starsze) Jeśli nie określono inaczej, kompilator speed .
    • Jeśli ma wartość speed, używany jest filtr kompilatora speed.
    • Jeśli ma wartość speed-profile, używany jest filtr kompilatora speed-profile, lub filtr kompilatora verify, jeśli nie podano profilu.
    • Jeśli ma wartość 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 znajduje się lista plików JAR wczytywanych przez serwer systemu. Pliki JAR są połączone z filtr kompilatora określony przez PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Wymagane) PRODUCT_SYSTEM_SERVER_JARS: lista włączonych plików JAR ścieżki klasy serwera systemu platformy (czyli w ramach SYSTEMSERVERCLASSPATH). Dodaję serwer systemowy Pliki JAR ze ścieżką klasy do tej listy są wymagane. Nie udało się dodać plików JAR ścieżki klasy serwera systemowego do listy spowoduje, że pliki JAR nie zostaną wczytane.
    • (Wymagane) PRODUCT_APEX_SYSTEM_SERVER_JARS: lista plików JAR ścieżki klasy serwera systemowego zrealizowanych z APEX (w ramach SYSTEMSERVERCLASSPATH). Format to <apex name>:<jar name> Dodaję pliki JAR ścieżki systemu APEX do ta lista jest wymagana. Jeśli nie dodasz do tej listy plików JAR ścieżki systemu APEX, spowoduje to te pliki JAR nie zostały wczytane.
    • (Opcjonalnie, Android 13 lub starszy) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: lista plików JAR wczytywanych przez serwer systemu dynamicznie za pomocą osobnych modułów ładowania klas (za pomocą SystemServiceManager.startServiceFromJar). Dodawanie samodzielnych plików JAR serwera systemowego do ta lista nie jest wymagana, ale zdecydowanie zalecana, ponieważ powoduje kompilację plików JAR i więc jego środowisko wykonawcze zapewnia dobrą wydajność.
    • (wymagane od Androida 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: lista pliki JAR dostarczane z pakietem APEX, który serwer systemu wczytuje dynamicznie za pomocą osobnych programów ładujących jest za pośrednictwem usługi SystemServiceManager.startServiceFromJar lub zadeklarowana jako <apex-system-service>). Format to <apex name>:<jar name> Dodanie samodzielnych plików JAR serwera systemu APEX do ta lista jest wymagana. Jeśli nie dodasz do tej listy samodzielnych plików JAR serwera systemu APEX, spowoduje to nie udało się uruchomić.

    Uruchom konfigurację ścieżki klasy

    Wstępnie wczytana lista klas to lista klas inicjowanych przez Zygote podczas uruchamiania. Dzięki temu każda aplikacja nie będzie musiała uruchamiać tych inicjatorów klas oddzielnie, co pozwala na szybsze uruchamianie się i udostępnianie stron w pamięci. wstępnie załadowany plik z listą klas znajduje się pod adresem frameworks/base/config/preloaded-classes domyślnie i zawiera listę dostosowaną do standardowego użytkowania telefonu. Może to spowodować musi różnić się w przypadku innych urządzeń, takich jak urządzenia do noszenia, i musi zostać dostrojony. odpowiednio się zmienia. Zachowaj ostrożność podczas dostrajania. dodawanie zbyt wielu zbędnych zajęć w pamięci masowej, gdy są wczytywane nieużywane zajęcia. Dodanie zbyt małej liczby klas wymusza na każdej aplikacji mieć własną kopię, co również marnuje pamięć.

    Przykład użycia (w device.mk usługi):

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

    Uwaga: ten wiersz należy umieścić przed dziedziczenie dowolnych plików konfiguracji produktów, które pobierają domyślny plik build/target/product/base.mk

    Konfiguracja środowiska wykonawczego

    Opcje JIT

    Poniższe opcje wpływają tylko na wersje Androida, w których kompilator ART JIT jest dostępna.

    • dalvik.vm.usejit: wskazuje, czy kompilator JIT jest włączony.
    • dalvik.vm.jitinitialsize (domyślnie 64 KB): początkowa pojemność z pamięci podręcznej kodu. Pamięć podręczna kodu będzie regularnie zwiększana GC i w razie potrzeby zwiększa się.
    • dalvik.vm.jitmaxsize (domyślnie 64 MB): maksymalna pojemność pamięci podręcznej kodu.
    • dalvik.vm.jitthreshold (domyślnie 10 000): Próg, na podstawie którego „gorąca” licznik metody musi być przekazywany w kolejności metody kompilowania przy użyciu metody JIT. „Gorąco” licznik to wewnętrzny wskaźnik do środowiska wykonawczego. Obejmuje liczbę połączeń, odgałęzień wstecz i inne czynników.
    • dalvik.vm.usejitprofiles (do Androida 13): czy profile JIT nie są włączone; tej wartości można używać nawet wtedy, gdy dalvik.vm.usejit ma wartość false (fałsz). Zwróć uwagę, że jeśli to fałsz, filtr kompilatora speed-profile nie kompiluje żadnej metody AOT i jest odpowiednikiem metody verify. Od Android 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 UI aplikacji. Użyj, aby przyspieszyć kompilację metod bezpośrednio wpływających na wrażenia użytkownika podczas interakcji z .
    • dalvik.vm.jittransitionweight (domyślnie dalvik.vm.jitthreshold / 10): Waga metody które umożliwia przejście między kodem kompilacji a interpreterem. To pomaga upewnij się, że stosowane metody są skompilowane w taki sposób, by zminimalizować przejścia (które są drogie).

    Opcje Dex2oat

    Te opcje mają wpływ na kompilację danych na urządzeniu (dexopt), a kilka z nich również ma wpływ dexpreopt, natomiast opcje omówione w sekcji Konfiguracja systemowej pamięci ROM powyżej znajdują się tylko w sekcji dexpreopt.

    Opcje kontrolowania 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), który będzie używany na potrzeby obrazów rozruchowych.
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • Liczba wątków i zestaw rdzeni procesora (do Androida 11). (patrz poniżej) do użycia podczas uruchamiania urządzenia poza obrazami rozruchu.
      • Liczba wątków i zestaw rdzeni procesora (od Androida 12). (patrz poniżej), który będzie używany podczas uruchamiania do wszystkiego, w tym do obrazów rozruchu.
        • Ponieważ Android 14 odpowiada klasa priorytetowa 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 chmury kopii zapasowej.
      • (od Androida 14) Liczba wątków i zestaw rdzeni procesora. (patrz poniżej), aby używać go w przypadku działań, które są bardziej podatne na opóźnienia niż zwykle, w tym przywracania z kopii zapasowej w chmurze.
        • Odpowiada to klasie priorytetu. PRIORITY_INTERACTIVE_FAST w ART Service.
    • 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), do użycia w tle.
      • Odpowiada to klasie priorytetu PRIORITY_BACKGROUND w Usługa ART.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Liczba wątków i zestaw rdzeni procesora, które mają być używane do wszystkich reszty.

    Zbiór rdzeni procesora należy podać w postaci listy oddzielonych przecinkami identyfikatorów procesora. Na przykład do uruchamiania na dex2oat na rdzeniach procesora 0–3, ustaw:

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

    Przy ustawianiu właściwości koligacji procesora zalecamy dopasowanie odpowiedniej właściwości do parametru liczba wątków dex2oat odpowiadających liczbie wybranych procesorów, co pozwala uniknąć niepotrzebnej pamięci i operacji wejścia-wyjścia rywalizacja: 

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

    Oprócz wymienionych powyżej właściwości systemu możesz też używać profili zadań do kontrolowania wykorzystanie zasobów dex2oat (zobacz Cgroup Abstraction Layer).

    Obsługiwane profile zadań to:

    • Dex2OatBackground (od Androida 14) (domyślnie dziedziczy właściwość Dex2OatBootComplete): Kontroluje zasoby, których można używać w tle.
      • Odpowiada to klasie priorytetu PRIORITY_BACKGROUND w Usługa ART.
    • Dex2OatBootComplete:
      • (do Androida 13) Kontroluje zasób używany do wszystkiego po uruchomieniu przeglądarki.
      • (od Androida 14) Kontroluje zasoby używane do wszystkiego po uruchomieniu, a nie w tle.
        • Odpowiada to klasie priorytetu. PRIORITY_INTERACTIVE_FAST i PRIORITY_INTERACTIVE w ART posprzedażna.

    Jeśli określisz zarówno właściwości systemowe, jak i profile zadań, zostaną zastosowane obie te właściwości.

    Opcje sterowania rozmiarem sterty:

    • dalvik.vm.image-dex2oat-Xms: początkowy rozmiar stosu obrazów rozruchowych.
    • dalvik.vm.image-dex2oat-Xmx: maksymalny rozmiar stosu obrazów rozruchowych.
    • dalvik.vm.dex2oat-Xms: początkowy rozmiar stosu na pozostałe.
    • dalvik.vm.dex2oat-Xmx: maksymalny rozmiar stosu na wszystkie pozostałe elementy.

    Opcje sterujące początkowym i maksymalnym rozmiarem stosu dla Parametrów dex2oat nie należy zmniejszać, ponieważ mogą one ograniczyć aplikacje mogą być kompilowane.

    Opcje sterowania filtrem kompilatora:

    • dalvik.vm.image-dex2oat-filter (do Androida 11): Filtr kompilatora dla obrazów rozruchowych. Od Androida 12 filtr obrazów rozruchowych ma zawsze wartość speed-profile i nie można go zmienić.
    • dalvik.vm.systemservercompilerfilter (od Androida 13): Filtr kompilatora dla serwera systemu. Zobacz PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
    • dalvik.vm.systemuicompilerfilter (od Androida 13): Filtr kompilatora dla pakietu interfejsu systemowego.
    • dalvik.vm.dex2oat-filter (do Androida 6): Filtr kompilatora dla wszystkich pozostałych elementów.
    • pm.dexopt.<reason> (od Androida 7): Filtr kompilatora dla wszystkich pozostałych elementów. Zobacz Konfiguracja usługi ART na Androida 14 lub więcej, Konfiguracja menedżera pakietów dla Android 13 i starsze.

    Inne opcje kontrolowania kompilacji wszystkich elementów innych niż obrazy rozruchowe:

    • dalvik.vm.dex2oat-very-large (od Androida 7.1): minimalny łączny rozmiar pliku .dex w calach bajtów, aby wyłączyć kompilację AOT.
    • dalvik.vm.dex2oat-swap (od Androida 7.1) (domyślnie: prawda): umożliwia zamianę dex2oat. Może to pomóc uniknąć awarii z brakiem pamięci. Pamiętaj, że nawet jeśli ta opcja jest jest włączone, dex2oat korzysta z pliku wymiany tylko w określonych warunkach, na przykład gdy numer plików .dex jest bardzo duże, a warunki mogą ulec zmianie.
    • dalvik.vm.ps-min-first-save-ms (od Androida 12): minimalny czas oczekiwania przed wygenerowaniem profilu aplikacji przez środowisko wykonawcze po raz pierwszy po uruchomieniu aplikacji.
    • dalvik.vm.ps-min-save-period-ms (od Androida 12): minimalny czas oczekiwania przed aktualizacją profilu aplikacji.
    • dalvik.vm.dex2oat64.enabled (od 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 odsetek nowych klas w profilu z zakresu od 0 do 100, który powoduje ponowną kompilację. Ma zastosowanie tylko do kompilacji wspomaganej przez profil (speed-profile), zazwyczaj w trakcie dexopt. Pamiętaj, że oprócz tego obowiązuje też próg co najmniej 50 nowych zajęć. progu procentowego i nie można go skonfigurować.
    • dalvik.vm.bgdexopt.new-methods-percent (od Androida 12) (domyślnie: 20): Minimalny odsetek nowych metod w profilu z zakresu od 0 do 100, który aktywuje ponowną kompilację. Ma zastosowanie tylko do kompilacji wspomaganej przez profil (speed-profile), zazwyczaj w trakcie dexopt. Pamiętaj, że dodatkowo obowiązuje próg co najmniej 100 nowych metod. do wartości progowej i nie można go skonfigurować.
    • dalvik.vm.dex2oat-max-image-block-size (od Androida 10) (domyślnie: 524288) Maksymalny rozmiar bloku stałego w przypadku skompresowanych obrazów. Duży obraz jest podzielony na zbiór brył bryły, tak aby żadna bryła nie przekraczała maksymalnego rozmiaru.
    • dalvik.vm.dex2oat-resolve-startup-strings (od Androida 10) (domyślnie: prawda) Jeśli wartość to prawda, dex2oat rozłącza wszystkie ciągi stałe, do których odwołują się metody oznaczone jako „uruchamianie” w profilu.
    • debug.generate-debug-info (domyślnie: fałsz) Określa, czy mają być generowane informacje na potrzeby debugowania natywnego, np. rozwijanie stosu. informacje, symbole ELF i sekcje DARF.
    • dalvik.vm.dex2oat-minidebuginfo (od Androida 9) (domyślnie: prawda) Określa, czy należy wygenerować minimalną ilość skompresowanych danych debugowania skompresowanych w LZMA, które są niezbędne tradycji drukowanych.

    Opcje usługi ART

    Od Androida 14 kompilacja informacji o AOT na urządzeniu (tzw. dexopt) jest obsługiwane przez ART Service. Informacje o konfigurowaniu usługi ART znajdziesz w artykule Konfiguracja usługi ART.

    Opcje menedżera pakietów

    Przed Androidem 14 kompilacja AOT aplikacji na urządzeniu (lub dexopt) jest obsługiwane przez menedżera pakietów. Informacje o konfigurowaniu menedżera pakietów na potrzeby dexopt zobacz Konfiguracja menedżera pakietów.

    Konfiguracja dostosowaną do typu A/B

    Konfiguracja ROM

    Począwszy od Androida 7.0 urządzenia mogą używać dwóch partycji systemowych do włączania i wyłączania Aktualizacje systemu A/B. Aby zmniejszyć rozmiar partycji systemowej, możesz zainstalować wstępnie skonfigurowane pliki w z nieużywanej drugiej partycji systemowej. Są one następnie kopiowane na partycję danych. przy pierwszym uruchomieniu.

    Przykład użycia (w device-common.mk):

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

    A w aplikacji BoardConfig.mk na urządzeniu:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Pamiętaj, że kod ścieżki klasy rozruchowej, kod serwera systemowego oraz podstawowe dane dotyczące usługi aplikacje zawsze kompilują się na partycję systemową. Domyślnie wszystkie pozostałe aplikacje będą kompilowane do nieużywanej drugiej partycji systemowej. Może to być kontrolowane za pomocą funkcji SYSTEM_OTHER_ODEX_FILTER, która ma wartość jako wartość domyślna:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Deksoptacja OTA w tle

    Na urządzeniach z włączoną obsługą testów A/B aplikacje mogą być kompilowane w tle przed ponownym uruchomieniem za pomocą nowego obrazu systemu. Zobacz Kompilację aplikacji w tła, aby opcjonalnie dołączyć skrypt kompilacji i pliki binarne w obrazie systemu. filtrem kompilacji używanym w tej kompilacji można sterować za pomocą:

    pm.dexopt.ab-ota=speed-profile

    Zalecamy używanie speed-profile, aby korzystać z przewodnika po profilu kompilować i zapisywać w pamięci masowej.

    Opcje JDWP

    Tworzenie wątków za pomocą protokołu Java Debug Wire Protocol (JDWP) w kompilacjach userdebug można kontrolować za pomocą Właściwość systemowa persist.debug.dalvik.vm.jdwp.enabled. Domyślnie ta usługa nie jest ustawiony, a wątki JDWP są tworzone tylko dla aplikacji możliwych do debugowania. Aby włączyć wątki JDWP w obu tych usługach aplikacje możliwe i niedebugowane, ustaw persist.debug.dalvik.vm.jdwp.enabled do: 1. Aby zmiany właściwości zaczęły obowiązywać, należy zrestartować urządzenie.

    Aby debugować aplikację, której nie można debugować, w kompilacji userdebug, włącz JDWP, uruchamiając to polecenie polecenie:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    . W przypadku urządzeń z Androidem 13 lub starszym środowisko wykonawcze tworzy pakiet JDWP w kompilacjach userdebug i w wątkach aplikacji możliwych do debugowania oraz tych, których nie można debugować. Oznacza to, że możliwe jest , by dołączyć debuger lub profilować dowolną aplikację w kompilacjach userdebug.