Konfiguracja ART

Na tej stronie omówiono, jak skonfigurować ART i jego opcje kompilacji. Poruszone tutaj tematy obejmują konfigurację wstępnej kompilacji obrazu systemu, opcje kompilacji dex2oat oraz sposoby kompromisu w zakresie miejsca na partycji systemowej, miejsca na 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 Weryfikowanie zachowania aplikacji w środowisku wykonawczym Androida (ART) , aby upewnić się, że aplikacje działają poprawnie.

Jak działa ART?

ART używa kompilacji z wyprzedzeniem (AOT), a począwszy od systemu Android 7.0 (Nougat lub N), używa hybrydowej kombinacji AOT, kompilacji just-in-time (JIT) i kompilacji sterowanej profilem. Kombinacja wszystkich tych trybów kompilacji jest konfigurowalna i zostanie omówiona w tej sekcji. Na przykład urządzenia Pixel są skonfigurowane z następującym przepływem kompilacji:

  1. Aplikacja jest początkowo instalowana bez kompilacji AOT. Przy pierwszych kilku uruchomieniach aplikacji jest ona interpretowana, a często wykonywane metody są kompilowane JIT.
  2. Gdy urządzenie jest bezczynne i ładuje się, demon kompilacji uruchamia się, aby skompilować często używany kod AOT na podstawie profilu wygenerowanego podczas pierwszych uruchomień.
  3. Następne ponowne uruchomienie aplikacji używa kodu sterowanego profilem i unikaj wykonywania kompilacji JIT w czasie wykonywania dla metod już skompilowanych. Metody, które zostaną skompilowane JIT podczas nowych uruchomień, są dodawane do profilu, który następnie zostanie pobrany przez demona kompilacji.

ART zawiera kompilator (narzędzie dex2oat ) i środowisko uruchomieniowe ( libart.so ), które jest ładowane do uruchamiania Zygote. Narzędzie dex2oat pobiera plik APK i generuje jeden lub więcej plików artefaktów kompilacji, które są ładowane przez środowisko wykonawcze. Liczba plików, ich rozszerzenia i nazwy mogą ulec zmianie w różnych wydaniach, ale od wydania Androida 8 generowane są pliki:

  • .vdex : zawiera nieskompresowany kod DEX pakietu APK z dodatkowymi metadanymi przyspieszającymi weryfikację.
  • .odex : zawiera skompilowany kod AOT dla metod w APK.
  • .art (optional) : zawiera wewnętrzne reprezentacje ART niektórych ciągów i klas wymienionych w APK, używane do przyspieszenia uruchamiania aplikacji.

Opcje kompilacji

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

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

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

  • verify : uruchom tylko weryfikację kodu DEX.
  • quicken : (usunięty od Androida 12) 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

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

  • Kod ścieżki startowej klasy: domyślnie skompilowany z filtrem kompilatora speed-profile .
  • Kod serwera systemowego (zobacz 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 (AOSP eksperymentalny)) skompilowany domyślnie z filtrem kompilatora speed-profile lub skompilowany z filtrem kompilatora speed , jeśli nie podano profilu.
    • (do Androida 13) domyślnie skompilowany z filtrem kompilatora speed .
    Konfigurowalny za pomocą PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (patrz dalej w tym dokumencie).
  • Podstawowe aplikacje specyficzne dla produktu (zobacz PRODUCT_DEXPREOPT_SPEED_APPS w dalszej części tego dokumentu): domyślnie kompilowane 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 podany.

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

