Configurer ART

Cette page explique comment configurer Android Runtime (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 façon de faire des compromis entre l'espace de partition système, l'espace de partition de données et les performances.

Pour travailler avec ART, consultez ART et Dalvik et le format exécutable Dalvik. Consultez Vérifier le comportement des applications dans l'environnement d'exécution Android Runtime (ART) pour vous assurer que vos applications fonctionnent correctement.

Fonctionnement de l'ART

ART utilise la compilation anticipée (AOT). À partir d'Android 7, il utilise une combinaison hybride de compilation AOT, de compilation juste à temps (JIT) et d'interprétation. La compilation AOT peut être guidée par le profil. La combinaison de tous ces modes d'exécution est configurable et sera abordée dans cette section. Par 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 le Play Store, qui contient un profil cloud. ART compile les méthodes listées dans le profil cloud de manière anticipée. 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 AOT sont interprétées. Parmi les méthodes interprétées, celles qui sont fréquemment exécutées sont ensuite compilées par JIT. ART génère un profil local en fonction de l'exécution et le combine au profil cloud (le cas échéant).
  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 daemon de compilation, qui contiennent plus de code compilé AOT que ceux générés lors de la compilation. Les méthodes qui ne sont pas compilées AOT sont toujours interprétées ou compilées JIT. ART met à jour l'installation du profil en fonction de l'exécution, et le profil est ensuite récupéré par les exécutions ultérieures du daemon de compilation.

ART comprend un compilateur (l'outil dex2oat) et un environnement d'exécution (libart.so) chargé au démarrage. L'outil dex2oat prend un fichier APK et génère un ou plusieurs fichiers d'artefacts de compilation que l'environnement d'exécution charge. Le nombre de fichiers, leurs extensions et leurs noms peuvent changer d'une version à l'autre, mais à partir de la version 8 d'Android, les fichiers suivants sont générés:

  • .vdex: contient des métadonnées supplémentaires pour accélérer la validation, parfois avec le code DEX non compressé de l'APK.
  • .odex: contient du code compilé AOT pour les méthodes de l'APK.
  • .art (optional) contient des représentations internes ART de certaines chaînes et classes listé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: code compilé AOT lors de la création d'une image système.
  2. Configuration d'exécution: façon dont ART compile et exécute des applications sur un appareil.

Filtres du compilateur

L'une des options principales d'ART pour configurer ces deux catégories est les filtres de compilation. Les filtres de compilateur déterminent la façon dont ART compile le code DEX. Il s'agit d'une option transmise à l'outil dex2oat. À partir d'Android 8, quatre filtres sont officiellement pris en charge:

  • verify: n'exécute que la validation du code DEX (pas de compilation AOT).
  • quicken: (Android 11 ou version antérieure) exécute la vérification du code DEX et optimise certaines instructions DEX pour améliorer les performances de l'interprète.
  • speed: exécute la vérification du code DEX et compile toutes les méthodes avec AOT. N'optimise pas le chargement de classe pour aucune classe.
  • speed-profile: exécute la vérification du code DEX, compile les méthodes listées dans le profil avec AOT et optimise les chargements de classe pour les classes du profil.

Configuration de la ROM système

Les bibliothèques et applications préinstallées sont compilées AOT lors de la création d'une image système. Ce processus est appelé dexpreopt. Ces fichiers compilés sont utilisables tant que toutes les dépendances restent inchangées, en particulier le chemin d'accès au classpath de démarrage.

Remarque:Si l'appareil reçoit des mises à jour du module système, le chemin d'accès au boot est très susceptible de changer lors de la prochaine mise à jour, ce qui rend tous les fichiers dexpreopt obsolètes et inutilisables.

Plusieurs options de compilation ART sont 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 fichiers JAR/APK compilés dans une ROM système peuvent être divisés en quatre catégories:

  • Code de chemin d'accès au démarrage: compilé avec le filtre de compilation 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 et PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS plus loin dans ce document) :
    • (Android 14 et versions ultérieures) Compilé avec le filtre de compilateur speed-profile par défaut, ou compilé avec le filtre de compilateur speed si aucun profil n'est fourni.
    • (Android 13 ou version antérieure) Compilé avec le filtre de 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 de compilation speed par défaut.
  • Toutes les autres applications: compilation avec le filtre de compilation speed-profile par défaut ou compilation avec le filtre de compilation verify si aucun profil n'est fourni.

    Configurable via PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (voir plus loin dans ce document).

Options Makefile

  • WITH_DEXPREOPT

    • Indique si dex2oat est appelé sur le code DEX installé sur l'image système. Activée par défaut.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 ou version ultérieure)

    • L'activation de DONT_DEXPREOPT_PREBUILTS empêche les précompilés d'être déprécompilés. Il s'agit d'applications pour lesquelles include $(BUILD_PREBUILT) est spécifié dans Android.mk. Ignorer le dépréopt de l'application précompilée susceptible d'être mise à jour via Google Play permet d'économiser de l'espace dans l'image système, mais augmente le temps de démarrage initial. Notez que cette option n'a aucune incidence sur les applications précompilées définies dans Android.bp.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 ou version ultérieure)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER spécifie le filtre de compilation par défaut pour les applications dexpréoptées. Ces applications sont définies dans Android.bp ou ont 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 aucune valeur n'est 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 ne dépréopte que le chemin d'accès au chemin d'accès au démarrage et les fichiers JAR du serveur système.

  • LOCAL_DEX_PREOPT

    • Dexpreopt peut également être activé ou désactivé pour chaque application en spécifiant l'option LOCAL_DEX_PREOPT dans la définition du module. Cela peut être utile pour désactiver le prédéploiement dex de certaines applications susceptibles de recevoir immédiatement des mises à jour Google Play, car les mises à jour rendraient le code prédéployé dex dans l'image système obsolète. Cela permet également d'économiser de l'espace sur les mises à niveau OTA majeures, car les utilisateurs peuvent déjà disposer de versions plus récentes des applications dans la partition de données.

    LOCAL_DEX_PREOPT accepte 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 dexpreopt. Toutefois, cette dernière option est nécessaire pour que les signatures APK tierces restent valides.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Transmet des options à dex2oat pour contrôler la compilation de l'image de démarrage. 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 compilation.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Transmet des options à dex2oat pour contrôler la compilation de tout ce qui n'est pas l'image de démarrage.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Permet de transmettre des options dex2oat pour un module et une configuration de produit spécifiques. 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.

  • PRODUCT_DEXPREOPT_SPEED_APPS (depuis Android 8)

    • Liste des applications identifiées comme essentielles aux produits et qu'il est souhaitable de compiler avec le filtre de compilation speed. Par exemple, les applications persistantes telles que SystemUI n'ont la possibilité d'utiliser la compilation guidée par profil qu'au prochain redémarrage. Il peut donc être préférable que ces applications soient toujours compilées AOT pour le produit.

  • 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 de compilation speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (depuis Android 8)

    • Indique si une version de débogage d'ART doit être incluse sur l'appareil. Par défaut, cette option est activée pour les builds userdebug et eng. Vous pouvez remplacer ce comportement en définissant explicitement l'option sur true ou false.

    Par défaut, l'appareil utilise la version non de débogage (libart.so). Pour passer à la version de débogage, 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). Ainsi, le code compilé de l'image n'a pas besoin d'être déplacé de /system vers /data/dalvik-cache, ce qui économise de l'espace dans la partition de données. Toutefois, il existe un léger impact au moment de l'exécution, car il désactive une optimisation qui exploite le code dépendant de la position. En règle générale, les appareils qui souhaitent économiser de l'espace dans /data doivent activer la compilation PIC.

    Dans 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 fichiers 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) Si ce champ n'est pas spécifié, le filtre de compilation speed-profile est utilisé, ou le filtre de compilation speed est utilisé si aucun profil n'est fourni.
    • (Android 13 et versions antérieures) Si elle n'est pas spécifiée, le filtre du compilateur speed est utilisé.
    • Si la valeur est speed, le filtre du compilateur speed est utilisé.
    • Si la valeur est speed-profile, le filtre du compilateur speed-profile est utilisé, ou le filtre du compilateur verify est utilisé si aucun profil n'est fourni.
    • Si la valeur est 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

    • Vous trouverez ci-dessous la liste des fichiers JAR chargés par le serveur système. Les fichiers JAR sont compilés avec le filtre de compilation spécifié par PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.

    • (Obligatoire) PRODUCT_SYSTEM_SERVER_JARS: liste des fichiers JAR de chemin d'accès au système du serveur sur la plate-forme (c'est-à-dire dans SYSTEMSERVERCLASSPATH). L'ajout de fichiers JAR de chemin d'accès au système du serveur à cette liste est obligatoire. Si vous n'ajoutez pas les fichiers JAR de classpath 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 d'accès au cours du serveur système fournis avec APEX (c'est-à-dire dans SYSTEMSERVERCLASSPATH). Le format est <apex name>:<jar name>. Vous devez ajouter les fichiers JAR de chemin d'accès au serveur système APEX à cette liste. Si vous n'ajoutez pas les fichiers JAR de classpath 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 fichiers JAR de serveur système autonomes à cette liste n'est pas obligatoire, mais fortement recommandé, car il permet de compiler les fichiers JAR et de bénéficier ainsi de bonnes performances d'exécution.
    • (obligatoire, depuis Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: liste des fichiers 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>. Vous devez ajouter les fichiers JAR de serveur système APEX autonomes à cette liste. Si vous n'ajoutez pas de fichiers JAR de serveur système APEX autonomes à cette liste, le démarrage échoue.

    Configuration du chemin d'accès des classes de démarrage

    La liste des classes préchargées est une liste de classes qu'Zygote initialise au démarrage. Cela évite à chaque application d'avoir à exécuter ces initialisateurs 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 dans frameworks/base/config/preloaded-classes par défaut. Il contient une liste adaptée à une utilisation typique du téléphone. Cela peut être différent pour d'autres appareils tels que les accessoires connectés, et doit être configuré en conséquence. Soyez prudent lorsque vous effectuez ce réglage. Ajouter trop de classes gaspille de la mémoire lorsque des classes inutilisées sont chargées. Ajouter trop peu de classes oblige chaque application à disposer de sa propre copie, ce qui gaspille de la mémoire.

    Exemple d'utilisation (dans le fichier device.mk du produit):

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

    Remarque:Vous devez placer cette ligne avant d'hériter de tout fichier de compilation de configuration de produit qui obtient celui par défaut de build/target/product/base.mk.

    Configuration de l'environnement d'exécution

    Options JIT

    Les options suivantes n'affectent les versions Android que lorsque le compilateur JIT ART 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 effectue régulièrement une collecte des garbages et augmente si nécessaire.
    • dalvik.vm.jitmaxsize (64 Mo par défaut): capacité maximale du cache de code.
    • dalvik.vm.jitthreshold (valeur 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 par JIT. Le compteur "hotness" est une métrique interne à l'environnement d'exécution. Il comprend le nombre d'appels, de branches arrière et d'autres facteurs.
    • dalvik.vm.usejitprofiles (jusqu'à Android 13): indique si les profils JIT sont activés. Cette valeur peut être utilisée même si dalvik.vm.usejit est défini sur "false". Notez que si cette valeur est fausse, le filtre de compilateur speed-profile ne compile aucune méthode AOT et est équivalent à 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): pondération des "échantillons" JIT (voir jitthreshold) pour le thread d'UI de l'application. À utiliser pour accélérer la compilation des méthodes qui affectent directement l'expérience utilisateur lorsqu'il interagit avec l'application.
    • dalvik.vm.jittransitionweight (par défaut, dalvik.vm.jitthreshold / 10) : poids de l'appel de méthode qui passe du code de compilation à l'interpréteur. Cela permet de s'assurer 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 (également appelée dexopt), et certaines d'entre elles affectent également dexpreopt, tandis 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): nombre de threads et 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) Nombre de threads et ensemble de cœurs de processeur (voir ci-dessous) à utiliser au démarrage pour tout ce qui n'est pas une image de démarrage.
      • (depuis Android 12) Nombre de threads et ensemble de cœurs de processeur (voir ci-dessous) à utiliser au démarrage pour tout, y compris les images de démarrage.
        • Plus précisément, depuis Android 14, cela correspond à la classe de priorité PRIORITY_BOOT dans le service ART.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set :
      • (depuis Android 11, jusqu'à Android 13) Nombre de threads et ensemble de cœurs de processeur (voir ci-dessous) à utiliser pour la restauration à partir d'une sauvegarde dans le cloud.
      • (depuis Android 14) Nombre de threads et ensemble de 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 dans le 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): nombre de threads et ensemble de cœurs de processeur (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 : nombre de threads et ensemble de cœurs de processeur à utiliser pour tout le reste.

    Un ensemble de cœurs de processeur doit être spécifié sous la forme d'une liste d'ID de processeur séparés par une virgule. Par exemple, pour exécuter dex2oat sur les cœurs de processeur 0 à 3, définissez:

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

    Lorsque vous définissez les propriétés d'affinité de processeur, nous vous recommandons de faire correspondre la propriété correspondante pour le nombre de threads dex2oat au nombre de processeurs sélectionnés afin d'éviter toute contention de mémoire et d'E/S inutile: 

    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âche pour contrôler l'utilisation des ressources de dex2oat (voir la section Cgroup Abstraction Layer).

    Les profils de tâche compatibles sont les suivants:

    • Dex2OatBackground (depuis Android 14) (par défaut, hérite de 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 ce qui se passe 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âche sont tous deux spécifiés, les deux prennent effet.

    Options pour contrôler la taille du tas:

    • dalvik.vm.image-dex2oat-Xms: taille initiale de la pile pour les images de démarrage.
    • dalvik.vm.image-dex2oat-Xmx: taille maximale de la pile pour les images de démarrage.
    • dalvik.vm.dex2oat-Xms: taille initiale du tas pour tout le reste.
    • dalvik.vm.dex2oat-Xmx: taille maximale de la pile pour tout le reste.

    Les options qui contrôlent la taille initiale et maximale de la pile pour dex2oat ne doivent pas être réduites, car elles pourraient limiter les applications pouvant être compilées.

    Options permettant de contrôler le filtre du compilateur:

    • dalvik.vm.image-dex2oat-filter (jusqu'à Android 11) : 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) : filtre du compilateur pour le serveur système. Consultez PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
    • dalvik.vm.systemuicompilerfilter (depuis Android 13) : filtre du compilateur pour le package d'interface utilisateur système.
    • dalvik.vm.dex2oat-filter (jusqu'à Android 6) : filtre du compilateur pour tout le reste.
    • pm.dexopt.<reason> (depuis Android 7) : filtre du compilateur pour tout le reste. Consultez la section Configuration du service ART pour Android 14 et versions ultérieures, ou la section Configuration du gestionnaire de paquets pour Android 13 et versions antérieures.

    Autres options pour contrôler la compilation de tout ce qui n'est pas une image 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 vous aider à éviter les plantages dus à un manque de mémoire. Notez que même si cette option est activée, dex2oat n'utilise un fichier d'échange que dans certaines conditions, par exemple lorsque le nombre de fichiers dex est important et que les conditions sont susceptibles d'évoluer.
    • dalvik.vm.ps-min-first-save-ms (depuis Android 12): durée minimale d'attente avant que l'environnement d'exécution génère un profil de l'application lors du premier lancement de l'application.
    • dalvik.vm.ps-min-save-period-ms (depuis Android 12): temps minimal d'attente avant de mettre à jour le profil de l'application.
    • dalvik.vm.dex2oat64.enabled (depuis Android 11) (valeur par défaut: false) : indique si la version 64 bits de dex2oat doit être utilisée.
    • dalvik.vm.bgdexopt.new-classes-percent (depuis Android 12) (par défaut: 20) : pourcentage minimal, compris entre 0 et 100, de nouvelles classes dans un profil pour déclencher une recompilation. Ne s'applique qu'à la compilation guidée par le profil (speed-profile), généralement lors de la décompilation en arrière-plan. Notez qu'en plus du seuil de pourcentage, il existe également un seuil d'au moins 50 nouvelles classes, qui n'est pas configurable.
    • dalvik.vm.bgdexopt.new-methods-percent (depuis Android 12) (par défaut: 20) : pourcentage minimal, compris entre 0 et 100, de nouvelles méthodes dans un profil pour déclencher une recompilation. Ne s'applique qu'à la compilation guidée par le profil (speed-profile), généralement lors de la décompilation en arrière-plan. Notez qu'en plus du seuil de pourcentage, il existe également un seuil d'au moins 100 nouvelles méthodes, qui n'est pas configurable.
    • dalvik.vm.dex2oat-max-image-block-size (depuis Android 10) (par défaut: 524288) Taille maximale de bloc plein pour les images compressées. Une grande image est divisée en un ensemble de blocs solides, de sorte qu'aucun bloc ne dépasse la taille maximale.
    • dalvik.vm.dex2oat-resolve-startup-strings (depuis Android 10) (valeur par défaut : "true") Si la valeur est "true", dex2oat résout toutes les chaînes constantes référencées à partir de méthodes marquées comme "démarrage" dans le profil.
    • debug.generate-debug-info (valeur par défaut: false) Indique si des informations de débogage doivent être générées pour le débogage natif, telles que des informations de débogage de la pile, des symboles ELF et des sections naines.
    • dalvik.vm.dex2oat-minidebuginfo (depuis Android 9) (par défaut : "true") Indique si générer ou non une quantité minimale d'informations de débogage compressées au format LZMA nécessaires pour imprimer des rétrotraces.

    Options de service ART

    Depuis Android 14, la compilation AOT sur l'appareil pour les applications (également appelée dexopt) est gérée par le service ART. Pour en savoir plus sur la configuration du service ART, consultez la section Configuration du service ART.

    Options du gestionnaire de paquets

    Avant Android 14, la compilation AOT sur l'appareil pour les applications (également appelée dexopt) est gérée par le gestionnaire de paquets. Pour en savoir plus sur la configuration du gestionnaire de paquets pour dexopt, consultez la section Configuration du gestionnaire de paquets.

    Configuration spécifique au test A/B

    Configuration de la ROM

    À partir d'Android 7.0, les appareils peuvent utiliser deux partitions système pour activer les mises à jour système A/B. Pour réduire la taille de la partition système, les fichiers préoptimisés peuvent être installés dans la deuxième partition système inutilisée. Elles sont ensuite copiées dans 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

    Dans le BoardConfig.mk de l'appareil:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Notez que le code de chemin d'accès au chemin d'accès au démarrage, le code du serveur système et les applications principales spécifiques au produit sont toujours compilés dans la partition système. Par défaut, toutes les autres applications sont compilées dans la deuxième partition système inutilisée. Cela peut être contrôlé avec SYSTEM_OTHER_ODEX_FILTER, qui a la valeur par défaut suivante:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Déxoptimisation OTA en arrière-plan

    Sur les appareils compatibles avec le mode A/B, les applications peuvent être compilées en arrière-plan avant le redémarrage avec la nouvelle image système. Consultez la section Compilation d'applications 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 de l'espace de stockage.

    Options JDWP

    La création de threads JDWP (Java Debug Wire Protocol) dans les builds 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 ne sont créés que pour les applications débogables. Pour activer les threads JDWP pour les applications débogables et non débogables, définissez persist.debug.dalvik.vm.jdwp.enabled sur 1. Vous devez redémarrer l'appareil pour que les modifications apportées à la propriété prennent effet.

    Pour déboguer une application non débogable sur un build userdebug, activez JDWP en exécutant la commande suivante:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Pour les appareils équipés d'Android 13 ou version antérieure, l'environnement d'exécution crée des threads JDWP pour les applications débogables et non débogables sur les builds userdebug. Cela signifie qu'il est possible d'attacher un débogueur ou de profiler n'importe quelle application sur les builds userdebug.