Configura ART

Questa pagina illustra come configurare Android Runtime (ART) e le relative opzioni di compilazione. Argomenti trattati includono la configurazione della precompilazione dell'immagine di sistema, dex2oat le opzioni di compilazione e come compromesso lo spazio della partizione di sistema, le prestazioni dei dispositivi.

Vedi ART e Dalvik e il formato eseguibile Dalvik per lavorare con ART. Consulta la sezione Verifica Comportamento delle app in Android Runtime (ART) per garantire il funzionamento delle app correttamente.

Come funziona ART

ART utilizza una compilazione di compilazione in anticipo (AOT) e, a partire da Android 7, utilizza una combinazione ibrida di compilation AOT, just-in-time (JIT) e interpretazione, mentre la compilazione AOT può essere guidata dal profilo. La combinazione di tutte queste modalità di esecuzione configurabili e verranno trattati in questa sezione. Ad esempio, i dispositivi Pixel sono configurati possono funzionare nel seguente flusso:

  1. Un'applicazione viene inizialmente installata con un file dex metadata (.dm) distribuito tramite Play Store, che contiene un profilo cloud. ART AOT compila i metodi elencati nel cloud profilo. Oppure, se l'applicazione è installata senza un file di metadati dex, non viene in esecuzione.
  2. Le prime volte che l'applicazione viene eseguita, vengono interpretati i metodi non compilati con AOT. Tra i metodi interpretati, quelli che vengono eseguiti di frequente vengono poi compilati tramite JIT. ARTE genera un profilo locale basato sull'esecuzione e lo combina con il profilo cloud (se esiste già).
  3. Quando il dispositivo è inattivo e in carica, viene eseguito un daemon 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 daemon, che contengono più codice compilato AOT rispetto a quelli generati durante I metodi che non sono compilati da AOT vengono comunque interpretati o compilati tramite JIT. ART aggiorna il profilo dell'installazione, in base all'esecuzione; il profilo verrà quindi selezionato dalle esecuzioni successive il daemon di compilazione.

ART comprende un compilatore (lo strumento dex2oat) e un runtime (libart.so) che viene caricato durante l'avvio. La Lo strumento dex2oat prende un file APK e genera uno o più gli artefatti di compilazione caricati dal runtime. Il numero di file, il loro le estensioni e i nomi sono soggetti a modifica nelle varie release, ma a partire dal Nella versione Android 8 vengono generati i seguenti file:

  • .vdex: contiene alcuni metadati aggiuntivi per velocizzare la verifica, a volte insieme con il codice DEX non compresso dell'APK.
  • .odex: contiene il codice compilato AOT per i metodi in .
  • .art (optional) contiene ART interno di alcune stringhe e classi elencate nell'APK, usate per velocizzare 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 un'immagine di sistema.
  2. Configurazione del runtime: in che modo ART compila ed esegue le app su un dispositivo.

Filtri del compilatore

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

  • verify: esegui solo la verifica del codice DEX (non la compilazione AOT).
  • quicken: (fino ad Android 11) esegui il codice DEX verifica e ottimizzare alcune istruzioni DEX per migliorare le prestazioni degli interpreti.
  • speed: esegui la verifica del codice DEX e la compilazione AOT di tutti i metodi.
  • speed-profile: esegui la verifica del codice DEX e i metodi di compilazione AOT elencate in un file di profilo.

Configurazione della ROM di sistema

Le app e le librerie preinstallate vengono compilate AOT durante la creazione di un'immagine di sistema. Questo processo è chiamato dexpreopt. Questi file compilati possono essere utilizzati purché tutte le dipendenze rimangono invariati, in particolare il classpath di avvio.

Nota: se il dispositivo impiega gli aggiornamenti al modulo di sistema, quindi il classpath di avvio è molto che potrebbero cambiare nel prossimo aggiornamento, il che rende tutti i file dexpreopt inattivi e inutilizzabili.

