Skonfiguruj ART

Na tej stronie znajdziesz informacje o konfigurowaniu środowiska uruchomieniowego Androida (ART) i jego opcji kompilacji. Poruszane tu tematy obejmują konfigurację wstępną kompilacji obrazu systemu, dex2oatopcje kompilacji oraz sposób na zrównoważenie przestrzeni na partycji systemowej, partycji danych i wydajności.

Aby dowiedzieć się, jak pracować z ART, zapoznaj się z artykułami ART i Dalvik oraz Format wykonywalny Dalvik. Aby mieć pewność, że aplikacje działają prawidłowo, zapoznaj się z artykułem Sprawdzanie działania aplikacji w środowisku uruchomieniowym Androida (ART).

Jak działa ART

ART używa kompilacji z wyprzedzeniem (AOT). Od Androida 7 używa hybrydowej kombinacji kompilacji AOT, kompilacji just-in-time (JIT) i interpretacji. Kompilacja AOT może być kierowana przez profil. Kombinacje wszystkich tych trybów wykonywania są konfigurowalne i omówione w tej sekcji. Na przykład urządzenia Pixel są skonfigurowane tak, aby działać zgodnie z tym schematem:

  1. Aplikacja jest początkowo instalowana z plikiem metadanych dex (.dm) rozpowszechnianym przez Sklep Play, który zawiera profil chmury. ART kompiluje metody AOT zgodnie z profilem w chmurze. Jeśli aplikacja jest zainstalowana bez pliku metadanych DEX, nie jest wykonywana kompilacja AOT.
  2. Przez pierwsze kilka razy, gdy aplikacja jest uruchamiana, metody, które nie zostały skompilowane w procesie AOT, są interpretowane. Spośród interpretowanych metod te, które są często wykonywane, są następnie kompilowane z wykorzystaniem kompilacji Just-In-Time. ART generuje profil lokalny na podstawie wykonania i łączy go z profilem w chmurze (jeśli istnieje).
  3. Gdy urządzenie jest nieaktywne i ładuje się, uruchamia się demon kompilacji, który ponownie kompiluje aplikację na podstawie połączonego profilu wygenerowanego podczas kilku pierwszych uruchomień.
  4. Podczas kolejnych uruchomień aplikacji ART korzysta z artefaktów wygenerowanych przez demona kompilacji, które zawierają więcej kodu skompilowanego AOT niż te wygenerowane podczas uruchamiania. Metody, które nie zostały skompilowane AOT, są nadal interpretowane lub kompilowane 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ędzia dex2oat) i środowiska wykonawczego (libart.so), które jest ładowane podczas uruchamiania. Narzędzie dex2oat przetwarza plik APK i generuje co najmniej 1 plik artefaktu kompilacji, który jest ładowany w czasie wykonywania. Liczba plików, ich rozszerzeń i nazwy może się zmieniać w kolejnych wersjach, ale od wersji 8 Androida generowane są te pliki:

  • .vdex: zawiera dodatkowe metadane, które przyspieszają weryfikację, czasami wraz z nieskompresowanym kodem DEX pliku APK.
  • .odex: zawiera kod skompilowany za pomocą AOT dla metod w pliku APK.
  • .art (optional) zawiera wewnętrzne reprezentacje niektórych ciągów znaków i klas wymienionych w pliku APK, które służą do przyspieszania uruchamiania aplikacji.

Opcje kompilacji

Istnieją 2 kategorie opcji kompilacji ART:

  1. Konfiguracja systemu ROM: jaki kod jest kompilowany w trybie AOT podczas tworzenia obrazu systemu.
  2. Konfiguracja w czasie wykonywania: sposób kompilowania i uruchamiania aplikacji przez ART na urządzeniu.

Filtry kompilatora

