Configura ART

Questa pagina spiega come configurare il runtime Android (ART) e le relative opzioni di compilazione. Gli argomenti trattati qui includono la configurazione della precompilazione dell'immagine di sistema, le opzioni di compilazione e come trovare il giusto equilibrio tra spazio della partizione di sistema, spazio della partizione di dati e prestazioni.dex2oat

Per lavorare con ART, consulta ART e Dalvik e il formato eseguibile Dalvik. Consulta la sezione Verificare il comportamento delle app in Android Runtime (ART) per assicurarti che le tue app funzionino correttamente.

Come funziona ART

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

  1. Un'applicazione viene inizialmente installata con un file di metadati dex (.dm) distribuito dal Play Store, che contiene un profilo cloud. ART AOT compila i metodi elencati nel profilo cloud. In alternativa, se l'applicazione è installata senza un file di metadati dex, non viene eseguita alcuna compilazione AOT.
  2. Le prime volte che l'applicazione viene eseguita, i metodi non compilati con AOT vengono interpretati. Tra i metodi interpretati, quelli eseguiti di frequente vengono compilati con la compilazione Just-in-time. ART genera un profilo locale in base all'esecuzione e lo combina con il profilo cloud (se esistente).
  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 elementi generati dal daemon di compilazione, che contengono più codice compilato AOT rispetto a quelli generati durante la compilazione. I metodi non compilati AOT vengono comunque interpretati o compilati JIT. ART aggiorna l'installazione del profilo in base all'esecuzione e il profilo verrà rilevato dalle esecuzioni successive del daemon di compilazione.

ART comprende un compilatore (lo strumento dex2oat) e un runtime (libart.so) che viene caricato durante l'avvio. Lo strumento dex2oat prende un file APK e genera uno o più file di elementi di compilazione che vengono caricati dal runtime. Il numero di file, le relative estensioni e i nomi sono soggetti a modifiche nelle varie release, ma a partire dalla release di Android 8 vengono generati i seguenti 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 di 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: il codice che viene compilato AOT durante la creazione di un'immagine di sistema.
  2. Configurazione di runtime: come ART compila ed esegue le app su un dispositivo.

Filtri del compilatore

Un'opzione di base di ART per configurare queste due categorie è compiler filters. I filtri del compilatore determinano il modo in cui ART compila il codice DEX e sono un'opzione passata allo strumento dex2oat. A partire da Android 8, sono disponibili quattro filtri ufficialmente supportati:

  • verify: esegue solo la verifica del codice DEX (nessuna compilazione AOT).
  • quicken: (Android 11 o versioni precedenti) esegue la verifica del codice DEX e ottimizza alcune istruzioni DEX per migliorare le prestazioni dell'interprete.
  • speed: esegue la verifica del codice DEX e compila AOT tutti i metodi. Non ottimizza il caricamento delle classi per nessuna classe.
  • speed-profile: esegue la verifica del codice DEX, compila i metodi AOT elencati nel profilo e ottimizza i caricamenti delle classi per le classi nel profilo.

Configurazione della ROM di sistema

Le app e le librerie preinstallate vengono compilate con AOT durante la creazione di un'immagine di sistema. Questo procedura è chiamata dexpreopt. Questi file compilati sono utilizzabili a condizione che tutte le dipendenze rimangano invariate, in particolare il percorso di classe di avvio.

Nota: se il dispositivo riceve aggiornamenti del modulo di sistema, è molto probabile che il percorso di classe di avvio cambi nel prossimo aggiornamento, il che rende tutti i file dexpreopt obsoleti e inutilizzabili.

Esistono diverse opzioni di compilazione ART disponibili per la configurazione di dexpreopt. La modalità di configurazione di queste opzioni dipende dallo spazio di archiviazione disponibile per l'immagine di sistema e dal numero di applicazioni preinstallate. I file 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 di seguito in questo documento):
    • (Android 14 e versioni successive) Compilato con il filtro del compilatore speed-profile per impostazione predefinita o 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 (vedi più avanti in questo documento).
  • App di base 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 speed-profile per impostazione predefinita o con il filtro del compilatore verify se non viene fornito un profilo.

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