Sono disponibili diverse opzioni di build ART per la configurazione di Dexpreopt. Come configurare dipendono dallo spazio di archiviazione disponibile per l'immagine di sistema e dal numero applicazioni preinstallate. I JAR/APK compilati in una ROM di sistema possono essere suddivisi in quattro categorie:

  • Codice classpath di avvio: compilato con il filtro del compilatore speed-profile mediante predefinito.
  • 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 speed-profile filtro del compilatore per impostazione predefinita oppure compilato con il filtro del compilatore speed se un profilo non fornito.
    • (Android 13 e versioni precedenti) Compilato con il speed il filtro del compilatore per impostazione predefinita.
    di Gemini Advanced. Configurabile tramite PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (vedi più avanti in non web).
  • App principali specifiche del prodotto (vedi PRODUCT_DEXPREOPT_SPEED_APPS più avanti in questo document): compilata con il filtro di compilazione speed per impostazione predefinita.
  • Tutte le altre app: compilate con il filtro del compilatore speed-profile per impostazione predefinita, oppure compilate con il filtro di compilazione verify se non viene fornito un profilo.

    Configurabile tramite PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (vedi più avanti in non web).

Opzioni Makefile

  • WITH_DEXPREOPT

    • Indica se dex2oat viene richiamato nel codice DEX installato nell'immagine di sistema. Attivo per impostazione predefinita.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 e versioni successive)

    • L'attivazione di DONT_DEXPREOPT_PREBUILTS impedisce che i valori predefiniti sbalorditivi. Queste sono le app con include $(BUILD_PREBUILT) specificato in Android.mk. Ignorata eliminazione di app predefinite che probabilmente verranno aggiornate tramite Google Play consente di risparmiare spazio nell'immagine di sistema, ma va ad aggiungersi al primo 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 superiori)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER specifica il filtro del compilatore predefinito per le applicazioni dexpreopted. Queste app sono definite in Android.bp o hanno include $(BUILD_PREBUILT) specificato in 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 consente di ignorare solo boot classpath e jar del server di sistema.

  • LOCAL_DEX_PREOPT

    • La funzionalità Dexpreopt può essere attivata o disattivata anche a livello di singola app specificando l'opzione LOCAL_DEX_PREOPT nella definizione del modulo. Questa opzione può essere utile per disattivare le specifiche di app che potrebbero ricevere aggiornamenti di Google Play poiché gli aggiornamenti renderebbero la dexpreopted codice nell'immagine di sistema obsoleto. Ciò è utile anche per risparmiare spazio sui principali OTA con upgrade della versione perché gli utenti potrebbero già avere versioni più recenti delle app nel partizione dati.

    LOCAL_DEX_PREOPT supporta i valori true o false per attivare o disattivare dexpreopt, rispettivamente. Inoltre, nostripping può deve essere specificato se dexpreopt non deve rimuovere classes.dex del file APK o JAR. Di solito questo file viene rimosso perché non è necessario dopo la pianificazione, ma quest'ultima opzione è necessaria consentire la validità delle firme degli APK di terze parti.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Trasmette opzioni a dex2oat per controllare la modalità di visualizzazione dell'immagine di avvio viene compilato. Può essere usato per specificare elenchi di classi di immagini personalizzate, di corsi e filtri del compilatore.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Trasmette opzioni a dex2oat per controllare come tutto tranne il viene compilata l'immagine di avvio.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Consente di trasmettere le opzioni dex2oat per una determinata offerta del modulo e del prodotto. È impostato nel set di dati di un prodotto File device.mk di $(call add-product-dex-preopt-module-config,<modules>,<option>) dove <modules> è un elenco di LOCAL_MODULE e LOCAL_PACKAGE nomi per i file JAR e APK, rispettivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (da Android 8)

    • Elenco di app identificate come principali dei prodotti e che è preferibile compilare con il filtro del compilatore speed. Per Ad esempio, le app permanenti come SystemUI hanno la possibilità di usare compilation guidata dal profilo solo al prossimo riavvio, quindi potrebbe essere più adatta prodotto in modo che queste app siano sempre compilate 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, abilitato per userdebug ed eng build. Il comportamento può essere sostituito impostando l'opzione su true o false.

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

  • WITH_DEXPREOPT_PIC (fino ad Android 7)

    • Nelle versioni Android 5.1.0 e Android 6.0.1, WITH_DEXPREOPT_PIC può per abilitare il codice indipendente dalla posizione (PIC). Con questo, abbiamo compilato il codice dell'immagine non deve essere riposizionato /system in /data/dalvik-cache, risparmiando spazio nella partizione dati. Tuttavia, vi è un leggero impatto sul runtime perché disabilita un'ottimizzazione che sfrutta di codice dipendente dalla posizione. In genere, i dispositivi che vogliono risparmiare spazio su /data abilitare 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 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 specificati, i valori speed-profile viene usato il filtro del compilatore oppure il filtro del compilatore speed se non è presente fornito.
    • (Android 13 e versioni precedenti) Se non specificato, il compilatore speed .
    • Se impostato su speed, viene utilizzato il filtro del compilatore speed.
    • Se impostato su speed-profile, viene usato 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 elenchi di JAR caricati dal server di sistema. I JAR vengono compilati con filtro del compilatore specificato da PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obbligatorio) PRODUCT_SYSTEM_SERVER_JARS: elenco dei JAR del percorso di classe del server di sistema su la piattaforma (ovvero, come parte di SYSTEMSERVERCLASSPATH). Aggiunta del server di sistema in corso... JAR classpath in questo elenco è obbligatorio. Impossibile aggiungere JAR classpath del server di sistema all'elenco comporta il mancato caricamento di questi JAR.
    • (Obbligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS: elenco dei JAR del percorso di classe del server di sistema pubblicati con APEX (ovvero, come parte di SYSTEMSERVERCLASSPATH). Il formato è <apex name>:<jar name>. Aggiunta di JAR classpath del server di sistema APEX a questo elenco è obbligatorio. Se non aggiungi JAR di classpath del server di sistema APEX a questo elenco, per i JAR.
    • (Facoltativo, Android 13 e versioni precedenti) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: elenco di JAR caricati dal server di sistema in modo dinamico utilizzando classloader separati (tramite SystemServiceManager.startServiceFromJar). L'aggiunta di JAR di server di sistema autonomi a questo elenco non è obbligatorio ma vivamente consigliato perché i JAR vengono compilati e pertanto hanno buone prestazioni di runtime.
    • (obbligatorio, a partire da Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: elenco di JAR distribuiti con APEX che il server di sistema carica in modo dinamico utilizzando classloader separati (che è, tramite SystemServiceManager.startServiceFromJar o dichiarato come <apex-system-service>). Il formato è <apex name>:<jar name>. L'aggiunta di JAR di server di sistema APEX autonomi a questo elenco è obbligatorio. Se non aggiungi JAR del server di sistema APEX standalone a questo elenco, durante un errore di avvio.

    Configurazione classpath di avvio

    L'elenco di corsi precaricati è un elenco di classi su cui Zygote inizializza avvio automatico. In questo modo ogni app non deve eseguire questi inizializzatori di classe separatamente, consentendo un avvio più rapido e la condivisione delle pagine in memoria. La il file con l'elenco dei corsi precaricato si trova nella pagina frameworks/base/config/preloaded-classes per impostazione predefinita e contiene un elenco ottimizzato per il normale utilizzo dello smartphone. Questo potrebbe essere diverso per altri dispositivi come gli indossabili e deve essere sintonizzato di conseguenza. Fai attenzione durante la regolazione: aggiungere troppi sprechi di classi quando vengono caricate le classi inutilizzate. L'aggiunta di un numero troppo basso di classi obbliga ogni app a avere una propria copia, il che, ancora una volta, spreca memoria.

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

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

    Nota: devi inserire questa riga prima ereditando tutti i makefile di configurazione del prodotto che ricevono quello predefinito build/target/product/base.mk.

    Configurazione di runtime

    Opzioni JIT

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

    • dalvik.vm.usejit: se JIT è abilitato o meno.
    • dalvik.vm.jitinitialsize (valore predefinito: 64K): la capacità iniziale dalla cache del codice. La cache del codice viene eseguita regolarmente in GC e aumenta se necessario.
    • dalvik.vm.jitmaxsize (valore predefinito 64 MB): la capacità massima della cache del codice.
    • dalvik.vm.jitthreshold (valore predefinito 10000): La soglia che definisce il "hotness" di un metodo deve passare per ordinare per il metodo da compilare con JIT. Le caratteristiche principali è una metrica interna al runtime. Include il numero di chiamate, i rami a ritroso e altro fattori.
    • dalvik.vm.usejitprofiles (fino ad Android 13): se o non siano abilitati profili JIT; può essere utilizzato anche se dalvik.vm.usejit è falso. Tieni presente che se questo valore è falso, il filtro del compilatore speed-profile non compilano un metodo AOT ed è equivalente a verify. Dal giorno Android 14, i profili JIT sono sempre attivi e non possono essere disattivati.
    • dalvik.vm.jitprithreadweight (per impostazione predefinita dalvik.vm.jitthreshold / 20). La ponderazione degli "esempi" di JIT. (vedi jitthreshold) per il thread dell'interfaccia utente dell'applicazione. Per velocizzare la compilazione di metodi che incidono direttamente sull'esperienza degli utenti quando interagiscono con dell'app.
    • dalvik.vm.jittransitionweight (per impostazione predefinita dalvik.vm.jitthreshold / 10): Il peso del metodo chiamata che effettua la transizione tra il codice di compilazione e l'interprete. Ciò consente di assicurarsi che i metodi coinvolti siano compilati per ridurre al minimo le transizioni (ovvero costoso).

    Opzioni di Dex2oat

    Queste opzioni influiscono sulla compilazione sul dispositivo (ovvero dexopt) e alcune influiscono anche dexpreopt, mentre le opzioni discusse nella sezione Configurazione della ROM di sistema sopra riportata solo 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 sotto) da utilizzare durante il tempo di avvio per tutte le operazioni diverse dalle immagini di avvio.
      • (da Android 12) Il numero di thread e l'insieme di core della CPU (vedi sotto) da utilizzare durante l'avvio per tutto, incluse le immagini di avvio.
        • Nello specifico, a partire da Android 14, corrisponde classe di priorità PRIORITY_BOOT nel servizio ART.
    • 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 di seguito) da utilizzare per il ripristino dal cloud backup.
      • (da Android 14) Il numero di thread e l'insieme di core della CPU (vedi sotto) da usare per tutto ciò che è più sensibile alla latenza del normale, tra cui il ripristino da backup sul cloud.
        • Nello specifico, 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 l'insieme di core della CPU (vedi di seguito) da utilizzare in background.
      • Nello specifico, corrisponde alla classe di priorità PRIORITY_BACKGROUND in ART Service.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Il numero di thread e il set di core della CPU da utilizzare per tutto il resto.

    Un insieme di core della CPU deve essere specificato come elenco separato da virgole di ID CPU. 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 creare una corrispondenza con la proprietà corrispondente per il numero di thread dex2oat in base al numero di CPU selezionate per evitare memoria e I/O non necessari contesa: 

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

    Oltre alle proprietà di sistema indicate sopra, puoi utilizzare i profili delle attività anche per controllare le utilizzo delle risorse di dex2oat (vedi strato 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 in ART Service.
    • Dex2OatBootComplete:
      • (fino ad Android 13) Consente di controllare la risorsa da utilizzare per tutto dopo l'avvio.
      • (da Android 14) Consente di controllare la risorsa da utilizzare per tutto dopo l'avvio, non in background.
        • Nello specifico, corrisponde alla classe di priorità PRIORITY_INTERACTIVE_FAST e PRIORITY_INTERACTIVE in ART assistenza.

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

    Opzioni per controllare le dimensioni dello heap:

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

    Le opzioni che controllano la dimensione iniziale e massima dell'heap per dex2oat non deve essere ridotto perché potrebbe limitare ciò applicazioni 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, lo strumento di compilazione il filtro 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 successive oppure Configurazione del gestore di pacchetti per Android 13 e versioni precedenti.

    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 uno scambio file per dex2oat. Questo può aiutare a evitare arresti anomali per esaurimento della memoria. Tieni presente che anche se questa opzione è attiva, dex2oat utilizzerà un file di scambio solo in determinate condizioni, ad esempio quando il numero di file dex è grande e le condizioni sono soggette a modifica.
    • dalvik.vm.ps-min-first-save-ms (da Android 12): tempo minimo di attesa prima che il runtime generi un profilo dell'applicazione, la prima volta viene avviata l'applicazione.
    • dalvik.vm.ps-min-save-period-ms (da Android 12): di tempo minimo di attesa 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 ricompilazione. Applicabile solo alla compilazione guidata dal profilo (speed-profile), di solito durante dexopt sullo sfondo. Tieni presente che esiste anche una soglia di almeno 50 nuove classi oltre a la soglia percentuale e 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 guidata dal profilo (speed-profile), di solito durante dexopt sullo sfondo. Tieni presente che esiste anche una soglia di almeno 100 nuovi metodi, oltre a alla soglia percentuale e non è configurabile.
    • dalvik.vm.dex2oat-max-image-block-size (da Android 10) (valore predefinito: 524288) Dimensione massima del blocco solido per le immagini compresse. Un'immagine di grandi dimensioni viene suddivisa in un insieme di blocchi in modo che nessun blocco sia più grande della dimensione massima.
    • dalvik.vm.dex2oat-resolve-startup-strings (da Android 10) (valore predefinito: true) Se true, dex2oat risolve tutte le const-string a cui viene fatto riferimento dai metodi contrassegnati come "avvio" nel profilo.
    • debug.generate-debug-info (valore predefinito: false) Indica se generare o meno le informazioni di debug per il debug nativo, ad esempio il rilascio dello stack informazioni, simboli ELF e sezioni nane.
    • dalvik.vm.dex2oat-minidebuginfo (da Android 9) (predefinito: vero) Indica se generare o meno la quantità minima di informazioni di debug compresse con LZMA necessarie per per la stampa delle tracce arretrate.

    Opzioni ART Service

    Da Android 14, la compilazione AOT sul dispositivo per le app (ovvero dexopt) è gestiti da ART Service. Per informazioni sulla configurazione di ART Service, consulta Configurazione di ART Service.

    Opzioni del gestore di pacchetti

    Prima di Android 14, la compilazione AOT sul dispositivo per le app (ovvero dexopt) gestite dal gestore di pacchetti. Per informazioni sulla configurazione del gestore di pacchetti per dexopt, consulta la sezione Configurazione del gestore di pacchetti.

    Configurazione A/B specifica

    Configurazione ROM

    A partire da Android 7.0, i dispositivi potrebbero utilizzare due partizioni di sistema per attivare Aggiornamenti di sistema A/B. Per risparmiare sulla dimensione della partizione di sistema, i file preoptati possono essere installati la seconda partizione di sistema inutilizzata. 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 in BoardConfig.mk del dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Tieni presente che il codice classpath di avvio, il codice del server di sistema e il core specifico del prodotto le app vengono sempre compilate nella partizione di sistema. Per impostazione predefinita, tutti gli altri vengono compilate nella seconda partizione di sistema inutilizzata. Può essere controllato con SYSTEM_OTHER_ODEX_FILTER, che ha un valore valore predefinito di:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt OTA in background

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

    pm.dexopt.ab-ota=speed-profile

    Ti consigliamo di utilizzare speed-profile per usufruire della procedura guidata dal profilo e risparmiare spazio di archiviazione.

    Opzioni JDWP

    La creazione di thread JDWP (Java Debug Wire Protocol) nelle build userdebug viene controllata tramite proprietà di sistema persist.debug.dalvik.vm.jdwp.enabled. Per impostazione predefinita, questa proprietà non è impostato e i thread JDWP vengono creati solo per le app di cui è possibile eseguire il debug. Per abilitare i thread JDWP per entrambi app di cui è possibile eseguire il debug e non di debug, imposta persist.debug.dalvik.vm.jdwp.enabled a 1. Affinché le modifiche alla proprietà abbiano effetto, è necessario riavviare il dispositivo.

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

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