Configura ART

Questa pagina illustra come configurare il runtime Android (ART) e le relative opzioni di compilazione. Gli argomenti affrontati qui includono la configurazione della precompilazione dell'immagine di sistema, le opzioni di compilazione dex2oat e come bilanciare lo spazio della partizione di sistema, lo spazio della partizione dei dati e le prestazioni.

Vedi ART e Dalvik e il formato eseguibile Dalvik per lavorare con ART. Consulta Verifica del comportamento delle app su Android Runtime (ART) per garantire che le tue app funzionino correttamente.

Come funziona l'ARTE

ART utilizza la compilazione anticipata (AOT) e, a partire da Android 7, utilizza una combinazione ibrida di compilazione AOT, compilazione just-in-time (JIT) e interpretazione e la compilazione AOT può essere guidata dal profilo. La combinazione di tutte queste modalità di esecuzione è configurabile e verrà discussa in questa sezione. Ad esempio, i dispositivi Pixel sono configurati per funzionare nel seguente flusso:

  1. Un'applicazione viene inizialmente installata con un file di metadati dex ( .dm ) distribuito da Play Store, che contiene un profilo cloud. ART AOT compila i metodi elencati nel profilo cloud. Oppure, se l'applicazione viene installata senza un file di metadati dex, non viene eseguita alcuna compilazione AOT.
  2. Le prime volte in cui viene eseguita l'applicazione, vengono interpretati i metodi che non sono compilati AOT. Tra i metodi interpretati, quelli che vengono eseguiti frequentemente vengono poi compilati JIT. ART genera un profilo locale in base all'esecuzione e lo combina con il profilo cloud (se ne esiste uno).
  3. Quando il dispositivo è inattivo e in carica, viene eseguito un demone di compilazione per ricompilare l'applicazione in base al profilo combinato generato durante le prime esecuzioni.
  4. Nelle esecuzioni successive dell'applicazione, ART utilizza gli artefatti generati dal demone di compilazione, che contengono più codice compilato AOT, rispetto a quelli generati durante I metodi che non sono compilati AOT vengono comunque interpretati o compilati JIT. ART aggiorna l'installazione del profilo, in base all'esecuzione, e il profilo verrà poi prelevato dalle successive esecuzioni del demone di compilazione.

ART comprende un compilatore (lo strumento dex2oat ) e un runtime ( libart.so ) che viene caricato durante l'avvio. Lo strumento dex2oat accetta un file APK e genera uno o più file di artefatti di compilazione caricati dal runtime. Il numero di file, le relative estensioni e nomi sono soggetti a modifiche tra le versioni, ma a partire dalla versione Android 8 vengono generati questi file:

  • .vdex : contiene alcuni metadati aggiuntivi per velocizzare la verifica, a volte insieme al codice DEX non compresso dell'APK.
  • .odex : contiene il codice compilato AOT per i metodi nell'APK.
  • .art (optional) contiene rappresentazioni interne ART di alcune stringhe e classi elencate nell'APK, utilizzate per velocizzare l'avvio dell'app.

Opzioni di compilazione

Esistono due categorie di opzioni di compilazione per ART:

  1. Configurazione della ROM di sistema: quale codice viene compilato AOT durante la creazione di un'immagine di sistema.
  2. Configurazione runtime: come ART compila ed esegue app su un dispositivo.

Filtri del compilatore

Un'opzione ART fondamentale per configurare queste due categorie sono i filtri del compilatore . I filtri del compilatore determinano il modo in cui ART compila il codice DEX ed è un'opzione passata allo strumento dex2oat . A partire da Android 8, ci sono quattro filtri ufficialmente supportati:

  • verify : esegue solo la verifica del codice DEX (nessuna compilazione AOT).
  • quicken : (fino ad Android 11) esegui la verifica del codice DEX e ottimizza alcune istruzioni DEX per ottenere prestazioni migliori dell'interprete.
  • speed : esegui la verifica del codice DEX e compila AOT tutti i metodi.
  • speed-profile : esegue la verifica del codice DEX e i metodi di compilazione AOT elencati in un file di profilo.