Jedną z podstawowych opcji ART do konfigurowania tych 2 kategorii jest compiler filters. Filtry kompilatora określają sposób kompilowania kodu DEX przez ART i są opcją przekazywaną narzędziu dex2oat. Od Androida 8 dostępne są 4 oficjalnie obsługiwane filtry:

  • verify: przeprowadza tylko weryfikację kodu DEX (bez kompilacji AOT).
  • quicken: (Android 11 lub starszy) przeprowadza weryfikację kodu DEX i optymalizuje niektóre instrukcje DEX, aby zwiększyć wydajność interpretera.
  • speed: przeprowadza weryfikację kodu DEX i skompilowuje wszystkie metody w trybie AOT. nie optymalizuje ładowania zajęć,
  • speed-profile: przeprowadza weryfikację kodu DEX, kompiluje metody AOT wymienione w profilu i optymalizuje wczytywanie klas w klasach w profilu.

Konfiguracja systemu ROM

Wstępnie zainstalowane biblioteki i aplikacje są kompilowane w trybie AOT podczas tworzenia obrazu systemu. Ten proces nazywa się dexpreopt. Takie skompilowane pliki są przydatne, dopóki wszystkie zależności pozostają niezmienione, w szczególności ścieżka uruchamiania.

Uwaga: jeśli urządzenie obsługuje aktualizacje modułu systemowego, to w przyszłej aktualizacji ścieżka klas uruchamiania prawdopodobnie ulegnie zmianie, co spowoduje, że wszystkie pliki dexpreopt staną się nieaktualne i nieużyteczne.

Do konfigurowania dexpreopt dostępne jest kilka opcji kompilacji ART. Sposób konfiguracji tych opcji zależy od dostępnej ilości miejsca na obraz systemu i liczby wstępnie zainstalowanych aplikacji. Pliki JAR/APK, które są kompilowane do systemu ROM, można podzielić na 4 kategorie:

  • Kod ścieżki uruchamiania: domyślnie kompilowany za pomocą filtra kompilatora speed-profile.
  • Kod serwera systemu (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):
    • (Android 14 i nowsze) Kompilacja z filtrem kompilatora speed-profile domyślnie lub z filtrem kompilatora speed, jeśli nie podano profilu.
    • (Android 13 i starsze) Kompilacja z użyciem filtra kompilatora speed jest domyślnie włączona.
    Konfiguracja za pomocą PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (patrz dalej w tym dokumencie).
  • Aplikacje podstawowe związane z poszczególnymi usługami (patrz PRODUCT_DEXPREOPT_SPEED_APPS w tym dokumencie): domyślnie skompilowane za pomocą filtra kompilatora speed.
  • Wszystkie inne aplikacje: domyślnie skompilowane z filtrem kompilatora speed-profile lub skompilowane z filtrem kompilatora verify, jeśli nie podano profilu.

    Konfigurowalne za pomocą PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (patrz dalej w tym dokumencie).