Opzioni del file make

  • WITH_DEXPREOPT

    • Indica se dex2oat viene richiamato sul codice DEX installato nell'immagine di sistema. Questa opzione è abilitata per impostazione predefinita.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 e versioni successive)

    • L'attivazione di DONT_DEXPREOPT_PREBUILTS impedisce la disattivazione predefinita dei predefiniti. Si tratta di app in cui è specificato include $(BUILD_PREBUILT) nel file Android.mk. Se salti la compilazione preopt delle app precompilate che probabilmente verranno aggiornate tramite Google Play, risparmi spazio nell'immagine di sistema, ma il tempo di primo avvio aumenta. 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) specificato nel loro Android.mk. Se non specificato, il valore predefinito è speed-profile o 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'attivazione di WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts solo il classpath di avvio e i file JAR del server di sistema.

  • LOCAL_DEX_PREOPT

    • Dexpreopt può essere attivato o disattivato anche su base di app singola specificando l'opzione LOCAL_DEX_PREOPT nella definizione del modulo. Questa operazione può essere utile per disattivare la dexpreopt delle app che potrebbero ricevere immediatamente gli aggiornamenti di Google Play, poiché gli aggiornamenti renderebbero obsoleto il codice dexpreopt nell'immagine di sistema. Questo è utile anche per risparmiare spazio sulle OTA di upgrade della versione principale, perché gli utenti potrebbero già avere versioni più recenti delle app nella partizione dei dati.

    LOCAL_DEX_PREOPT supporta i valori true o false per attivare o disattivare rispettivamente dexpreopt. Inoltre, nostripping può essere specificato se dexpreopt non deve rimuovere il file classes.dex dal file APK o JAR. Normalmente questo file viene rimosso perché 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 la compilazione dell'immagine di avvio. Può essere utilizzato per specificare elenchi di classi di immagini personalizzate, elenchi di classi compilate e filtri del compilatore.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Passa le opzioni a dex2oat per controllare la compilazione di tutto ciò che non è l'immagine di avvio.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Offre la possibilità di passare opzioni dex2oat per un determinato modulo e una determinata configurazione del prodotto. Viene 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 che sono state 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 basata su profilo solo al riavvio successivo, quindi potrebbe essere meglio per il prodotto compilare sempre queste app con AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (da Android 8)

    • Elenco di 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)

    • Indica se includere una versione di debug di ART sul dispositivo. Per impostazione predefinita, questa opzione è attivata per le build userdebug ed eng. Il comportamento può essere ignorato impostando esplicitamente l'opzione su true o false.

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

  • WITH_DEXPREOPT_PIC (fino ad Android 7)

    • In Android 5.1.0 e versioni successive fino ad Android 6.0.1, è possibile specificare WITH_DEXPREOPT_PIC per attivare il codice indipendente dalla posizione (PIC). In questo modo, il codice compilato dell'immagine non deve essere spostato da /system a /data/dalvik-cache, risparmiando spazio nella partizione dei dati. Tuttavia, si verifica un lieve impatto in fase di runtime perché viene disattivata un'ottimizzazione che sfrutta il codice dipendente dalla posizione. In genere, i dispositivi che vogliono risparmiare spazio in /data devono attivare la compilazione PIC.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (fino ad Android 7 MR1)

    • Questa opzione è stata sostituita da WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY che pre-ottimizza anche i file 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 o 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 speed-profile oppure 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 dei file JAR caricati dal server di sistema. I file JAR vengono compilati con il filtro del compilatore specificato da PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obbligatorio) PRODUCT_SYSTEM_SERVER_JARS: elenco dei file JAR del percorso di classe del server di sistema sulla piattaforma (ovvero all'interno di SYSTEMSERVERCLASSPATH). L'aggiunta di file JAR del percorso di classe del server di sistema a questo elenco è obbligatoria. Se non aggiungi i file JAR del percorso di classe del server di sistema all'elenco, questi file JAR non verranno caricati.
    • (Obbligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS: elenco dei file JAR del percorso di classe del server di sistema fornito con APEX (ovvero come parte di SYSTEMSERVERCLASSPATH). Il formato è <apex name>:<jar name>. L'aggiunta dei file JAR del percorso di classe del server di sistema APEX a questo elenco è obbligatoria. Se non aggiungi i file JAR del percorso di classe del server di sistema APEX a questo elenco, questi file JAR non verranno caricati.
    • (Facoltativo, Android 13 e versioni precedenti) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: elenco dei file JAR che il server di sistema carica dinamicamente utilizzando classloader separati (tramite SystemServiceManager.startServiceFromJar). L'aggiunta di file JAR del server di sistema autonomi a questo elenco non è obbligatoria, ma vivamente consigliata perché consente di compilare i file JAR e quindi di avere un buon rendimento in fase di esecuzione.
    • (obbligatorio, da Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: elenco di JAR caricati 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>. L'aggiunta di file JAR del server di sistema APEX autonomi a questo elenco è obbligatoria. Se non aggiungi i file JAR del server di sistema APEX autonomi a questo elenco, si verifica un errore di avvio.

    Configurazione del percorso di classe di avvio

    L'elenco di classi precaricate è un elenco di classi inizializzate da Zygote all'avvio. In questo modo, ogni app non deve eseguire questi inizializzatori di classe separatamente, il che consente di avviarle più velocemente e di condividere le pagine in memoria. Il file dell'elenco di classi precaricate si trova in frameworks/base/config/preloaded-classes per impostazione predefinita e contiene un elenco ottimizzato per l'uso tipico dello smartphone. Questo valore potrebbe essere diverso per altri dispositivi, come i dispositivi indossabili, e deve essere regolato di conseguenza. Fai attenzione durante la regolazione: l'aggiunta di troppi classi comporta un utilizzo eccessivo della memoria quando vengono caricati i classi inutilizzati. L'aggiunta di un numero troppo ridotto di classi obbliga ogni app a avere la propria copia, il che, di nuovo, spreca memoria.

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

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

    Nota: devi inserire questa riga prima di ereditare i file make di configurazione del prodotto che ottengono quello predefinito da build/target/product/base.mk.

    Configurazione di runtime

    Opzioni JIT

    Le seguenti opzioni influiscono sulle release di Android solo dove è disponibile il compilatore JIT ART.

    • dalvik.vm.usejit: indica se JIT è attivo o meno.
    • dalvik.vm.jitinitialsize (valore predefinito 64 KB): la capacità iniziale della cache del codice. La cache di codice verrà regolarmente svuotata e aumentata, se necessario.
    • dalvik.vm.jitmaxsize (valore predefinito 64 M): la capacità massima della cache del codice.
    • dalvik.vm.jitthreshold (valore predefinito 10000): la soglia che il contatore "hotness" di un metodo deve superare affinché il metodo venga compilato con il JIT. Il contatore "hotness" è una metrica interna al runtime. Sono inclusi il numero di chiamate, i rami precedenti e altri fattori.
    • dalvik.vm.usejitprofiles (fino ad Android 13): indica se i profili JIT sono abilitati o meno. Questo valore può essere utilizzato anche se dalvik.vm.usejit è falso. Tieni presente che se questo valore è false, il filtro del compilatore speed-profile non compila alcun metodo con AOT ed è equivalente a verify. Da Android 14, i profili JIT sono sempre abilitati e non possono essere disattivati.
    • dalvik.vm.jitprithreadweight (valore predefinito dalvik.vm.jitthreshold / 20): il peso dei "samples" JIT (vedi jitthreshold) per il thread dell'interfaccia utente dell'applicazione. Da utilizzare per velocizzare la compilazione dei metodi che influiscono direttamente sull'esperienza degli utenti quando interagiscono con l'app.
    • dalvik.vm.jittransitionweight (valore predefinito dalvik.vm.jitthreshold / 10): il peso dell'invocazione del metodo che passa dal codice di compilazione all'interprete. In questo modo, puoi assicurarti che i metodi coinvolti vengano compilati per ridurre al minimo le transizioni (che sono costose).

    Opzioni Dex2oat

    Queste opzioni influiscono sulla compilazione sul dispositivo (ovvero su dexopt) e alcune influiscono anche su dexpreopt, mentre le opzioni discusse nella sezione Configurazione della ROM di sistema sopra incidono 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 l'insieme di core della CPU (vedi di seguito) 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 l'insieme di core della CPU (vedi di seguito) da utilizzare durante l'avvio per tutto ciò che non sono le immagini di avvio.
      • (da Android 12) Il numero di thread e l'insieme di core della CPU (vedi di seguito) da utilizzare durante l'avvio per tutto, incluse le immagini di avvio.
        • Nello specifico, a partire da Android 14, corrisponde alla classe di priorità PRIORITY_BOOT in ART Service.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (da Android 11 ad Android 13) Il numero di thread e l'insieme di core della CPU (vedi di seguito) da utilizzare per il ripristino dal backup sul cloud.
      • (da Android 14) Il numero di thread e l'insieme di core della CPU (vedi di seguito) da utilizzare per tutto ciò che è più sensibile alla latenza rispetto al normale, incluso il ripristino dal backup sul cloud.
        • Nello specifico, corrisponde alla classe di priorità PRIORITY_INTERACTIVE_FAST nel servizio ART.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (da Android 14): il numero di thread e l'insieme di core della CPU (vedi di seguito) da utilizzare in background.
      • Nello specifico, corrisponde alla classe di priorità PRIORITY_BACKGROUND nel servizio ART.
    • 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 insieme di core della CPU deve essere specificato come elenco di ID CPU separati da virgole. Ad esempio, per eseguire su dex2oat sui core della CPU 0-3, imposta:

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

    Quando imposti le proprietà di affinità della CPU, ti consigliamo di associare la proprietà corrispondente per il numero di thread dex2oat al numero di CPU selezionate per evitare concorrenze di memoria e I/O non necessarie: 

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

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

    I profili delle attività supportati sono:

    • Dex2OatBackground (da Android 14) (per impostazione predefinita eredita Dex2OatBootComplete): controlla le risorse da utilizzare in background.
      • Nello specifico, corrisponde alla classe di priorità PRIORITY_BACKGROUND nel servizio ART.
    • 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, corrisponde alla classe di priorità PRIORITY_INTERACTIVE_FAST e PRIORITY_INTERACTIVE nel servizio ART.

    Quando vengono specificate sia le proprietà di sistema sia i profili delle attività, entrambi vengono applicati.

    Opzioni per controllare la dimensione dell'heap:

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

    Le opzioni che controllano le dimensioni iniziali e massime dell'heap per dex2oat non devono essere ridotte, in quanto 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. 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. Consulta PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
    • dalvik.vm.systemuicompilerfilter (da Android 13): Il filtro del compilatore per il pacchetto UI di sistema.
    • dalvik.vm.dex2oat-filter (fino ad Android 6): Il filtro del compilatore per tutto il resto.
    • pm.dexopt.<reason> (da Android 7 in poi): il filtro del compilatore per tutto il resto. Consulta Configurazione del servizio ART per Android 14 e versioni successive oppure Configurazione del gestore pacchetti per Android 13 e versioni precedenti.

    Altre opzioni per controllare la compilazione di tutto ciò che non sono le immagini di avvio:

    • dalvik.vm.dex2oat-very-large (da Android 7.1): dimensione minima in byte del file dex totale per disattivare la compilazione AOT.
    • dalvik.vm.dex2oat-swap (da Android 7.1) (valore predefinito: true): consente di utilizzare un file di scambio per dex2oat. In questo modo puoi evitare arresti anomali dovuti a esaurimento di memoria. 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 da attendere prima che il runtime generi un profilo dell'applicazione la prima volta che viene avviata.
    • dalvik.vm.ps-min-save-period-ms (da Android 12): il tempo minimo da attendere prima di aggiornare il profilo dell'applicazione.
    • dalvik.vm.dex2oat64.enabled (da Android 11) (valore predefinito: false): Indica se utilizzare la versione a 64 bit di dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (da Android 12) (valore predefinito: 20): la percentuale minima, compresa tra 0 e 100, di nuove classi in un profilo per attivare una ricompilatura. Applicabile solo alla compilazione basata su profilo (speed-profile), in genere durante la compilazione in background. Tieni presente che oltre alla soglia percentuale è presente anche una soglia di almeno 50 nuovi corsi e che non è configurabile.
    • dalvik.vm.bgdexopt.new-methods-percent (da Android 12) (valore predefinito: 20): la percentuale minima, compresa tra 0 e 100, di nuovi metodi in un profilo per attivare una ricompilazione. Applicabile solo alla compilazione basata su profilo (speed-profile), in genere durante la compilazione in background. Tieni presente che, oltre alla soglia percentuale, è presente anche una soglia di almeno 100 nuovi metodi e che non è configurabile.
    • dalvik.vm.dex2oat-max-image-block-size (da Android 10) (valore predefinito: 524288) Dimensioni massime del blocco solido per le immagini compresse. Un'immagine di grandi dimensioni viene suddivisa in un insieme di blocchi pieni in modo che nessun blocco sia più grande delle dimensioni massime.
    • dalvik.vm.dex2oat-resolve-startup-strings (da Android 10) (valore predefinito: true) Se true, dex2oat risolve tutte le stringhe const a cui viene fatto riferimento dai metodi contrassegnati come "startup" nel profilo.
    • debug.generate-debug-info (valore predefinito: false) Indica se generare o meno informazioni di debug per il debug nativo, ad esempio informazioni di scollegamento dello stack, simboli ELF e sezioni dwarf.
    • dalvik.vm.dex2oat-minidebuginfo (da Android 9) (valore predefinito: true) Indica se generare o meno una quantità minima di informazioni di debug compresse con LZMA necessarie per stampare le backtrace.

    Opzioni del servizio ART

    Da Android 14, la compilazione AOT on-device per le app (ovvero dexopt) è gestita da ART Service. Per informazioni sulla configurazione di ART Service, consulta Configurazione di ART Service.

    Opzioni del gestore dei pacchetti

    Prima di Android 14, la compilazione AOT on-device per le app (nota anche come dexopt) è gestita dal gestore dei pacchetti. Per informazioni sulla configurazione del gestore pacchetti per dexopt, consulta Configurazione del gestore pacchetti.

    Configurazione specifica per il test A/B

    Configurazione della ROM

    A partire da Android 7.0, i dispositivi possono utilizzare due partizioni di sistema per attivare gli aggiornamenti di sistema A/B. Per risparmiare sulle dimensioni della partizione di sistema, i file preselezionati possono essere installati nella seconda partizione di sistema inutilizzata. Vengono poi copiati nella partizione dei 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 in BoardConfig.mk del dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

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

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt OTA in background

    Sui dispositivi con abilitazione A/B, le applicazioni possono essere compilate in background prima del riavvio con la nuova immagine di sistema. Consulta 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 dal profilo e risparmiare spazio di archiviazione.

    Opzioni JDWP

    La creazione di 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 attivare i thread JDWP sia per le app di debug sia per quelle non di debug, imposta persist.debug.dalvik.vm.jdwp.enabled su 1. Affinché le modifiche alla proprietà vengano applicate, è necessario riavviare il dispositivo.

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

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