Configurazione della ROM di sistema

Le librerie e le app preinstallate vengono compilate AOT durante la creazione di un'immagine di sistema. Questo processo è chiamato dexpreopt . Tali file compilati sono utilizzabili finché tutte le dipendenze rimangono invariate, in particolare il classpath di avvio.

Nota: se il dispositivo accetta aggiornamenti del modulo di sistema , è molto probabile che il classpath di avvio cambi nell'aggiornamento successivo, rendendo tutti i file dexpreopt obsoleti e inutilizzabili.

Sono disponibili numerose opzioni di build ART per la configurazione di dexpreopt. La modalità di configurazione di queste opzioni dipende dallo spazio di archiviazione disponibile per l'immagine del sistema e dal numero di applicazioni preinstallate. I JAR/APK compilati in una ROM di sistema possono essere suddivisi in quattro categorie:

  • Codice del percorso di classe di avvio: compilato con il filtro del compilatore speed-profile per impostazione predefinita.
  • Codice del server di sistema (vedi PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS più avanti in questo documento):
    • (Android 14 e versioni successive) Compilato con il filtro del compilatore speed-profile per impostazione predefinita o compilato con il filtro del compilatore speed se non viene fornito un profilo.
    • (Android 13 e versioni precedenti) Compilato con il filtro del compilatore speed per impostazione predefinita.
    Configurabile tramite PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (vedere più avanti in questo documento).
  • App principali specifiche del prodotto (vedi PRODUCT_DEXPREOPT_SPEED_APPS più avanti in questo documento): compilate con il filtro del compilatore speed per impostazione predefinita.
  • Tutte le altre app: compilate con il filtro del compilatore del speed-profile per impostazione predefinita o compilate con il filtro del compilatore verify se non viene fornito un profilo.

    Configurabile tramite PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (vedere più avanti in questo documento).