Opcje Makefile

  • WITH_DEXPREOPT

    • Czy dex2oat jest wywoływany na kodzie DEX zainstalowanym w obrazie systemu. Domyślnie włączone.

  • DONT_DEXPREOPT_PREBUILTS (od Androida 5)

    • Włączenie DONT_DEXPREOPT_PREBUILTS zapobiega wstępnej optymalizacji prekompilowanych. Są to aplikacje, które include $(BUILD_PREBUILT) określone w ich Android.mk . Pomijanie wstępnej optymalizacji wstępnie utworzonych aplikacji, które prawdopodobnie będą aktualizowane przez Google Play, oszczędza miejsce w obrazie systemu, ale wydłuża czas pierwszego uruchomienia. Pamiętaj, ż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 wstępnie zoptymalizowanych aplikacji. Te aplikacje są zdefiniowane w Android.bp lub include $(BUILD_PREBUILT) określone w ich Android.mk . Jeśli nie jest określona, ​​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 (nowość w Androidzie 8 MR1)

    • Włączenie WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY wstępnie optymalizuje tylko ścieżkę klasy rozruchu i pliki jar serwera systemowego.

  • LOCAL_DEX_PREOPT

    • Wstępną optymalizację można również 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 wstępnej optymalizacji aplikacji, które mogą od razu otrzymywać aktualizacje Google Play, ponieważ aktualizacje sprawią, że wstępnie zoptymalizowany kod w obrazie systemu stanie 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”, odpowiednio, aby włączyć lub wyłączyć wstępną optymalizację. Ponadto można określić „nostripping”, jeśli wstępna optymalizacja nie powinna usuwać pliku classes.dex z pliku APK lub JAR. Zwykle ten plik jest usuwany, ponieważ nie jest już potrzebny po wstępnej optymalizacji, ale ta ostatnia opcja jest konieczna, aby umożliwić zachowanie ważności podpisów APK innych firm.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Przekazuje opcje do dex2oat , aby kontrolować sposób kompilowania obrazu rozruchowego. Może służyć do określania niestandardowych list klas obrazów, skompilowanych list klas i filtrów kompilatora.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Przekazuje opcje do dex2oat , aby kontrolować sposób kompilowania wszystkiego poza obrazem rozruchowym.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Zapewnia możliwość przekazania opcji dex2oat dla konkretnego modułu i konfiguracji produktu. Jest ustawiany w pliku device.mk produktu przez $(call add-product-dex-preopt-module-config,<modules>,<option>) gdzie <modules> to lista nazw LOCAL_MODULE i LOCAL_PACKAGE dla JAR i APK pliki, odpowiednio.

  • PRODUCT_DEXPREOPT_SPEED_APPS (New in Android 8)

    • Lista aplikacji, które zostały zidentyfikowane jako podstawowe dla produktów i które są pożądane do kompilacji za pomocą filtra kompilatora speed . Na przykład trwałe aplikacje, takie jak SystemUI, mają szansę na użycie kompilacji sterowanej profilem tylko przy następnym ponownym uruchomieniu, więc może być lepiej, aby produkt zawsze był kompilowany AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (New in Android 8)

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

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD(Post Android 8)

    • Czy dołączyć na urządzeniu wersję ART do debugowania. Domyślnie jest to włączone dla kompilacji userdebug i eng. Zachowanie można zastąpić, jawnie ustawiając opcję na true lub false .

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

  • WITH_DEXPREOPT_PIC (Removed in Android 8)

    • W Android 5.1.0 do Android 6.0.1, WITH_DEXPREOPT_PIC można określić, 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. Istnieje jednak niewielki wpływ na środowisko uruchomieniowe, ponieważ wyłącza optymalizację wykorzystującą kod zależny od pozycji. Zazwyczaj urządzenia, które chcą zaoszczędzić miejsce w /data, powinny umożliwiać kompilację PIC.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (usunięty w Androidzie 8 MR1)

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

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

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

    • (od Android 14 (AOSP eksperymentalny)) Jeśli nie określono, jest używany filtr kompilatora speed-profile prędkości lub filtr kompilatora speed , jeśli nie podano profilu.
    • (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 ustawiona na speed-profile , używany jest filtr kompilatora speed-profile lub filtr kompilatora verify , jeśli nie podano profilu.
    • Jeśli ustawiono wartość verify 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, które są ładowane przez serwer systemowy. JAR są kompilowane z filtrem kompilatora określonym przez PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (wymagane) PRODUCT_SYSTEM_SERVER_JARS : Lista plików JAR ścieżki klas serwera systemowego na platformie (tj. jako część SYSTEMSERVERCLASSPATH ). Dodanie plików JAR ścieżki klas serwera systemowego do tej listy jest wymagane. Niepowodzenie dodania plików jar ścieżki klas serwera systemowego do listy powoduje, że te pliki nie są ładowane.
    • (wymagane) PRODUCT_APEX_SYSTEM_SERVER_JARS : Lista plików jar ścieżki klas serwera systemowego dostarczanych przez apex (tj. jako część SYSTEMSERVERCLASSPATH ). Format to <apex name>:<jar name> . Dodanie do tej listy plików JAR ścieżki klas serwera apex system jest wymagane. Niepowodzenie dodania plików JAR ścieżki klas serwera systemu apex do tej listy spowoduje, że te JAR nie zostaną załadowane.
    • (opcjonalnie, od Androida 13) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : Lista plików jar, które serwer systemowy ładuje dynamicznie przy użyciu oddzielnych programów ładujących klasy (za pośrednictwem SystemServiceManager.startServiceFromJar ). Dodanie do tej listy autonomicznych plików jar serwera systemowego nie jest wymagane, ale zdecydowanie zalecane, ponieważ powoduje to kompilację plików jar i zapewnia dobrą wydajność w czasie wykonywania.
    • (wymagane, od Androida 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : Lista plików jar dostarczanych przez wierzchołek, które serwer systemowy ładuje dynamicznie przy użyciu oddzielnych programów ładujących klasy (tj. za pośrednictwem SystemServiceManager.startServiceFromJar lub zadeklarowanych jako <apex-system-service> ). Format to <apex name>:<jar name> . Dodanie do tej listy autonomicznych plików jar serwera systemu apex jest wymagane. Niepowodzenie dodania plików jar serwera autonomicznego systemu apex do tej listy skutkuje niepowodzeniem rozruchu.

    Konfiguracja ścieżki klasy rozruchowej

    • Lista wstępnie załadowanych klas

      • 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 im szybciej uruchamiać się i udostępniać strony w pamięci. Wstępnie załadowany plik listy 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 strojenia; 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 device.mk produktu):

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

      Uwaga: Ta linia musi być umieszczona przed odziedziczeniem jakichkolwiek plików makefile konfiguracji produktu, które pobierają domyślny z: build/target/product/base.mk

    Konfiguracja uruchomieniowa

    Opcje Jit

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

    • dalvik.vm.usejit: czy JIT jest włączony.
    • dalvik.vm.jitinitialsize (domyślnie 64K): początkowa pojemność pamięci podręcznej kodu. Pamięć podręczna kodu będzie regularnie GC i zwiększać się w razie potrzeby.
    • dalvik.vm.jitmaxsize (domyślnie 64M): maksymalna pojemność pamięci podręcznej kodu.
    • dalvik.vm.jitthreshold: (domyślnie 10000) — jest to próg, który musi przekroczyć licznik „gorący” metody, aby metoda została skompilowana JIT. Licznik „gorących” to metryka wewnętrzna środowiska wykonawczego. Obejmuje liczbę połączeń, wsteczne gałęzie i inne czynniki.
    • dalvik.vm.usejitprofiles: czy włączone są profile JIT; może to być użyte, nawet jeśli dalvik.vm.usejit jest fałszywe. Zwróć uwagę, że jeśli to jest fałszywe, filtr kompilatora speed-profile nie kompiluje AOT żadnej metody i jest równoważny z verify .
    • 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 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 interpreterem. Pomaga to upewnić się, że zaangażowane metody są kompilowane w celu zminimalizowania przejść (które są kosztowne).

    Opcje menedżera pakietów

    Od wersji Androida 7.0 istnieje ogólny sposób określania poziomu kompilacji/weryfikacji, która miała miejsce na różnych etapach. Poziomy kompilacji można skonfigurować we właściwościach systemu, przy czym wartości domyślne to:

    • pm.dexopt.install=speed-profile

      • Jest to filtr kompilacji używany podczas instalowania aplikacji przez Google Play. Zalecamy ustawienie filtra instalacji na speed-profile, aby umożliwić korzystanie z profili z plików metadanych dex. Pamiętaj, że jeśli profil nie jest podany lub jest pusty, speed-profile jest równoznaczne z weryfikacją.

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

      • Jest to filtr kompilacji używany, gdy urządzenie jest bezczynne, ładuje się i jest w pełni naładowane. Wypróbuj filtr kompilatora speed-profile , aby skorzystać z kompilacji sterowanej profilami i zaoszczędzić na pamięci.

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

      • Filtr kompilacji używany po aktualizacji bezprzewodowej. Zdecydowanie zalecamy filtr verify kompilatora dla tej opcji, aby uniknąć bardzo długich czasów uruchamiania.

    • pm.dexopt.first-boot=verify

    • Filtr kompilacji po raz pierwszy w historii rozruchu urządzenia. Zastosowany tutaj filtr wpływa tylko na czas rozruchu po fabryce. Zalecamy verify filtra, aby uniknąć długiego czasu, zanim użytkownik zacznie korzystać z telefonu po raz pierwszy. Zwróć uwagę, że jeśli wszystkie aplikacje w obrazie systemu są już skompilowane za pomocą verify , speed-profile lub speed z odpowiednim kontekstem programu ładującego klasy, pm.dexopt.first-boot nie przyniesie żadnego efektu.

    Opcje Dex2oat

    Należy zauważyć, że te opcje wpływają na dex2oat podczas kompilacji na urządzeniu, a także podczas wstępnej optymalizacji, podczas gdy większość omówionych powyżej opcji wpływa tylko na wstępną optymalizację.

    Aby kontrolować dex2oat podczas kompilowania obrazu rozruchowego:

    • dalvik.vm.image-dex2oat-Xms: początkowy rozmiar sterty
    • dalvik.vm.image-dex2oat-Xmx: maksymalny rozmiar sterty
    • dalvik.vm.image-dex2oat-filter: opcja filtra kompilatora
    • dalvik.vm.image-dex2oat-threads: liczba wątków do użycia

    Aby kontrolować dex2oat podczas kompilacji wszystkiego oprócz obrazu rozruchowego:

    • dalvik.vm.dex2oat-Xms: początkowy rozmiar sterty
    • dalvik.vm.dex2oat-Xmx: maksymalny rozmiar sterty
    • dalvik.vm.dex2oat-filter: opcja filtra kompilatora

    W wersjach do Androida 6.0 dostępna jest jedna dodatkowa opcja kompilacji wszystkiego oprócz obrazu rozruchowego:

    • dalvik.vm.dex2oat-threads: liczba wątków do użycia

    Począwszy od Androida 6.1, stają się to dwie dodatkowe opcje kompilacji wszystkiego oprócz obrazu rozruchowego:

    • dalvik.vm.boot-dex2oat-threads: liczba wątków do użycia podczas uruchamiania
    • dalvik.vm.dex2oat-threads: liczba wątków do użycia po uruchomieniu

    Począwszy od Androida 7.1, dostępne są dwie opcje kontrolowania wykorzystania pamięci podczas kompilowania wszystkiego oprócz obrazu rozruchowego:

    • dalvik.vm.dex2oat-very-large: minimalny całkowity rozmiar pliku dex w bajtach, aby wyłączyć kompilację AOT
    • dalvik.vm.dex2oat-swap: użyj pliku wymiany dex2oat (dla urządzeń o małej ilości pamięci)

    Opcje kontrolujące początkową i maksymalną wielkość sterty dla dex2oat nie powinny być zmniejszane, ponieważ mogą one ograniczać ilość aplikacji, które można skompilować.

    Począwszy od Androida 11, dostępne są trzy opcje koligacji procesora, aby umożliwić ograniczenie wątków kompilatora do określonej grupy procesorów:

    • dalvik.vm.boot-dex2oat-cpu-set: procesory uruchamiające wątki dex2oat podczas rozruchu
    • dalvik.vm.image-dex2oat-cpu-set: procesory z uruchomionym dex2oat podczas kompilowania obrazu rozruchowego
    • dalvik.vm.dex2oat-cpu-set: procesory uruchamiające wątki dex2oat po uruchomieniu

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

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

    Podczas ustawiania właściwości koligacji procesora zalecamy dopasowanie odpowiedniej właściwości dla liczby wątków dex2oat w celu dopasowania 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

    Począwszy od Androida 12 dodano następujące opcje:

    • dalvik.vm.ps-min-first-save-ms: czas oczekiwania na wygenerowanie profilu aplikacji przy pierwszym uruchomieniu aplikacji
    • dalvik.vm.ps-min-save-period-ms: minimalny czas oczekiwania przed aktualizacją profilu aplikacji
    • dalvik.vm.systemservercompilerfilter: filtr kompilatora używany przez urządzenie podczas rekompilacji serwera systemowego

    Konfiguracja specyficzna dla A/B

    Konfiguracja ROM

    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. Są one następnie 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

    A w BoardConfig.mk urządzenia :

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Należy zauważyć, że kod ścieżki klasy startowej, kod serwera systemowego i podstawowe aplikacje specyficzne dla produktu zawsze są kompilowane na partycji systemowej. Domyślnie wszystkie inne aplikacje są kompilowane na nieużywanej drugiej partycji systemowej. Można to kontrolować za pomocą SYSTEM_OTHER_ODEX_FILTER , który ma domyślną wartość:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Wyszukiwarka tła OTA

    W przypadku urządzeń obsługujących A/B aplikacje można kompilować w tle w celu aktualizacji do nowego obrazu 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 kierowanej profilem i zaoszczędzić na pamięci.