Cette page explique comment configurer le runtime Android (ART) et ses options de compilation. Les sujets abordés ici incluent la configuration de la précompilation de l'image système, les options de compilation dex2oat
et la manière de compromis entre l'espace de partition système, l'espace de partition de données et les performances.
Voir ART et Dalvik et le format exécutable Dalvik pour travailler avec ART. Consultez Vérification du comportement des applications sur Android Runtime (ART) pour vous assurer que vos applications fonctionnent correctement.
Comment fonctionne l'ART
ART utilise la compilation anticipée (AOT) et, à partir d'Android 7, il utilise une combinaison hybride de compilation AOT, de compilation juste à temps (JIT) et d'interprétation, et la compilation AOT peut être guidée par profil. La combinaison de tous ces modes d'exécution est configurable et sera abordée dans cette section. À titre d'exemple, les appareils Pixel sont configurés pour fonctionner selon le flux suivant :
- Une application est initialement installée avec un fichier de métadonnées dex (
.dm
) distribué par Play Store, qui contient un profil cloud. ART AOT-compile les méthodes répertoriées dans le profil cloud. Ou, si l'application est installée sans fichier de métadonnées dex, aucune compilation AOT n'est effectuée. - Lors des premières exécutions de l'application, les méthodes qui ne sont pas compilées en AOT sont interprétées. Parmi les méthodes interprétées, celles qui sont fréquemment exécutées sont ensuite compilées en JIT. ART génère un profil local basé sur l'exécution et le combine avec le profil cloud (s'il en existe un).
- Lorsque l'appareil est inactif et en charge, un démon de compilation s'exécute pour recompiler l'application en fonction du profil combiné généré lors des premières exécutions.
- Lors des exécutions ultérieures de l'application, ART utilise les artefacts générés par le démon de compilation, qui contiennent plus de code compilé par AOT, par rapport à ceux générés lors de l'exécution des méthodes qui ne sont pas compilées par AOT. ART met à jour l'installation du profil, en fonction de l'exécution, et le profil sera ensuite récupéré par les exécutions ultérieures du démon de compilation.
ART comprend un compilateur (l'outil dex2oat
) et un runtime ( libart.so
) qui est chargé lors du démarrage. L'outil dex2oat
prend un fichier APK et génère un ou plusieurs fichiers d'artefacts de compilation que le runtime charge. Le nombre de fichiers, leurs extensions et leurs noms sont susceptibles de changer d'une version à l'autre, mais à partir de la version Android 8, ces fichiers sont générés :
-
.vdex
: contient des métadonnées supplémentaires pour accélérer la vérification, parfois avec le code DEX non compressé de l'APK. -
.odex
: contient le code compilé par AOT pour les méthodes de l'APK. -
.art (optional)
contient des représentations internes ART de certaines chaînes et classes répertoriées dans l'APK, utilisées pour accélérer le démarrage de l'application.
Options de compilation
Il existe deux catégories d’options de compilation pour ART :
- Configuration de la ROM système : quel code AOT est-il compilé lors de la création d'une image système.
- Configuration d'exécution : comment ART compile et exécute des applications sur un appareil.
Filtres du compilateur
Les filtres du compilateur sont une option essentielle d'ART pour configurer ces deux catégories. Les filtres du compilateur déterminent la manière dont ART compile le code DEX et constituent une option transmise à l'outil dex2oat
. À partir d'Android 8, il existe quatre filtres officiellement pris en charge :
-
verify
: exécutez uniquement la vérification du code DEX (pas de compilation AOT). -
quicken
: (jusqu'à Android 11) exécutez la vérification du code DEX et optimisez certaines instructions DEX pour obtenir de meilleures performances de l'interpréteur. -
speed
: exécutez la vérification du code DEX et compilez AOT toutes les méthodes. -
speed-profile
: exécutez la vérification du code DEX et les méthodes de compilation AOT répertoriées dans un fichier de profil.
Configuration de la ROM système
Les bibliothèques et applications préinstallées sont compilées par AOT lors de la création d'une image système. Ce processus est appelé dexpreopt . De tels fichiers compilés sont utilisables tant que toutes les dépendances restent inchangées, en particulier le chemin de classe de démarrage.
Remarque : Si l'appareil prend des mises à jour du module système , le chemin de classe de démarrage est très susceptible de changer lors de la prochaine mise à jour, ce qui rend tous les fichiers dexpreopt obsolètes et inutilisables.
Il existe un certain nombre d'options de construction ART disponibles pour configurer dexpreopt. La façon dont vous configurez ces options dépend de l'espace de stockage disponible pour l'image système et du nombre d'applications préinstallées. Les JAR/APK compilés dans une ROM système peuvent être divisés en quatre catégories :
- Code du chemin de classe de démarrage : compilé avec le filtre du compilateur de
speed-profile
par défaut. - Code du serveur système (voir
PRODUCT_SYSTEM_SERVER_JARS
,PRODUCT_APEX_SYSTEM_SERVER_JARS
,PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
,PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
plus loin dans ce document) :- (Android 14 et versions ultérieures) Compilé avec le filtre du compilateur
speed-profile
par défaut, ou compilé avec le filtre du compilateurspeed
si aucun profil n'est fourni. - (Android 13 et versions antérieures) Compilé avec le filtre du compilateur
speed
par défaut.
PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
(voir plus loin dans ce document). - (Android 14 et versions ultérieures) Compilé avec le filtre du compilateur
- Applications principales spécifiques au produit (voir
PRODUCT_DEXPREOPT_SPEED_APPS
plus loin dans ce document) : compilées avec le filtre du compilateurspeed
par défaut. - Toutes les autres applications : compilées avec le filtre du compilateur de
speed-profile
par défaut, ou compilées avec le filtreverify
du compilateur si aucun profil n'est fourni.Configurable via
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(voir plus loin dans ce document).
Options du fichier Make
-
WITH_DEXPREOPT
-
DONT_DEXPREOPT_PREBUILTS
(Android 5 et supérieur) -
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
(Android 9 et supérieur) -
WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
(depuis Android 8 MR1) -
LOCAL_DEX_PREOPT
-
PRODUCT_DEX_PREOPT_BOOT_FLAGS
-
PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
-
PRODUCT_DEX_PREOPT_MODULE_CONFIGS
-
PRODUCT_DEXPREOPT_SPEED_APPS
(depuis Android 8) -
PRODUCT_SYSTEM_SERVER_APPS
(depuis Android 8) -
PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD
(depuis Android 8) -
WITH_DEXPREOPT_PIC
(jusqu'à Android 7) -
WITH_DEXPREOPT_BOOT_IMG_ONLY
(jusqu'à Android 7 MR1) -
PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
- (Android 14 et versions ultérieures) S'il n'est pas spécifié, le filtre du compilateur de
speed-profile
est utilisé, ou le filtre du compilateur despeed
est utilisé si aucun profil n'est fourni. - (Android 13 et versions antérieures) S’il n’est pas spécifié, le filtre du compilateur de
speed
est utilisé. - S'il est défini sur
speed
, le filtre du compilateurspeed
est utilisé. - S'il est défini sur
speed-profile
, le filtre du compilateurspeed-profile
est utilisé, ou le filtreverify
du compilateur est utilisé si aucun profil n'est fourni. - S'il est défini sur
verify
, le filtre du compilateurverify
est utilisé. -
PRODUCT_SYSTEM_SERVER_JARS
,PRODUCT_APEX_SYSTEM_SERVER_JARS
,PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
,PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
- (Obligatoire)
PRODUCT_SYSTEM_SERVER_JARS
: liste des fichiers JAR de chemin de classe du serveur système sur la plate-forme (c'est-à-dire dans le cadre deSYSTEMSERVERCLASSPATH
). L’ajout de fichiers JAR de chemin de classe du serveur système à cette liste est requis. Si vous n’ajoutez pas les fichiers JAR de chemin de classe du serveur système à la liste, ces fichiers JAR ne seront pas chargés. - (Obligatoire)
PRODUCT_APEX_SYSTEM_SERVER_JARS
: liste des fichiers JAR de chemin de classe du serveur système fournis avec APEX (c'est-à-dire dans le cadre deSYSTEMSERVERCLASSPATH
). Le format est<apex name>:<jar name>
. L’ajout des fichiers JAR de chemin de classe du serveur système APEX à cette liste est requis. Si vous n’ajoutez pas les fichiers JAR de chemin de classe du serveur système APEX à cette liste, ces fichiers JAR ne seront pas chargés. - (Facultatif, Android 13 et versions antérieures)
PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
: liste des fichiers JAR que le serveur système charge dynamiquement à l'aide de chargeurs de classe distincts (viaSystemServiceManager.startServiceFromJar
). L'ajout de JAR de serveur système autonome à cette liste n'est pas obligatoire mais fortement recommandé car cela rend les JAR compilés et offre donc de bonnes performances d'exécution. - (obligatoire, depuis Android 13)
PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
: Liste des JAR fournis avec APEX que le serveur système charge dynamiquement à l'aide de chargeurs de classe distincts (c'est-à-dire viaSystemServiceManager.startServiceFromJar
ou déclarés comme<apex-system-service>
). Le format est<apex name>:<jar name>
. L’ajout de fichiers JAR de serveur système APEX autonomes à cette liste est requis. Si vous n'ajoutez pas de fichiers JAR de serveur système APEX autonome à cette liste, cela entraînera un échec de démarrage.
Indique si dex2oat
est invoqué sur le code DEX installé sur l'image système. Activé par défaut.
L'activation DONT_DEXPREOPT_PREBUILTS
empêche la dexpreoptation des pré-construits. Ce sont des applications qui include $(BUILD_PREBUILT)
spécifié dans leur Android.mk
. Ignorer le dexpreopt des applications prédéfinies susceptibles d'être mises à jour via Google Play permet d'économiser de l'espace dans l'image système, mais augmente le temps de premier démarrage. Notez que cette option n'a aucun effet sur les applications prédéfinies définies dans Android.bp
.
PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER
spécifie le filtre du compilateur par défaut pour les applications dexpreoptées. Ces applications sont définies dans Android.bp
ou include $(BUILD_PREBUILT)
spécifié dans leur Android.mk
. Si elle n'est pas spécifiée, la valeur par défaut est speed-profile
, ou verify
si la valeur n'est pas spécifiée et qu'aucun profil n'est fourni.
L'activation de WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
dexpreopte uniquement le chemin de classe de démarrage et les fichiers JAR du serveur système.
Dexpreopt peut également être activé ou désactivé pour une application individuelle en spécifiant l'option LOCAL_DEX_PREOPT
dans la définition du module. Cela peut être utile pour désactiver la dexpreopt des applications qui peuvent recevoir immédiatement les mises à jour de Google Play, car les mises à jour rendraient obsolète le code dxpreopt dans l'image système. Ceci est également utile pour économiser de l'espace sur les OTA de mise à niveau de version majeure, car les utilisateurs peuvent déjà disposer de versions plus récentes d'applications dans la partition de données.
LOCAL_DEX_PREOPT
prend en charge les valeurs true
ou false
pour activer ou désactiver dexpreopt, respectivement. De plus, nostripping
peut être spécifié si dexpreopt ne doit pas supprimer le fichier classes.dex
du fichier APK ou JAR. Normalement, ce fichier est supprimé car il n'est plus nécessaire après dxpreopt, mais cette dernière option est nécessaire pour permettre aux signatures APK tierces de rester valides.
Passe les options à dex2oat
pour contrôler la manière dont l'image de démarrage est compilée. Il peut être utilisé pour spécifier des listes de classes d'images personnalisées, des listes de classes compilées et des filtres de compilateur.
Passe les options à dex2oat
pour contrôler la façon dont tout ce qui est compilé, à l'exception de l'image de démarrage.
Offre la possibilité de transmettre les options dex2oat
pour un module et une configuration de produit particuliers. Il est défini dans le fichier device.mk
d'un produit par $(call add-product-dex-preopt-module-config,<modules>,<option>)
où <modules>
est une liste de noms LOCAL_MODULE
et LOCAL_PACKAGE
pour les fichiers JAR et APK , respectivement.
Liste des applications qui ont été identifiées comme étant essentielles aux produits et qu'il est souhaitable de compiler avec le filtre du compilateur speed
. Par exemple, les applications persistantes telles que SystemUI ont la possibilité d'utiliser la compilation guidée par profil uniquement au prochain redémarrage. Il peut donc être préférable que le produit ait toujours ces applications compilées en AOT.
Liste des applications chargées par le serveur système. Ces applications sont compilées par défaut avec le filtre du compilateur speed
.
S'il faut inclure une version de débogage d'ART sur l'appareil. Par défaut, ceci est activé pour les builds userdebug et eng. Le comportement peut être remplacé en définissant explicitement l'option sur true
ou false
.
Par défaut, l'appareil utilise la version sans débogage ( libart.so
). Pour basculer, définissez la propriété système persist.sys.dalvik.vm.lib.2
sur libartd.so
.
Dans Android 5.1.0 à Android 6.0.1, WITH_DEXPREOPT_PIC
peut être spécifié pour activer le code indépendant de la position (PIC). Avec cela, le code compilé de l'image n'a pas besoin d'être déplacé de /system
vers /data/dalvik-cache
, économisant ainsi de l'espace dans la partition de données. Cependant, il y a un léger impact sur l'exécution car cela désactive une optimisation qui tire parti du code dépendant de la position. En règle générale, les appareils souhaitant économiser de l'espace dans /data
doivent activer la compilation PIC.
Sous Android 7.0, la compilation PIC était activée par défaut.
Cette option a été remplacée par WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY
qui pré-opte également les JAR du serveur système.
Cette option spécifie le filtre du compilateur pour le serveur système.
Voici les listes de fichiers JAR chargés par le serveur système. Les JAR sont compilés avec le filtre du compilateur spécifié par PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
Configuration du chemin de classe de démarrage
La liste des classes préchargées est une liste de classes que Zygote initialise au démarrage. Cela évite à chaque application d'avoir à exécuter ces initialiseurs de classe séparément, ce qui leur permet de démarrer plus rapidement et de partager des pages en mémoire. Le fichier de liste des classes préchargées se trouve par défaut dans frameworks/base/config/preloaded-classes
et contient une liste adaptée à une utilisation typique du téléphone. Cela peut être différent pour d’autres appareils tels que les appareils portables et doit être réglé en conséquence. Soyez prudent lorsque vous réglez ceci ; ajouter trop de classes gaspille de la mémoire lorsque les classes inutilisées sont chargées. Ajouter trop peu de classes oblige chaque application à avoir sa propre copie, ce qui, encore une fois, gaspille de la mémoire.
Exemple d'utilisation (dans device.mk
du produit) :
PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes
Remarque : Vous devez placer cette ligne avant d'hériter de tout makefile de configuration de produit qui obtient celui par défaut de build/target/product/base.mk
.
Configuration d'exécution
Options JIT
Les options suivantes affectent les versions Android uniquement dans lesquelles le compilateur ART JIT est disponible.
-
dalvik.vm.usejit
: indique si le JIT est activé ou non. -
dalvik.vm.jitinitialsize
(64 Ko par défaut) : capacité initiale du cache de code. Le cache de code sera régulièrement GC et augmentera si nécessaire. -
dalvik.vm.jitmaxsize
(64 Mo par défaut) : la capacité maximale du cache de code. -
dalvik.vm.jitthreshold
(par défaut 10 000) : seuil que le compteur « hotness » d'une méthode doit dépasser pour que la méthode soit compilée JIT. Le compteur « hotness » est une métrique interne au runtime. Il inclut le nombre d’appels, les branchements arrière et d’autres facteurs. -
dalvik.vm.usejitprofiles
(jusqu'à Android 13) : indique si les profils JIT sont activés ou non ; cela peut être utilisé même sidalvik.vm.usejit
est faux. Notez que si cela est faux, lespeed-profile
du filtre du compilateur ne compile aucune méthode AOT et équivaut àverify
. Depuis Android 14, les profils JIT sont toujours activés et ne peuvent pas être désactivés. -
dalvik.vm.jitprithreadweight
(par défautdalvik.vm.jitthreshold
/ 20) : poids des « échantillons » JIT (voir jitthreshold) pour le thread de l'interface utilisateur de l'application. À utiliser pour accélérer la compilation des méthodes qui affectent directement l'expérience des utilisateurs lors de leur interaction avec l'application. -
dalvik.vm.jittransitionweight
(par défautdalvik.vm.jitthreshold
/ 10) : poids de l'invocation de méthode qui fait la transition entre le code de compilation et l'interpréteur. Cela permet de garantir que les méthodes impliquées sont compilées pour minimiser les transitions (qui sont coûteuses).
Options Dex2oat
Ces options affectent la compilation sur l'appareil (alias, dexopt ), et quelques-unes d'entre elles affectent également dexpreopt, alors que les options décrites dans la section Configuration de la ROM système ci-dessus n'affectent que dexpreopt.
Options pour contrôler l'utilisation des ressources :
-
dalvik.vm.image-dex2oat-threads
/dalvik.vm.image-dex2oat-cpu-set
(jusqu'à Android 11) : le nombre de threads et l'ensemble de cœurs de processeur (voir ci-dessous) à utiliser pour les images de démarrage. -
dalvik.vm.boot-dex2oat-threads
/dalvik.vm.boot-dex2oat-cpu-set
:- (jusqu'à Android 11) Le nombre de threads et l'ensemble des cœurs de processeur (voir ci-dessous) à utiliser pendant le démarrage pour tout autre chose que les images de démarrage.
- (depuis Android 12) Le nombre de threads et l'ensemble des cœurs de processeur (voir ci-dessous) à utiliser pendant le démarrage pour tout, y compris les images de démarrage.
- Concrètement, depuis Android 14, cela correspond à la classe de priorité
PRIORITY_BOOT
dans ART Service.
- Concrètement, depuis Android 14, cela correspond à la classe de priorité
-
dalvik.vm.restore-dex2oat-threads
/dalvik.vm.restore-dex2oat-cpu-set
:- (depuis Android 11, jusqu'à Android 13) Le nombre de threads et l'ensemble de cœurs de processeur (voir ci-dessous) à utiliser pour la restauration à partir d'une sauvegarde cloud.
- (depuis Android 14) Le nombre de threads et l'ensemble des cœurs de processeur (voir ci-dessous) à utiliser pour tout ce qui est plus sensible à la latence que la normale, y compris la restauration à partir d'une sauvegarde cloud.
- Plus précisément, cela correspond à la classe de priorité
PRIORITY_INTERACTIVE_FAST
dans le service ART.
- Plus précisément, cela correspond à la classe de priorité
-
dalvik.vm.background-dex2oat-threads
/dalvik.vm.background-dex2oat-cpu-set
(depuis Android 14) : Le nombre de threads et l'ensemble des cœurs CPU (voir ci-dessous) à utiliser en arrière-plan.- Plus précisément, cela correspond à la classe de priorité
PRIORITY_BACKGROUND
dans le service ART.
- Plus précisément, cela correspond à la classe de priorité
-
dalvik.vm.dex2oat-threads
/dalvik.vm.dex2oat-cpu-set
: Le nombre de threads et l'ensemble de cœurs CPU à utiliser pour tout le reste.
Un ensemble de cœurs de processeur doit être spécifié sous la forme d’une liste d’identifiants de processeur séparés par des virgules. Par exemple, pour exécuter sur dex2oat sur les cœurs de processeur 0 à 3, définissez :
dalvik.vm.dex2oat-cpu-set=0,1,2,3
Lors de la définition des propriétés d'affinité du processeur, nous vous recommandons de faire correspondre la propriété correspondante pour le nombre de threads dex2oat afin qu'elle corresponde au nombre de processeurs sélectionnés afin d'éviter des conflits inutiles de mémoire et d'E/S :
dalvik.vm.dex2oat-cpu-set=0,1,2,3 dalvik.vm.dex2oat-threads=4
En plus des propriétés système ci-dessus, vous pouvez également utiliser des profils de tâches pour contrôler l'utilisation des ressources de dex2oat (voir Cgroup Abstraction Layer ).
Les profils de tâches pris en charge sont :
-
Dex2OatBackground
(depuis Android 14) (hérite par défautDex2OatBootComplete
) : Contrôle les ressources à utiliser en arrière-plan.- Plus précisément, cela correspond à la classe de priorité
PRIORITY_BACKGROUND
dans le service ART.
- Plus précisément, cela correspond à la classe de priorité
-
Dex2OatBootComplete
:- (jusqu'à Android 13) Contrôle la ressource à utiliser pour tout après le démarrage.
- (depuis Android 14) Contrôle la ressource à utiliser pour tout après le démarrage et non en arrière-plan.
- Plus précisément, cela correspond aux classes de priorité
PRIORITY_INTERACTIVE_FAST
etPRIORITY_INTERACTIVE
dans le service ART.
- Plus précisément, cela correspond aux classes de priorité
Lorsque les propriétés système et les profils de tâches sont spécifiés, les deux prennent effet.
Options pour contrôler la taille du tas :
-
dalvik.vm.image-dex2oat-Xms
: taille de tas initiale pour les images de démarrage. -
dalvik.vm.image-dex2oat-Xmx
: taille maximale du tas pour les images de démarrage. -
dalvik.vm.dex2oat-Xms
: taille initiale du tas pour tout le reste. -
dalvik.vm.dex2oat-Xmx
: Taille maximale du tas pour tout le reste.
Les options qui contrôlent la taille initiale et maximale du tas pour dex2oat
ne doivent pas être réduites car elles pourraient limiter les applications pouvant être compilées.
Options pour contrôler le filtre du compilateur :
-
dalvik.vm.image-dex2oat-filter
(jusqu'à Android 11) : le filtre du compilateur pour les images de démarrage. Depuis Android 12, le filtre du compilateur pour les images de démarrage est toujoursspeed-profile
et ne peut pas être modifié. -
dalvik.vm.systemservercompilerfilter
(depuis Android 13) : le filtre du compilateur pour le serveur système. VoirPRODUCT_SYSTEM_SERVER_COMPILER_FILTER
. -
dalvik.vm.systemuicompilerfilter
(depuis Android 13) : le filtre du compilateur pour le package System UI. -
dalvik.vm.dex2oat-filter
(jusqu'à Android 6) : le filtre du compilateur pour tout le reste. -
pm.dexopt.<reason>
(depuis Android 7) : Le filtre du compilateur pour tout le reste. Voir Configuration du service ART pour Android 14 et versions ultérieures, ou Configuration du gestionnaire de packages pour Android 13 et versions ultérieures.
Autres options pour contrôler la compilation de tout autre chose que les images de démarrage :
-
dalvik.vm.dex2oat-very-large
(depuis Android 7.1) : taille totale minimale du fichier dex en octets pour désactiver la compilation AOT. -
dalvik.vm.dex2oat-swap
(depuis Android 7.1) (par défaut : true) : permet d'utiliser un fichier d'échange pour dex2oat. Cela peut aider à éviter les pannes de mémoire insuffisante. Notez que même si cette option est activée, dex2oat n'utilisera un fichier d'échange que sous certaines conditions, par exemple lorsque le nombre de fichiers dex est important, et les conditions sont susceptibles de changer. -
dalvik.vm.ps-min-first-save-ms
(depuis Android 12) : Le temps minimum d'attente avant que le runtime génère un profil de l'application, au premier lancement de l'application. -
dalvik.vm.ps-min-save-period-ms
(depuis Android 12) : Le temps minimum d'attente avant de mettre à jour le profil de l'application. -
dalvik.vm.dex2oat64.enabled
(depuis Android 11) (par défaut : false) : s'il faut utiliser la version 64 bits de dex2oat. -
dalvik.vm.bgdexopt.new-classes-percent
(depuis Android 12) (par défaut : 20) : Le pourcentage minimum, entre 0 et 100, de nouvelles classes dans un profil pour déclencher une recompilation. Applicable uniquement à la compilation guidée par profil (speed-profile
), généralement pendant la dexopt en arrière-plan. Notez qu'il existe également un seuil d'au moins 50 nouvelles classes en plus du seuil en pourcentage, et qu'il n'est pas configurable. -
dalvik.vm.bgdexopt.new-methods-percent
(depuis Android 12) (par défaut : 20) : Le pourcentage minimum, entre 0 et 100, de nouvelles méthodes dans un profil pour déclencher une recompilation. Applicable uniquement à la compilation guidée par profil (speed-profile
), généralement pendant la dexopt en arrière-plan. Notez qu’il existe également un seuil d’au moins 100 nouvelles méthodes en plus du seuil de pourcentage, et qu’il n’est pas configurable. -
dalvik.vm.dex2oat-max-image-block-size
(depuis Android 10) (par défaut : 524288) Taille de bloc solide maximale pour les images compressées. Une grande image est divisée en un ensemble de blocs solides de telle sorte qu'aucun bloc ne soit plus grand que la taille maximale. -
dalvik.vm.dex2oat-resolve-startup-strings
(depuis Android 10) (par défaut : vrai) Si vrai, dex2oat résout toutes les chaînes const référencées à partir des méthodes marquées comme « démarrage » dans le profil. -
debug.generate-debug-info
(par défaut : false) Indique s'il faut ou non générer des informations de débogage pour le débogage natif, telles que les informations de déroulement de la pile, les symboles ELF et les sections naines. -
dalvik.vm.dex2oat-minidebuginfo
(depuis Android 9) (par défaut : true) Indique s'il faut ou non générer une quantité minimale d'informations de débogage compressées LZMA nécessaires pour imprimer les traces arrière.
Options de services ART
Depuis Android 14, la compilation AOT sur l'appareil pour les applications (alias dexopt) est gérée par ART Service. Pour plus d'informations sur la configuration du service ART, voir Configuration du service ART .Options du gestionnaire de packages
Avant Android 14, la compilation AOT sur l'appareil pour les applications (alias dexopt) était gérée par le gestionnaire de packages. Pour plus d'informations sur la configuration du gestionnaire de packages pour dexopt, consultez Configuration du gestionnaire de packages .Configuration spécifique A/B
Configuration de la ROM
À partir d'Android 7.0, les appareils peuvent utiliser deux partitions système pour activer les mises à jour du système A/B . Pour économiser sur la taille de la partition système, les fichiers préoptés peuvent être installés dans la deuxième partition système inutilisée. Ils sont ensuite copiés sur la partition de données au premier démarrage.
Exemple d'utilisation (dans device-common.mk
) :
PRODUCT_PACKAGES += \ cppreopts.sh PRODUCT_PROPERTY_OVERRIDES += \ ro.cp_system_other_odex=1
Et dans BoardConfig.mk
de l'appareil :
BOARD_USES_SYSTEM_OTHER_ODEX := true
Notez que le code du chemin de classe de démarrage, le code du serveur système et les applications principales spécifiques au produit sont toujours compilés sur la partition système. Par défaut, toutes les autres applications sont compilées sur la deuxième partition système inutilisée. Cela peut être contrôlé avec le SYSTEM_OTHER_ODEX_FILTER
, qui a une valeur par défaut de :
SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%
Contexte OTA dexopt
Sur les appareils compatibles A/B, les applications peuvent être compilées en arrière-plan avant le redémarrage avec la nouvelle image système. Consultez Compilation d’application en arrière-plan pour inclure éventuellement le script de compilation et les binaires dans l’image système. Le filtre de compilation utilisé pour cette compilation est contrôlé avec :
pm.dexopt.ab-ota=speed-profile
Nous vous recommandons d'utiliser speed-profile
pour profiter de la compilation guidée par profil et économiser sur le stockage.
Options JDWP
La création de threads Java Debug Wire Protocol (JDWP) dans les versions userdebug est contrôlée via la propriété système persist.debug.dalvik.vm.jdwp.enabled
. Par défaut, cette propriété n'est pas définie et les threads JDWP sont créés uniquement pour les applications déboguables. Pour activer les threads JDWP pour les applications déboguables et non déboguables, définissez persist.debug.dalvik.vm.jdwp.enabled
sur 1
. L'appareil doit être redémarré pour que les modifications apportées à la propriété prennent effet.
Pour déboguer une application non déboguable sur une version userdebug, activez JDWP en exécutant la commande suivante :
Pour les appareils exécutant Android 13 et versions antérieures, le runtime crée des threads JDWP pour les applications déboguables et non déboguables sur les versions userdebug. Cela signifie qu'il est possible d'attacher un débogueur ou de profiler n'importe quelle application sur les versions userdebug.adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
adb reboot