Opzioni del makefile

  • WITH_DEXPREOPT
  • Se dex2oat viene richiamato sul codice DEX installato sull'immagine di sistema. Abilitato per impostazione predefinita.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 e versioni successive)
  • L'abilitazione DONT_DEXPREOPT_PREBUILTS impedisce la dexpreoptazione delle versioni predefinite. Queste sono le app che hanno include $(BUILD_PREBUILT) specificata nel loro Android.mk . Saltare la dexpreopt delle app predefinite che potrebbero essere aggiornate tramite Google Play consente di risparmiare spazio nell'immagine di sistema ma aumenta il tempo di avvio. Tieni presente che questa opzione non ha alcun effetto sulle app predefinite definite in Android.bp .

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 e versioni successive)
  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER specifica il filtro del compilatore predefinito per le applicazioni dexpreoptate. Queste app sono definite in Android.bp o hanno include $(BUILD_PREBUILT) specificata nel relativo Android.mk . Se non specificato, il valore predefinito è speed-profile oppure verify se il valore non è specificato e non viene fornito un profilo.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (da Android 8 MR1)
  • L'abilitazione di WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopta solo il classpath di avvio e i jar del server di sistema.

  • LOCAL_DEX_PREOPT
  • Dexpreopt può anche essere abilitato o disabilitato in base alla singola app specificando l'opzione LOCAL_DEX_PREOPT nella definizione del modulo. Ciò può essere utile per disabilitare il dexpreopt delle app che potrebbero ricevere immediatamente gli aggiornamenti di Google Play poiché gli aggiornamenti renderebbero obsoleto il codice dexpreopt nell'immagine di sistema. Ciò è utile anche per risparmiare spazio sugli OTA di aggiornamento della versione principale perché gli utenti potrebbero già avere versioni più recenti delle app nella partizione dati.

    LOCAL_DEX_PREOPT supporta i valori true o false per abilitare o disabilitare rispettivamente dexpreopt. Inoltre è possibile specificare nostripping se dexpreopt non deve rimuovere il classes.dex dal file APK o JAR. Normalmente questo file viene rimosso poiché non è più necessario dopo dexpreopt, ma quest'ultima opzione è necessaria per consentire alle firme APK di terze parti di rimanere valide.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS
  • Passa le opzioni a dex2oat per controllare come viene compilata l'immagine di avvio. Può essere utilizzato per specificare elenchi personalizzati di classi di immagini, elenchi di classi compilate e filtri del compilatore.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
  • Passa le opzioni a dex2oat per controllare come viene compilato tutto tranne l'immagine di avvio.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS
  • Fornisce la possibilità di passare le opzioni dex2oat per un particolare modulo e configurazione del prodotto. È impostato nel file device.mk di un prodotto da $(call add-product-dex-preopt-module-config,<modules>,<option>) dove <modules> è un elenco di nomi LOCAL_MODULE e LOCAL_PACKAGE per i file JAR e APK , rispettivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (da Android 8)
  • Elenco di app identificate come fondamentali per i prodotti e che è consigliabile compilare con il filtro del compilatore speed . Ad esempio, le app persistenti come SystemUI hanno la possibilità di utilizzare la compilazione guidata dal profilo solo al successivo riavvio, quindi potrebbe essere meglio per il prodotto avere queste app sempre compilate AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (da Android 8)
  • Elenco delle app caricate dal server di sistema. Queste app vengono compilate per impostazione predefinita con il filtro del compilatore speed .

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (da Android 8)
  • Se includere una versione di debug di ART nel dispositivo. Per impostazione predefinita, questo è abilitato per userdebug ed eng build. Il comportamento può essere sovrascritto impostando esplicitamente l'opzione su true o false .

    Per impostazione predefinita, il dispositivo utilizza la versione non debug ( libart.so ). Per cambiare, impostare la proprietà di sistema persist.sys.dalvik.vm.lib.2 su libartd.so .

  • WITH_DEXPREOPT_PIC (fino ad Android 7)
  • In Android da 5.1.0 a Android 6.0.1, è possibile specificare WITH_DEXPREOPT_PIC per abilitare il codice indipendente dalla posizione (PIC). In questo modo, il codice compilato dall'immagine non deve essere riposizionato da /system a /data/dalvik-cache , risparmiando spazio nella partizione dati. Tuttavia, c'è un leggero impatto sul runtime perché disabilita un'ottimizzazione che sfrutta il codice dipendente dalla posizione. In genere, i dispositivi che desiderano risparmiare spazio in /data dovrebbero abilitare la compilazione PIC.

    In Android 7.0, la compilazione PIC era abilitata per impostazione predefinita.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (fino ad Android 7 MR1)
  • Questa opzione è stata sostituita con WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY che preopta anche i JAR del server di sistema.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
  • Questa opzione specifica il filtro del compilatore per il server di sistema.

    • (Android 14 e versioni successive) Se non specificato, viene utilizzato il filtro del compilatore speed-profile oppure viene utilizzato il filtro del compilatore speed se non viene fornito un profilo.
    • (Android 13 e versioni precedenti) Se non specificato, viene utilizzato il filtro del compilatore speed .
    • Se impostato su speed , viene utilizzato il filtro del compilatore speed .
    • Se impostato su speed-profile , viene utilizzato il filtro del compilatore del speed-profile oppure viene utilizzato il filtro del compilatore verify se non viene fornito un profilo.
    • Se impostato su verify , viene utilizzato il filtro del compilatore verify .

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
  • Di seguito sono riportati gli elenchi di JAR caricati dal server di sistema. I JAR vengono compilati con il filtro del compilatore specificato da PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obbligatorio) PRODUCT_SYSTEM_SERVER_JARS : elenco dei JAR del classpath del server di sistema sulla piattaforma (ovvero, come parte di SYSTEMSERVERCLASSPATH ). È necessario aggiungere i JAR del percorso di classe del server di sistema a questo elenco. Se non si aggiungono i JAR del percorso di classe del server di sistema all'elenco, tali JAR non verranno caricati.
    • (Obbligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS : elenco dei JAR del percorso di classe del server di sistema forniti con APEX (ovvero come parte di SYSTEMSERVERCLASSPATH ). Il formato è <apex name>:<jar name> . È necessario aggiungere i JAR del percorso di classe del server di sistema APEX a questo elenco. Se non si aggiungono i JAR del percorso di classe del server di sistema APEX a questo elenco, tali JAR non verranno caricati.
    • (Facoltativo, Android 13 e versioni precedenti) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : elenco di JAR che il server di sistema carica dinamicamente utilizzando classloader separati (tramite SystemServiceManager.startServiceFromJar ). L'aggiunta di JAR di server di sistema autonomi a questo elenco non è necessaria ma fortemente consigliata perché rende i JAR compilati e quindi hanno buone prestazioni di runtime.
    • (richiesto a partire da Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : elenco di JAR forniti con APEX che il server di sistema carica dinamicamente utilizzando classloader separati (ovvero tramite SystemServiceManager.startServiceFromJar o dichiarato come <apex-system-service> ). Il formato è <apex name>:<jar name> . È necessario aggiungere JAR del server di sistema APEX autonomo a questo elenco. La mancata aggiunta dei JAR del server di sistema APEX autonomo a questo elenco provoca un errore di avvio.

    Configurazione del percorso di classe di avvio

    L'elenco delle classi precaricate è un elenco di classi che Zygote inizializza all'avvio. Ciò evita a ciascuna app di dover eseguire questi inizializzatori di classe separatamente, consentendo loro di avviarsi più velocemente e condividere le pagine in memoria. Per impostazione predefinita, il file dell'elenco delle classi precaricate si trova in frameworks/base/config/preloaded-classes e contiene un elenco ottimizzato per l'utilizzo tipico del telefono. Questo potrebbe essere diverso per altri dispositivi come i dispositivi indossabili e deve essere regolato di conseguenza. Fai attenzione quando lo sintonizzi; l'aggiunta di troppe classi spreca memoria quando vengono caricate le classi inutilizzate. L'aggiunta di un numero troppo basso di classi costringe ciascuna app a dover avere la propria copia, il che, ancora una volta, spreca memoria.

    Esempio di utilizzo (nel device.mk del prodotto):

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

    Nota: è necessario inserire questa riga prima di ereditare qualsiasi makefile di configurazione del prodotto che ottiene quello predefinito da build/target/product/base.mk .

    Configurazione in fase di esecuzione

    Opzioni JIT

    Le opzioni seguenti influiscono sulle versioni Android solo in cui è disponibile il compilatore ART JIT.

    • dalvik.vm.usejit : indica se il JIT è abilitato o meno.
    • dalvik.vm.jitinitialsize (predefinito 64K): la capacità iniziale della cache del codice. La cache del codice verrà regolarmente GC e aumenterà se necessario.
    • dalvik.vm.jitmaxsize (predefinito 64M): la capacità massima della cache del codice.
    • dalvik.vm.jitthreshold (predefinito 10000): la soglia che il contatore "hotness" di un metodo deve superare affinché il metodo venga compilato JIT. Il contatore "hotness" è una metrica interna al runtime. Include il numero di chiamate, diramazioni a ritroso e altri fattori.
    • dalvik.vm.usejitprofiles (fino ad Android 13): se i profili JIT sono abilitati o meno; questo può essere utilizzato anche se dalvik.vm.usejit è falso. Si noti che se ciò è falso, il speed-profile del filtro del compilatore non compila AOT alcun metodo ed è equivalente a verify . A partire da Android 14, i profili JIT sono sempre abilitati e non possono essere disattivati.
    • dalvik.vm.jitprithreadweight (predefinito su dalvik.vm.jitthreshold / 20): il peso dei "campioni" JIT (vedi jitthreshold) per il thread dell'interfaccia utente dell'applicazione. Utilizzare per accelerare la compilazione di metodi che influiscono direttamente sull'esperienza degli utenti durante l'interazione con l'app.
    • dalvik.vm.jittransitionweight (predefinito su dalvik.vm.jitthreshold / 10): il peso dell'invocazione del metodo che effettua la transizione tra il codice di compilazione e l'interprete. Ciò aiuta a garantire che i metodi coinvolti siano compilati per ridurre al minimo le transizioni (che sono costose).

    Opzioni Dex2oat

    Queste opzioni influiscono sulla compilazione sul dispositivo (nota anche come dexopt ) e alcune di esse influiscono anche su dexpreopt, mentre le opzioni discusse nella sezione di configurazione della ROM di sistema sopra influiscono solo su dexpreopt.

    Opzioni per controllare l'utilizzo delle risorse:

    • dalvik.vm.image-dex2oat-threads / dalvik.vm.image-dex2oat-cpu-set (fino ad Android 11): il numero di thread e il set di core della CPU (vedi sotto) da utilizzare per le immagini di avvio.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (fino ad Android 11) Il numero di thread e il set di core della CPU (vedi sotto) da utilizzare durante l'avvio per tutto tranne le immagini di avvio.
      • (da Android 12) Il numero di thread e il set di core della CPU (vedi sotto) da utilizzare durante l'avvio per tutto, comprese le immagini di avvio.
        • Nello specifico, a partire da Android 14, ciò corrisponde alla classe di priorità PRIORITY_BOOT in ART Service.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (da Android 11 fino ad Android 13) Il numero di thread e il set di core della CPU (vedi sotto) da utilizzare per il ripristino dal backup nel cloud.
      • (da Android 14) Il numero di thread e il set di core della CPU (vedi sotto) da utilizzare per tutto ciò che è più sensibile alla latenza del normale, incluso il ripristino dal backup sul cloud.
        • Nello specifico, ciò corrisponde alla classe di priorità PRIORITY_INTERACTIVE_FAST in ART Service.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (da Android 14): il numero di thread e il set di core della CPU (vedi sotto) da utilizzare in background.
      • Nello specifico, ciò corrisponde alla classe di priorità PRIORITY_BACKGROUND in ART Service.
    • dalvik.vm.dex2oat-threads / dalvik.vm.dex2oat-cpu-set : il numero di thread e l'insieme di core della CPU da utilizzare per tutto il resto.

    Un set di core della CPU deve essere specificato come elenco di ID CPU separati da virgole. Ad esempio, per eseguire dex2oat sui core CPU 0-3, impostare:

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

    Quando si impostano le proprietà di affinità della CPU, si consiglia di far corrispondere la proprietà corrispondente per il numero di thread dex2oat al numero di CPU selezionate per evitare memoria non necessaria e conflitti di I/O:

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

    Oltre alle proprietà di sistema di cui sopra, puoi anche utilizzare i profili delle attività per controllare l'utilizzo delle risorse di dex2oat (vedi Cgroup Abstraction Layer ).

    I profili attività supportati sono:

    • Dex2OatBackground (da Android 14) (per impostazione predefinita eredita Dex2OatBootComplete ): controlla le risorse da utilizzare in background.
      • Nello specifico, ciò corrisponde alla classe di priorità PRIORITY_BACKGROUND in ART Service.
    • Dex2OatBootComplete :
      • (fino ad Android 13) Controlla la risorsa da utilizzare per tutto dopo l'avvio.
      • (da Android 14) Controlla la risorsa da utilizzare per tutto dopo l'avvio e non in background.
        • Nello specifico, ciò corrisponde alla classe di priorità PRIORITY_INTERACTIVE_FAST e PRIORITY_INTERACTIVE in ART Service.

    Quando vengono specificati sia le proprietà del sistema che i profili delle attività, entrambi hanno effetto.

    Opzioni per controllare la dimensione dell'heap:

    • dalvik.vm.image-dex2oat-Xms : dimensione heap iniziale per le immagini di avvio.
    • dalvik.vm.image-dex2oat-Xmx : dimensione heap massima per le immagini di avvio.
    • dalvik.vm.dex2oat-Xms : dimensione heap iniziale per tutto il resto.
    • dalvik.vm.dex2oat-Xmx : dimensione heap massima per tutto il resto.

    Le opzioni che controllano la dimensione heap iniziale e massima per dex2oat non dovrebbero essere ridotte poiché potrebbero limitare le applicazioni che possono essere compilate.

    Opzioni per controllare il filtro del compilatore:

    • dalvik.vm.image-dex2oat-filter (fino ad Android 11): il filtro del compilatore per le immagini di avvio. A partire da Android 12, il filtro del compilatore per le immagini di avvio è sempre speed-profile e non può essere modificato.
    • dalvik.vm.systemservercompilerfilter (da Android 13): il filtro del compilatore per il server di sistema. Vedi PRODUCT_SYSTEM_SERVER_COMPILER_FILTER .
    • dalvik.vm.systemuicompilerfilter (da Android 13): il filtro del compilatore per il pacchetto dell'interfaccia utente di sistema.
    • dalvik.vm.dex2oat-filter (fino ad Android 6): il filtro del compilatore per tutto il resto.
    • pm.dexopt.<reason> (da Android 7): il filtro del compilatore per tutto il resto. Consulta Configurazione del servizio ART per Android 14 e versioni successive o Configurazione di Gestione pacchetti per Android 13 e versioni successive.

    Altre opzioni per controllare la compilazione di tutto tranne le immagini di avvio:

    • dalvik.vm.dex2oat-very-large (da Android 7.1): dimensione minima totale del file dex in byte per disabilitare la compilazione AOT.
    • dalvik.vm.dex2oat-swap (da Android 7.1) (impostazione predefinita: true): consente di utilizzare un file di scambio per dex2oat. Ciò può aiutare a evitare arresti anomali per memoria insufficiente. Tieni presente che anche se questa opzione è attivata, dex2oat utilizzerà un file di scambio solo in determinate condizioni, ad esempio quando il numero di file dex è elevato e le condizioni sono soggette a modifiche.
    • dalvik.vm.ps-min-first-save-ms (da Android 12): il tempo minimo di attesa prima che il runtime generi un profilo dell'applicazione, la prima volta che l'applicazione viene avviata.
    • dalvik.vm.ps-min-save-period-ms (da Android 12): il tempo minimo di attesa prima di aggiornare il profilo dell'applicazione.
    • dalvik.vm.dex2oat64.enabled (da Android 11) (impostazione predefinita: false): se utilizzare la versione a 64 bit di dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (da Android 12) (impostazione predefinita: 20): la percentuale minima, compresa tra 0 e 100, di nuove classi in un profilo per attivare una ricompilazione. Applicabile solo alla compilazione guidata dal profilo ( speed-profile ), in genere durante il dexopt in background. Tieni presente che esiste anche una soglia di almeno 50 nuove classi oltre alla soglia percentuale e non è configurabile.
    • dalvik.vm.bgdexopt.new-methods-percent (da Android 12) (impostazione predefinita: 20): la percentuale minima, compresa tra 0 e 100, dei nuovi metodi in un profilo per attivare una ricompilazione. Applicabile solo alla compilazione guidata dal profilo ( speed-profile ), in genere durante il dexopt in background. Tieni presente che esiste anche una soglia di almeno 100 nuovi metodi oltre alla soglia percentuale e non è configurabile.
    • dalvik.vm.dex2oat-max-image-block-size (da Android 10) (impostazione predefinita: 524288) Dimensione massima del blocco solido per le immagini compresse. Un'immagine di grandi dimensioni viene divisa in una serie di blocchi solidi in modo tale che nessun blocco sia più grande della dimensione massima.
    • dalvik.vm.dex2oat-resolve-startup-strings (da Android 10) (impostazione predefinita: true) Se true, fa sì che dex2oat risolva tutte le const-string a cui fanno riferimento i metodi contrassegnati come "startup" nel profilo.
    • debug.generate-debug-info (default: false) Se generare o meno informazioni di debug per il debug nativo, come informazioni sullo svolgimento dello stack, simboli ELF e sezioni nane.
    • dalvik.vm.dex2oat-minidebuginfo (da Android 9) (impostazione predefinita: true) Indica se generare o meno una quantità minima di informazioni di debug compresse LZMA necessarie per stampare i backtrace.

    Opzioni del servizio ART

    A partire da Android 14, la compilazione AOT sul dispositivo per le app (nota anche come dexopt) è gestita da ART Service. Per informazioni sulla configurazione di ART Service, vedere Configurazione di ART Service .

    Opzioni del gestore pacchetti

    Prima di Android 14, la compilazione AOT sul dispositivo per le app (nota anche come dexopt) veniva gestita dal gestore pacchetti. Per informazioni sulla configurazione del gestore pacchetti per dexopt, consulta Configurazione del gestore pacchetti .

    Configurazione specifica A/B

    Configurazione della ROM

    A partire da Android 7.0, i dispositivi possono utilizzare due partizioni di sistema per abilitare gli aggiornamenti di sistema A/B . Per risparmiare sulla dimensione della partizione di sistema, i file preoptati possono essere installati nella seconda partizione di sistema non utilizzata. Vengono quindi copiati nella partizione dati al primo avvio.

    Esempio di utilizzo (in device-common.mk ):

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

    E nel BoardConfig.mk del dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true
    

    Tieni presente che il codice del percorso di classe di avvio, il codice del server di sistema e le app principali specifiche del prodotto vengono sempre compilati nella partizione di sistema. Per impostazione predefinita, tutte le altre app vengono compilate nella seconda partizione di sistema non utilizzata. Questo può essere controllato con SYSTEM_OTHER_ODEX_FILTER , che ha un valore per impostazione predefinita di:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%
    

    Background OTA dex

    Sui dispositivi abilitati A/B, le applicazioni possono essere compilate in background prima del riavvio con la nuova immagine di sistema. Vedi Compilazione dell'app in background per includere facoltativamente lo script di compilazione e i file binari nell'immagine di sistema. Il filtro di compilazione utilizzato per questa compilazione è controllato con:

    pm.dexopt.ab-ota=speed-profile
    

    Ti consigliamo di utilizzare speed-profile per sfruttare la compilazione guidata del profilo e risparmiare spazio di archiviazione.

    Opzioni JDWP

    La creazione del thread Java Debug Wire Protocol (JDWP) nelle build userdebug è controllata tramite la proprietà di sistema persist.debug.dalvik.vm.jdwp.enabled . Per impostazione predefinita, questa proprietà non è impostata e i thread JDWP vengono creati solo per le app di cui è possibile eseguire il debug. Per abilitare i thread JDWP sia per le app debuggabili che per quelle non debuggabili, imposta persist.debug.dalvik.vm.jdwp.enabled su 1 . Il dispositivo deve essere riavviato affinché le modifiche alla proprietà abbiano effetto.

    Per eseguire il debug di un'app non debuggabile su una build userdebug, abilita JDWP eseguendo il comando seguente:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
      adb reboot
      
    Per i dispositivi che eseguono Android 13 e versioni precedenti, il runtime crea thread JDWP per app di cui è possibile eseguire il debug e non su build di userdebug. Ciò significa che è possibile collegare un debugger o profilare qualsiasi app sulle build di userdebug.