Configurer ART

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 :

  1. 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.
  2. 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).
  3. 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.
  4. 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 :

  1. Configuration de la ROM système : quel code AOT est-il compilé lors de la création d'une image système.
  2. 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 compilateur speed si aucun profil n'est fourni.
    • (Android 13 et versions antérieures) Compilé avec le filtre du compilateur speed par défaut.
    Configurable via PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (voir plus loin dans ce document).
  • Applications principales spécifiques au produit (voir PRODUCT_DEXPREOPT_SPEED_APPS plus loin dans ce document) : compilées avec le filtre du compilateur speed 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 filtre verify 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
  • Indique si dex2oat est invoqué sur le code DEX installé sur l'image système. Activé par défaut.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 et supérieur)
  • 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 (Android 9 et supérieur)
  • 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.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (depuis Android 8 MR1)
  • 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.

  • LOCAL_DEX_PREOPT
  • 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.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS
  • 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.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS
  • Passe les options à dex2oat pour contrôler la façon dont tout ce qui est compilé, à l'exception de l'image de démarrage.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS
  • 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>)<modules> est une liste de noms LOCAL_MODULE et LOCAL_PACKAGE pour les fichiers JAR et APK , respectivement.

  • PRODUCT_DEXPREOPT_SPEED_APPS (depuis Android 8)
  • 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.

  • PRODUCT_SYSTEM_SERVER_APPS (depuis Android 8)
  • Liste des applications chargées par le serveur système. Ces applications sont compilées par défaut avec le filtre du compilateur speed .

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (depuis Android 8)
  • 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 .

  • WITH_DEXPREOPT_PIC (jusqu'à Android 7)
  • 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.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (jusqu'à Android 7 MR1)
  • 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.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
  • Cette option spécifie le filtre du compilateur pour le serveur système.

    • (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 de speed 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 compilateur speed est utilisé.
    • S'il est défini sur speed-profile , le filtre du compilateur speed-profile est utilisé, ou le filtre verify du compilateur est utilisé si aucun profil n'est fourni.
    • S'il est défini sur verify , le filtre du compilateur verify est utilisé.

  • PRODUCT_SYSTEM_SERVER_JARS , PRODUCT_APEX_SYSTEM_SERVER_JARS , PRODUCT_STANDALONE_SYSTEM_SERVER_JARS , PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
  • 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

    • (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 de SYSTEMSERVERCLASSPATH ). 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 de SYSTEMSERVERCLASSPATH ). 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 (via SystemServiceManager.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 via SystemServiceManager.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.

    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 si dalvik.vm.usejit est faux. Notez que si cela est faux, le speed-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éfaut dalvik.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éfaut dalvik.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.
    • 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.
    • 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.
    • 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éfaut Dex2OatBootComplete ) : 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.
    • 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 et PRIORITY_INTERACTIVE dans le service ART.

    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 toujours speed-profile et ne peut pas être modifié.
    • dalvik.vm.systemservercompilerfilter (depuis Android 13) : le filtre du compilateur pour le serveur système. Voir PRODUCT_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 :

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
      adb reboot
      
    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.