Opcje makefile

  • WITH_DEXPREOPT

    • Czy dex2oat jest wywoływany w kodzie DEX zainstalowanym w pliku obrazu systemu. Ta opcja jest domyślnie włączona.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 lub nowszy)

    • Włączenie DONT_DEXPREOPT_PREBUILTS uniemożliwia wykluczenie z indeksu gotowych pakietów. Są to aplikacje, w których include $(BUILD_PREBUILT) jest określony w elementach Android.mk. Pominięcie opcji dexpreopt w przypadku gotowych aplikacji, które prawdopodobnie zostaną zaktualizowane przez Google Play, pozwala zaoszczędzić miejsce w obrazie systemu, ale wydłuża czas uruchamiania. Pamiętaj, że ta opcja nie ma wpływu na wstępnie utworzone aplikacje zdefiniowane w Android.bp.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 lub nowszy)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER określa domyślny filtr kompilatora dla aplikacji zoptymalizowanych pod kątem dex. Te aplikacje są zdefiniowane w pliku Android.bp lub mają w pliku Android.mk określony parametr include $(BUILD_PREBUILT). Jeśli nie podasz wartości, domyślnie zostanie użyta wartość speed-profile lub verify, jeśli nie podasz profilu.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY(od Androida 8 MR1)

    • Włączenie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY powoduje dexpreopt tylko boot classpath i system server jars.

  • LOCAL_DEX_PREOPT

    • Dexpreopt można też włączyć lub wyłączyć w poszczególnych aplikacjach, podając opcję LOCAL_DEX_PREOPT w definicji modułu. Może to być przydatne, jeśli chcesz wyłączyć dexpreopt w przypadku aplikacji, które mogą natychmiast otrzymywać aktualizacje z Google Play, ponieważ aktualizacje te spowodują, że kod dexpreopt w pliku obrazu systemu stanie się przestarzały. Jest to też przydatne, aby zaoszczędzić miejsce podczas aktualizacji OTA, ponieważ użytkownicy mogą mieć już nowsze wersje aplikacji na partycji danych.

    Opcja LOCAL_DEX_PREOPT obsługuje wartości true lub false, które odpowiednio włączają lub wyłączają dexpreopt. Dodatkowo można określić parametr nostripping, jeśli dexpreopt nie ma usuwać pliku classes.dex z pliku APK lub JAR. Zwykle ten plik jest usuwany, ponieważ nie jest już potrzebny po dexpreopt, ale ta ostatnia opcja jest niezbędna, aby podpisy APK innych firm pozostały ważne.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Przekazuje opcje do dex2oat, aby kontrolować sposób kompilowania obrazu rozruchowego. Można go używać do określania niestandardowych list klas obrazów, kompilowanych list klas i filtrów kompilatora.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Przekazuje opcje do dex2oat, aby kontrolować sposób kompilacji wszystkich elementów z wyjątkiem obrazu rozruchu.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Umożliwia przekazywanie opcji dex2oat dla konkretnego modułu i konfiguracji produktu. Jest ona ustawiana w pliku device.mk produktu za pomocą parametru $(call add-product-dex-preopt-module-config,<modules>,<option>), gdzie <modules> to lista nazw LOCAL_MODULE i LOCAL_PACKAGE odpowiednio dla plików JAR i APK.

  • PRODUCT_DEXPREOPT_SPEED_APPS (od Androida 8)

    • Lista aplikacji zidentyfikowanych jako kluczowe dla produktów i które warto skompilować za pomocą filtra kompilatora speed. Na przykład aplikacje trwałe, takie jak SystemUI, mogą korzystać z kompilacji kierowanej przez profil tylko podczas następnego ponownego uruchamiania, więc dla produktu lepiej jest, aby te aplikacje były zawsze kompilowane w trybie AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (od Androida 8)

    • Lista aplikacji wczytywanych przez serwer systemowy. Te aplikacje są domyślnie kompilowane za pomocą filtra kompilatora speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (od Androida 8)

    • Określa, czy na urządzeniu ma być uwzględniona wersja debugowania ART. Domyślnie jest to włączone w przypadku kompilacji userdebug i eng. Sposób działania można zmienić, ustawiając opcję na true lub false.

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

  • WITH_DEXPREOPT_PIC (do Androida 7)

    • W Androidzie 5.1.0–6.0.1 można użyć parametru WITH_DEXPREOPT_PIC, aby włączyć kod niezależny od pozycji (PIC). Dzięki temu nie trzeba przenosić skompilowanego kodu z obrazu z poziomu /system do /data/dalvik-cache, co pozwala zaoszczędzić miejsce na partycji danych. Ma to jednak niewielki wpływ na czas wykonywania, ponieważ wyłącza optymalizację, która korzysta z kodu zależnego od pozycji. Urządzenia, które chcą oszczędzać miejsce w /data, powinny zwykle włączyć kompilację PIC.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (do Androida 7.0 MR1)

    • Ta opcja została zastąpiona opcją WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, która również preoptymalizuje pliki JAR serwera systemowego.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

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

    • (Android 14 i nowsze) Jeśli nie podano wartości, używany jest filtr kompilatora speed-profile lub filtr kompilatora speed, jeśli nie podano profilu.
    • (Android 13 i starsze) Jeśli nie określono inaczej, używany jest filtr kompilatora speed.
    • Jeśli ustawisz wartość speed, używany jest filtr kompilatora speed.
    • Jeśli ustawisz wartość speed-profile, zostanie użyty filtr kompilatora speed-profile. Jeśli nie podasz profilu, zostanie użyty filtr kompilatora verify.
    • Jeśli ustawisz 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 znajdują się listy plików JAR wczytywanych przez serwer systemowy. Pliki JAR są kompilowane za pomocą filtra kompilatora określonego przez parametr PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.

    • (Wymagane) PRODUCT_SYSTEM_SERVER_JARS: lista plików JAR classpath serwera systemu na platformie (czyli w ramach SYSTEMSERVERCLASSPATH). Dodanie plików JAR classpath serwera systemu do tej listy jest wymagane. Jeśli nie dodasz do listy plików JAR z ścieżki klas do serwera systemu, te pliki JAR nie zostaną załadowane.
    • (Wymagane) PRODUCT_APEX_SYSTEM_SERVER_JARS: lista plików JAR z ścieżki klas serwera systemu dostarczanych z Apexem (czyli jako część SYSTEMSERVERCLASSPATH). Format: <apex name>:<jar name>. Dodanie plików JAR z ścieżki klastrów serwera APEX do tej listy jest wymagane. Jeśli nie dodasz do tej listy plików JAR z ścieżki klas serwera systemu APEX, te pliki JAR nie będą wczytywane.
    • (Opcjonalnie, Android 13 i starsze wersje) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: lista plików JAR, które serwer systemowy wczytuje dynamicznie za pomocą oddzielnych ładowarek klas (poprzez SystemServiceManager.startServiceFromJar). Dodawanie do tej listy samodzielnych plików JAR serwera systemowego nie jest wymagane, ale zdecydowanie zalecane, ponieważ pozwala skompilować pliki JAR i w ten sposób uzyskać dobrą wydajność w czasie wykonywania.
    • (wymagany od Androida 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: lista plików JAR dostarczanych z APEX, które serwer systemowy ładuje dynamicznie za pomocą oddzielnych ładowarek klas (czyli za pomocą interfejsu SystemServiceManager.startServiceFromJar lub deklarowanych jako <apex-system-service>). Format: <apex name>:<jar name>. Dodanie do tej listy samodzielnych plików JAR serwera systemu APEX jest wymagane. Niedodanie do tej listy samodzielnych plików JAR serwera systemu APEX spowoduje błąd uruchamiania.

    Konfiguracja ścieżki klas podczas uruchamiania

    Lista wstępnie załadowanych klas to lista klas, które Zygote inicjuje podczas uruchamiania. Dzięki temu każda aplikacja nie musi uruchamiać tych inicjatorów klas osobno, co pozwala na szybsze uruchamianie aplikacji i dzielenie się stronami w pamięci. Plik z listą wstępnie załadowanych klas znajduje się domyślnie w folderze frameworks/base/config/preloaded-classes i zawiera listę dostosowaną do typowego użytkowania telefonu. W przypadku innych urządzeń, takich jak urządzenia do noszenia, może to być inne i musi być odpowiednio dostosowane. Zachowaj ostrożność podczas dostosowywania tego parametru. Dodanie zbyt wielu klas powoduje marnowanie pamięci, gdy nieużywane klasy są wczytywane. Dodanie zbyt małej liczby klas powoduje, że każda aplikacja musi mieć własną kopię, co z kolei powoduje marnowanie pamięci.

    Przykład użycia (w sekcji device.mk produktu):

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

    Uwaga: musisz umieścić ten wiersz przed dziedziczeniem plików make z konfiguracją produktu, które otrzymują domyślny plik z pliku build/target/product/base.mk.

    Konfiguracja środowiska wykonawczego

    Opcje JIT

    Opcje te mają wpływ na wersje Androida tylko wtedy, gdy jest dostępny kompilator JIT ART.

    • dalvik.vm.usejit: czy kompilacja Just In Time jest włączona.
    • dalvik.vm.jitinitialsize (domyślnie 64 KB): początkowa pojemność pamięci podręcznej kodu. Pamięć podręczna kodu będzie regularnie czyszczona i w razie potrzeby zwiększana.
    • dalvik.vm.jitmaxsize (domyślnie 64 M): maksymalna pojemność pamięci podręcznej kodu.
    • dalvik.vm.jitthreshold (domyślnie 10 000): próg, który licznik „gorąca” metody musi przekroczyć, aby metoda została skompilowana z wykorzystaniem kompilacji Just-In-Time. Licznik „hotness” to dane wewnętrzne środowiska uruchomieniowego. Obejmuje on liczbę wywołań, odgałęzi wstecznych i inne czynniki.
    • dalvik.vm.usejitprofiles (do Androida 13): określa, czy profile JIT są włączone. Można go użyć nawet wtedy, gdy dalvik.vm.usejit ma wartość Fałsz. Pamiętaj, że jeśli ta wartość jest równa fałsz, filtr kompilatora speed-profile nie kompiluje metod AOT w żadnym przypadku i jest równoważny z wartością verify. Od 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” kodu JIT (patrz jitthreshold) w wątku interfejsu użytkownika aplikacji. Używaj do przyspieszania kompilacji metod, które mają bezpośredni wpływ na wygodę użytkowników podczas korzystania z aplikacji.
    • dalvik.vm.jittransitionweight (domyślnie dalvik.vm.jitthreshold / 10): waga wywołania metody, która przechodzi między kodem kompilacji a interpretatorem. Dzięki temu masz pewność, że metody są kompilowane w celu zminimalizowania liczby przejść (które są kosztowne).

    Opcje Dex2oat

    Te opcje wpływają na kompilację na urządzeniu (czyli dexopt), a niektóre z nich mają też wpływ na dexpreopt. Opcje opisane w sekcji Konfiguracja ROM-u systemowego powyżej wpływają tylko na dexpreopt.

    Opcje umożliwiające kontrolowanie 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) do użycia w przypadku obrazów startowych.
    • 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) do użycia podczas uruchamiania dla wszystkich elementów innych niż obrazy uruchamiania.
      • (od Androida 12) Liczba wątków i zestaw rdzeni procesora (patrz poniżej) do użycia podczas uruchamiania dla wszystkich elementów, w tym obrazów rozruchowych.
        • 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) do przywracania z kopii zapasowej w chmurze.
      • (od Androida 14) Liczba wątków i zestaw rdzeni procesora (patrz poniżej) do stosowania w przypadku zadań, które są bardziej wrażliwe na opóźnienia niż normalnie, w tym przy przywracaniu z kopii zapasowej w chmurze.
        • 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) do użycia w tle.
      • Odpowiada to klasie priorytetowej PRIORITY_BACKGROUND w usłudze ART.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: liczba wątków i zestaw rdzeni procesora do użycia do innych celów.

    Zestaw rdzeni procesora powinien być określony jako lista identyfikatorów procesorów rozdzielonych przecinkami. Aby na przykład uruchomić dex2oat na procesorach 0–3, ustaw:

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

    Aby uniknąć niepotrzebnego współzawodnictwa o pamięć i wejście/wyjście, zalecamy, aby podczas ustawiania właściwości zgodności z procesorem dopasować odpowiednią właściwość liczby wątków dex2oat do liczby wybranych procesorów: 

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

    Oprócz wymienionych wyżej właściwości systemu możesz też używać profili zadań, aby kontrolować wykorzystanie zasobów przez dex2oat (patrz warstwa abstrakcji Cgroup).

    Obsługiwane profile zadań:

    • Dex2OatBackground(od Androida 14) (domyślnie dziedziczy ustawienie Dex2OatBootComplete): kontroluje zasoby używane w tle.
      • Odpowiada to klasie priorytetowej PRIORITY_BACKGROUND w usłudze ART.
    • Dex2OatBootComplete:
      • (do Androida 13) Określa zasób używany do wszystkich operacji po uruchomieniu.
      • (od Androida 14) Określa zasób do użycia do wszystkich operacji po uruchomieniu, a nie w tle.
        • Odpowiada to klasom priorytetów PRIORITY_INTERACTIVE_FAST i PRIORITY_INTERACTIVE w usłudze ART.

    Jeśli określone są zarówno właściwości systemu, jak i profile zadań, mają one zastosowanie.

    Opcje kontrolowania rozmiaru stosu:

    • dalvik.vm.image-dex2oat-Xms: początkowy rozmiar stosu dla obrazów rozruchowych.
    • dalvik.vm.image-dex2oat-Xmx: maksymalny rozmiar stosu dla obrazów rozruchowych.
    • dalvik.vm.dex2oat-Xms: początkowy rozmiar stosu dla wszystkiego innego.
    • dalvik.vm.dex2oat-Xmx: maksymalny rozmiar stosu dla wszystkich innych danych.

    Nie należy zmniejszać opcji kontrolujących początkowy i maksymalny rozmiar stosu dla dex2oat, ponieważ może to ograniczyć możliwości kompilacji aplikacji.

    Opcje sterowania filtrem kompilatora:

    • dalvik.vm.image-dex2oat-filter (do Androida 11): Filtr kompilatora dla obrazów startowych. Od Androida 12 kompilator filtruje obrazy rozruchu zawsze za pomocą speed-profile i nie można tego 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 dla wszystkiego innego.
    • pm.dexopt.<reason> (od Androida 7): filtr kompilatora dla wszystkiego innego. Zapoznaj się z artykułem Konfiguracja usługi ART w przypadku Androida 14 i wyższych lub Konfiguracja menedżera pakietów w przypadku Androida 13 i starszych.

    Inne opcje sterowania kompilacją wszystkich elementów z wyjątkiem obrazów rozruchowych:

    • dalvik.vm.dex2oat-very-large (od Androida 7.1): minimalny łączny rozmiar pliku dex w bajtach, aby wyłączyć kompilację 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 spowodowanych brakiem pamięci. Pamiętaj, że nawet jeśli ta opcja jest włączona, dex2oat będzie używać pliku wymiany tylko w pewnych warunkach, na przykład gdy liczba plików dex jest duża. Warunki mogą się zmieniać.
    • dalvik.vm.ps-min-first-save-ms (od Androida 12): minimalny czas oczekiwania, zanim środowisko uruchomione wygeneruje profil aplikacji, gdy aplikacja zostanie uruchomiona po raz pierwszy.
    • dalvik.vm.ps-min-save-period-ms (od Androida 12): minimalny czas oczekiwania przed zaktualizowaniem profilu aplikacji.
    • dalvik.vm.dex2oat64.enabled(od Androida 11; domyślnie false): czy użyć 64-bitowej wersji dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent(od Androida 12) (domyślnie 20): minimalny odsetek (od 0 do 100) nowych klas w profilu, który powoduje ponowną kompilację. Dotyczy tylko kompilacji kierowanej przez profil (speed-profile), zwykle podczas optymalizacji dex w tle. Pamiętaj, że oprócz progu procentowego istnieje też próg co najmniej 50 nowych zajęć, który nie można konfigurować.
    • dalvik.vm.bgdexopt.new-methods-percent(od Androida 12) (domyślnie 20): minimalny odsetek (od 0 do 100) nowych metod w profilu, który powoduje ponowną kompilację. Dotyczy tylko kompilacji kierowanej przez profil (speed-profile), zwykle podczas optymalizacji dex w tle. Oprócz progu procentowego obowiązuje też próg co najmniej 100 nowych metod, który nie można konfigurować.
    • dalvik.vm.dex2oat-max-image-block-size(od Androida 10) (domyślnie: 524288)Maksymalny rozmiar stałego bloku dla skompresowanych obrazów. Duże zdjęcie jest dzielone na zestaw jednolitych bloków, tak aby żaden z nich nie przekraczał maksymalnego rozmiaru.
    • dalvik.vm.dex2oat-resolve-startup-strings(od Androida 10; domyślnie: prawda) Jeśli wartość to prawda, dex2oat rozwiązuje wszystkie ciągi znaków const, 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 na potrzeby debugowania natywnego, takie jak informacje o rozwijaniu stosu, symbole ELF i sekcje dwarf.
    • dalvik.vm.dex2oat-minidebuginfo(od Androida 9) (domyślnie: true)Określa, czy należy wygenerować minimalną ilość informacji debugowania skompresowanych za pomocą LZMA, które są niezbędne do wydrukowania ścieżek śledzenia.

    Opcje usługi ART

    Od Androida 14 kompilacja AOT na urządzeniu (czyli dexopt) jest obsługiwana przez usługę ART. Informacje o konfigurowaniu usługi ART znajdziesz w artykule Konfigurowanie usługi ART.

    Opcje menedżera pakietów

    W wersjach Androida starszych niż 14 kompilacja AOT aplikacji na urządzeniu (czyli dexopt) jest obsługiwana przez menedżera pakietów. Informacje o konfigurowaniu menedżera pakietów na potrzeby dexopt znajdziesz w artykule Konfigurowanie menedżera pakietów.

    Konfiguracja testu A/B

    Konfiguracja ROM

    Począwszy od Androida 7.0 urządzenia mogą używać 2 partycji systemowych, aby umożliwić aktualizacje systemu A/B. Aby zaoszczędzić miejsce na partycji systemowej, wstępnie wybrane pliki można zainstalować na nieużywanej drugiej partycji systemowej. Następnie są one kopiowane na partycję danych podczas pierwszego uruchomienia.

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

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

    A na urządzeniu BoardConfig.mk:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Pamiętaj, że kod ścieżki klas bootowania, kod serwera systemowego i aplikacje podstawowe związane z danym produktem są zawsze kompilowane na partycji systemowej. Domyślnie wszystkie inne aplikacje są kompilowane na nieużywany drugi partycji systemu. Możesz to kontrolować za pomocą parametru SYSTEM_OTHER_ODEX_FILTER, którego domyślna wartość to:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt OTA w tle

    Na urządzeniach z obsługą A/B aplikacje mogą być kompilowane w tle przed ponownym uruchomieniem z nowymi obrazami systemu. Aby opcjonalnie uwzględnić skrypt kompilacji i pliki binarne w obrazie systemu, zapoznaj się z artykułem Kompilacja aplikacji w tle. Filtr kompilacji użyty w tym przypadku jest kontrolowany przez:

    pm.dexopt.ab-ota=speed-profile

    Zalecamy korzystanie z wersji speed-profile, aby skorzystać z kompilacji z użyciem profilu i zaoszczędzić miejsce na dane.

    Opcje JDWP

    Tworzenie wątków w ramach protokołu Java Debug Wire Protocol (JDWP) w kompilacji userdebug jest kontrolowane za pomocą właściwości systemowej persist.debug.dalvik.vm.jdwp.enabled. Domyślnie ta właściwość nie jest ustawiona, a wątki JDWP są tworzone tylko w przypadku aplikacji z możliwością debugowania. Aby włączyć wątki JDWP zarówno w przypadku aplikacji z możliwością debugowania, jak i bez tej możliwości, ustaw wartość parametru persist.debug.dalvik.vm.jdwp.enabled na 1. Aby zmiany w usłudze zaczęły obowiązywać, musisz ponownie uruchomić urządzenie.

    Aby debugować aplikację nieobsługiwaną przez debugowanie na wersji userdebug, włącz JDWP, uruchamiając to polecenie:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Na urządzeniach z Androidem 13 lub niższym środowisko uruchomieniowe tworzy wątki JDWP dla aplikacji z możliwością debugowania i bez możliwości debugowania w kompilacji userdebug. Oznacza to, że można dołączyć debuger lub przeprofilować dowolną aplikację w kompilacji userdebug.