Konfigurowanie ART

Na tej stronie znajdziesz informacje o konfigurowaniu środowiska uruchomieniowego Androida (ART) i jego opcji kompilacji. Tematy omówione w tym artykule obejmują konfigurację wstępnej kompilacji obrazu systemu, dex2oatopcji kompilacji oraz sposób na znalezienie kompromisu między miejscem na partycji systemowej, miejscem na 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 wykonawczym 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 wykonania można konfigurować. W tej sekcji omówimy je szczegółowo. Na przykład urządzenia Pixel są skonfigurowane tak, aby działać w ramach tego procesu:

  1. Aplikacja jest początkowo instalowana z plikiem metadanych dex (.dm) rozpowszechnianym przez Sklep Play, który zawiera profil chmury. ART kompiluje AOT metody wymienione w profilu chmury. 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 technologii JIT. 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 kompilacji. 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 rozszerzenia i nazwy mogą 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

Dostępne są 2 kategorie opcji kompilacji ART:

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

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 kompiluje wszystkie metody w trybie AOT. Nie optymalizuje ładowania zajęć.
  • speed-profile: przeprowadza weryfikację kodu DEX, kompiluje metody AOT wymienione w profilu i optymalizuje ładowanie klas w klasach w profilu.

Konfiguracja ROM-u systemowego

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 ładowania.

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 jest dostępnych kilka opcji kompilacji ART. Konfiguracja 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 klas do uruchamiania: domyślnie jest 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 filtrem 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.

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

Opcje makefile

  • WITH_DEXPREOPT

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

  • DONT_DEXPREOPT_PREBUILTS (Android 5 lub nowszy)

    • Włączenie opcji DONT_DEXPREOPT_PREBUILTS uniemożliwia wykluczenie z indeksu gotowych pakietów. Są to aplikacje, które mają include $(BUILD_PREBUILT) określone w swoim 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 sekcji 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 dla boot classpath i systemowych plików JAR serwera.

  • 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 wersji 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 konieczna, 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, które zostały zidentyfikowane 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 może być lepiej, jeśli te aplikacje będą 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ą zaoszczędzić 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 zostanie określony, używany jest filtr kompilatora speed-profile lub filtr kompilatora speed, jeśli nie zostanie podany profil.
    • (Android 13 i starsze) Jeśli nie zostanie podany, 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 PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Wymagany) 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 klas serwera systemu 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ą 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 udostępnianie stron 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. Podczas dostosowywania tej wartości zachowaj ostrożność. 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 znowu 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

    Poniższe opcje mają wpływ na wersje Androida tylko wtedy, gdy jest dostępny kompilator JIT ART.

    • dalvik.vm.usejit: czy kompilacja JIT 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ę połączeń, gałę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żyj tej opcji, aby przyspieszyć kompilację metod, które mają bezpośredni wpływ na wrażenia użytkowników 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 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 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) 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 wszystkich operacji, 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 wersji 14 Androida): 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 wszystkich innych celów.

    Zestaw rdzeni procesora należy określić jako listę 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ółdzielenia pamięci i wejścia/wyjścia, zalecamy dopasowanie właściwości 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 warstwę 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) Kontroluje zasób używany do wszystkiego 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 umożliwiające kontrolowanie 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.

    Opcji, które kontrolują początkowy i maksymalny rozmiar stosu dla dex2oat, nie należy zmniejszać, 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 wszystkich innych wartości.
    • pm.dexopt.<reason> (od Androida 7): filtr kompilatora dla wszystkiego innego. Zapoznaj się z informacjami na temat konfiguracji usługi ART w Androidzie 14 i nowszych lub konfiguracji menedżera pakietów w Androidzie 13 i starszych.

    Inne opcje umożliwiające kontrolowanie kompilacji wszystkich elementów oprócz 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 utworzy profil aplikacji, gdy aplikacja jest uruchamiana 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): określa, 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 mają być generowane informacje debugowania na potrzeby debugowania natywnego, takie jak informacje o rozwijaniu stosu, symbole ELF i sekcje karłowate.
    • dalvik.vm.dex2oat-minidebuginfo(od Androida 9) (domyślnie: true)Czy generować 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 aplikacji 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 Androidzie 14 i starszych 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ć dwóch 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żna go 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 pliku obrazu systemu, zapoznaj się z artykułem Kompilacja aplikacji w tle. Filtr kompilacji użyty w tej kompilacji 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ątku protokołu JDWP (Java Debug Wire Protocol) 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 debuger w 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 starszym ś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żesz dołączyć debuger lub przeprowadzić profilowanie dowolnej aplikacji w kompilacji userdebug.