Configurer ART

Cette page explique comment configurer Android Runtime (ART) et ses options de compilation. Thèmes abordés ici incluent la configuration de la précompilation de l'image système, dex2oat les options de compilation et comment trouver le compromis entre l’espace de partition du système, l’espace de partition des données et des performances.

Consultez ART et Dalvik, ainsi que le format exécutable Dalvik pour utiliser ART. Reportez-vous à la section Vérification App Behavior on the Android Runtime (ART) pour garantir le bon fonctionnement de vos applications correctement.

Fonctionnement de la technologie ART

ART utilise la compilation anticipée (ou compilation AOT) et, à partir d'Android 7, utilise une combinaison hybride de compilation AOT, de compilation juste-à-temps (JIT) et d'interprétation, et la compilation anticipée peut être guidée par le profil. La combinaison de tous ces modes d'exécution configurable et que nous aborderons dans cette section. Par exemple, les appareils Pixel sont configurés fonctionnent 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 cloud profil. Si l'application est installée sans fichier de métadonnées dex, aucune compilation AOT n'est d'exécution.
  2. Les premières fois que l'application s'exécute, les méthodes qui ne sont pas compilées de manière anticipée sont interprétées. Parmi les méthodes interprétées, celles qui sont fréquemment exécutées font ensuite l'objet d'une compilation JIT. Art génère un profil local basé sur l'exécution et l'associe au profil cloud (si un .
  3. Lorsque l'appareil est inactif et en charge, un daemon 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 suivantes de l'application, ART utilise les artefacts générés par la compilation qui contiennent plus de code compilé par AOT que ceux générés lors de l'exécution Les méthodes qui ne sont pas compilées AOT sont tout de même interprétées ou compilées JIT. ART met à jour le profil l'installation, en fonction de l'exécution. Le profil est alors récupéré par les exécutions suivantes le daemon de compilation.

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

  • .vdex: contient des métadonnées supplémentaires pour accélérer la validation, parfois accompagnées avec le code DEX non compressé de l'APK.
  • .odex: contient du code compilé par AOT pour les méthodes du APK.
  • .art (optional) contient ART interne 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: quel est le code AOT compilé lors de la création d'un l'image système.
  2. Configuration de l'environnement d'exécution: comment ART compile et exécute les applications sur un appareil.

Filtres du compilateur

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

  • verify: n'exécute que la validation du code DEX (pas de compilation AOT).
  • quicken: (jusqu'à Android 11) exécute le code DEX vérification et optimiser certaines instructions DEX pour améliorer les performances de l'interprète.
  • speed: exécute la vérification du code DEX et effectue une compilation anticipée (ou compilation AOT) pour toutes les méthodes.
  • speed-profile: exécuter les méthodes de validation du code DEX et de compilation anticipée répertoriés dans un fichier de profil.

Configuration de la ROM système

Les bibliothèques et applications préinstallées sont compilées de manière anticipée lors de la création d'une image système. Ce s'appelle dexpreopt. Ces fichiers compilés sont utilisables tant que toutes les dépendances restent inchangées, en particulier le classpath de démarrage.

Remarque:Si l'appareil prend le module système, alors le chemin de classe de démarrage susceptibles 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 compilation ART disponibles pour configurer dexpreopt. Comment configurer ces options dépendent de l'espace de stockage disponible pour l'image système et du nombre des applications préinstallées. Les fichiers JAR/APK compilés dans une ROM système peuvent être divisés en quatre catégories:

  • Démarrage du code classpath: compilé avec le filtre de compilateur 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): <ph type="x-smartling-placeholder">
      </ph>
    • (Android 14 ou version ultérieure) Compilation avec speed-profile de compilation par défaut, ou compilé avec le filtre de compilateur speed si un profil non fourni.
    • (Android 13 et versions antérieures) Compilation avec speed de compilation par défaut.
    Configurable via PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (plus de détails document).
  • Applications de base spécifiques aux produits (voir PRODUCT_DEXPREOPT_SPEED_APPS plus loin dans ce document): compilé avec le filtre de compilation speed par défaut.
  • Toutes les autres applications: compilées avec le filtre de compilation speed-profile par défaut ou compilées avec le filtre de compilation verify si aucun profil n'est fourni.

    Configurable via PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (plus de détails 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 composants prédéfinis d'être abandonnées. Il s'agit d'applis qui contiennent include $(BUILD_PREBUILT) spécifié dans leur Android.mk. Omission développer 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 cela s'ajoute au 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érieurs)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER spécifie le filtre de compilation par défaut. pour les applications abandonnées. Ces applis sont définies dans Android.bp ou ont include $(BUILD_PREBUILT) spécifié dans son Android.mk. Si aucune valeur n'est spécifiée, la valeur par défaut est speed-profile, ou verify si la valeur n'est pas spécifiée. et 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 désactive uniquement les le classpath de démarrage et les fichiers JAR du serveur système.

  • LOCAL_DEX_PREOPT

    • Vous pouvez activer ou désactiver Dexpreopt pour une application spécifique en en spécifiant l'option LOCAL_DEX_PREOPT dans la définition du module. Cela peut être utile pour désactiver l'abandon d'applications recevoir des mises à jour Google Play, car elles entraîneraient l'abandon dans l'image système est obsolète. Cela permet également d'économiser de l'espace sur des mises à niveau de version, car les utilisateurs disposent peut-être déjà de versions plus récentes des applications partition de données.

    LOCAL_DEX_PREOPT accepte les valeurs true ou false pour activer ou désactiver dexpreopt, respectivement. De plus, nostripping peut doit être spécifié si dexpreopt ne doit pas supprimer classes.dex à partir du fichier APK ou JAR. Normalement, ce fichier est supprimé, car il n'est pas plus longtemps nécessaires après la dexpreopt, mais cette dernière option est nécessaire pour pour que les signatures d'APK tiers restent valides.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Transmet des options à dex2oat pour contrôler l'état de l'image de démarrage compilées. Il permet de spécifier des listes de classes d'images personnalisées, compilées les listes de classes et les filtres de compilateur.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Transmet les options à dex2oat pour contrôler la façon dont tous les éléments, à l'exception des l'image de démarrage est compilée.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Permet de transmettre des options dex2oat pour un élément du module et de la configuration du produit. Il est défini dans le device.mk fichier par $(call add-product-dex-preopt-module-config,<modules>,<option>) où <modules> est une liste de LOCAL_MODULE et Noms LOCAL_PACKAGE pour les fichiers JAR et APK, respectivement.

  • PRODUCT_DEXPREOPT_SPEED_APPS (depuis Android 8)

    • Liste des applications considérées comme essentielles aux produits et souhaitant être compilés avec le filtre de compilation speed. Pour exemple, les applications persistantes telles que SystemUI ont la possibilité d'utiliser compilation guidée des profils uniquement lors du prochain redémarrage. Elle peut donc être préférable pour produit pour que ces applications soient toujours compilées de manière anticipée.

  • PRODUCT_SYSTEM_SERVER_APPS (depuis Android 8)

    • Liste des applications chargées par le serveur système. Ces applications sont compilés par défaut avec le filtre de compilateur speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (depuis Android 8).

    • Indique s'il faut inclure une version de débogage d'ART sur l'appareil. Par défaut, il s'agit activé pour userdebug et eng builds. Le comportement peut être ignoré en en définissant l'option sur true ou false.

    Par défaut, l'appareil utilise la version non débogable (libart.so). Pour changer de niveau, définissez la propriété système persist.sys.dalvik.vm.lib.2 sur libartd.so

  • WITH_DEXPREOPT_PIC (jusqu'à Android 7)

    • Sur Android 5.1.0 à Android 6.0.1, WITH_DEXPREOPT_PIC peut pour activer le code indépendant de la position (PIC). Avec cela, compilé du code de l'image n'a pas besoin d'être déplacé /system dans /data/dalvik-cache, ce qui permet d'économiser de l'espace dans la partition de données. Cependant, il y a un léger impact au moment de l'exécution, car il désactive une optimisation qui tire parti du code dépendant de la position. Généralement, les appareils souhaitent économiser de l'espace dans /data doit permettre 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 de compilation pour le serveur système.

    • (Android 14 ou version ultérieure) Si aucune valeur n'est spécifiée, speed-profile le filtre de compilateur est utilisé, ou le filtre de compilateur speed est utilisé si un profil n'est pas fournies.
    • (Android 13 ou version antérieure) S'il n'est pas spécifié, le compilateur speed est utilisé.
    • S'il est défini sur speed, le filtre de compilation speed est utilisé.
    • S'il est défini sur speed-profile, le filtre de compilation speed-profile est utilisé. ou le filtre de compilation verify est utilisé si aucun profil n'est fourni.
    • S'il est défini sur verify, le filtre de compilation 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 des fichiers JAR chargés par le serveur système. Les fichiers JAR sont compilés avec le fichier filtre de compilateur spécifié par PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obligatoire) PRODUCT_SYSTEM_SERVER_JARS: liste des fichiers JAR du chemin de classe du serveur système sur la plate-forme (c'est-à-dire dans SYSTEMSERVERCLASSPATH). Ajouter un serveur système Les fichiers JAR classpath vers cette liste sont obligatoires. Échec de l'ajout des fichiers JAR de classpath du serveur système à la liste entraîne le chargement de ces fichiers JAR.
    • (Obligatoire) PRODUCT_APEX_SYSTEM_SERVER_JARS: liste des fichiers JAR de chemin de classe du serveur système envoyé avec APEX (c'est-à-dire dans le cadre de SYSTEMSERVERCLASSPATH). Le format est le suivant : <apex name>:<jar name> Ajouter des fichiers JAR de classpath du serveur système APEX à cette liste est obligatoire. L'échec de l'ajout de fichiers JAR de classpath du serveur système APEX à cette liste entraîne les fichiers JAR ne sont pas chargés.
    • (Facultatif, Android 13 ou version antérieure) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: liste des fichiers JAR chargés par le serveur système de manière dynamique à l'aide de ClassLoaders distincts (via SystemServiceManager.startServiceFromJar). Ajouter des fichiers JAR de serveurs système autonomes à Cette liste n'est pas obligatoire, mais vivement recommandée, car elle permet de compiler les fichiers JAR donc de bonnes performances d'exécution.
    • (obligatoire, depuis Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: liste Fichiers JAR fournis avec APEX que le serveur système charge dynamiquement à l'aide de ClassLoaders distincts (qui est, via SystemServiceManager.startServiceFromJar, ou déclarée comme <apex-system-service>). Le format est le suivant : <apex name>:<jar name> L'ajout des fichiers JAR des serveurs système APEX autonomes à cette liste est obligatoire. Si vous n'ajoutez pas de fichiers JAR de serveur système APEX autonome à cette liste, cela entraînera au démarrage.

    Configuration du classpath de démarrage

    La liste des classes préchargées est une liste des classes sur lesquelles 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. La le fichier de liste des classes préchargées se trouve sous frameworks/base/config/preloaded-classes par défaut et il contient une liste adaptée à une utilisation typique du téléphone. Cela pourrait est différente pour d'autres appareils, comme les accessoires connectés, et doit être réglé en conséquence. Soyez prudent lorsque vous ajustez ceci : ajouter trop de classes de gaspillage de mémoire lorsque les classes inutilisées sont chargées. L'ajout d'un nombre insuffisant de classes force chaque application à n'ont pas besoin d'avoir leur propre copie, ce qui gaspille de la mémoire.

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

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

    Remarque:Vous devez placer cette ligne avant sans hériter de tout fichier makefile de configuration de produit qui récupère le fichier par défaut build/target/product/base.mk

    Configuration de l'environnement d'exécution

    Options JIT

    Les options suivantes ne concernent que les versions Android où le compilateur JIT ART est utilisé. est disponible.

    • dalvik.vm.usejit: indique si le JIT est activé ou non.
    • dalvik.vm.jitinitialsize (64 K par défaut): capacité initiale du cache de code. Le cache de code est régulièrement récupéré et augmenté si nécessaire.
    • dalvik.vm.jitmaxsize (64 M par défaut): capacité maximale du cache de code.
    • dalvik.vm.jitthreshold (10 000 par défaut): Le seuil de la chaleur d'une méthode doit être transmis dans l'ordre pour que la méthode soit compilée à JIT. La chaleur Le compteur est une métrique interne à l'environnement d'exécution. Cela inclut le nombre d'appels, les branches antérieures et d'autres .
    • dalvik.vm.usejitprofiles (jusqu'à Android 13): indique si les profils JIT ne sont pas activés ; cette méthode peut être utilisée même si la valeur de dalvik.vm.usejit est "false". Notez que si cette valeur est "false", le filtre de compilation speed-profile n'effectue et non à la compilation AOT. Cette méthode équivaut à verify. Depuis Sous Android 14, les profils JIT sont toujours activés et ne peuvent pas être désactivés.
    • dalvik.vm.jitprithreadweight (valeur par défaut : dalvik.vm.jitthreshold / 20): poids des "échantillons" JIT (voir jitthreshold) pour le thread UI de l'application. À utiliser pour accélérer la compilation de méthodes qui ont une incidence directe sur l'expérience des utilisateurs lorsqu'ils interagissent avec l'application.
    • dalvik.vm.jittransitionweight (valeur par défaut : dalvik.vm.jitthreshold / 10): Pondération de la méthode qui passe du code de compilation à l'interpréteur. Cela vous aide vous assurer que les méthodes impliquées sont compilées pour minimiser les transitions (qui sont chers).

    Options Dex2oat

    Ces options affectent la compilation sur l'appareil (également appelée dexopt), et certaines d'entre elles concernent également dexpreopt, alors que les options décrites dans la section Configuration de la mémoire ROM système ci-dessus uniquement affecte la 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 des 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: <ph type="x-smartling-placeholder">
        </ph>
      • (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 élément que les images de démarrage.
      • (depuis Android 12) le nombre de threads et l'ensemble de cœurs de processeur ; (voir ci-dessous) à utiliser pendant le démarrage pour tout, y compris les images de démarrage.
        • Plus précisément, depuis Android 14, cela correspond au classe prioritaire PRIORITY_BOOT dans le service ART.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set: <ph type="x-smartling-placeholder">
        </ph>
      • (depuis Android 11 jusqu'à Android 13) Nombre de threads et ensemble de cœurs de processeur (voir ci-dessous) à utiliser pour la restauration depuis le cloud sauvegarde.
      • (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 d'habitude, y compris ou restaurer des données à partir de la sauvegarde dans le cloud.
        • Plus précisément, elle 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 de cœurs de processeur (voir ci-dessous) à utiliser en arrière-plan.
      • Plus précisément, elle correspond à la classe de priorité PRIORITY_BACKGROUND dans 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 sur dex2oat sur les cœurs de processeur 0-3, défini:

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

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

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

    Outre les 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 (consultez la section Couche d'abstraction Cgroup).

    Les profils de tâches compatibles sont les suivants:

    • Dex2OatBackground (depuis Android 14) (hérite par défaut de Dex2OatBootComplete): Contrôle les ressources à utiliser en arrière-plan.
      • Plus précisément, elle correspond à la classe de priorité PRIORITY_BACKGROUND dans Service ART.
    • Dex2OatBootComplete: <ph type="x-smartling-placeholder">
        </ph>
      • (jusqu'à Android 13) Contrôle la ressource à utiliser pour tous les éléments après le démarrage.
      • Contrôle la ressource à utiliser pour tous les éléments (depuis Android 14) après le démarrage et non en arrière-plan.
        • Plus précisément, elle correspond à la classe de priorité PRIORITY_INTERACTIVE_FAST et PRIORITY_INTERACTIVE dans ART de service.

    Lorsque les propriétés système et les profils de tâche sont spécifiés, les deux prennent effet.

    Options pour contrôler la taille des segments de mémoire:

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

    Les options qui contrôlent la taille initiale et maximale du tas de mémoire pour Les dex2oat ne devraient pas être réduits, car ils pourraient limiter les applications peuvent être compilées.

    Options pour contrôler le filtre de compilation:

    • dalvik.vm.image-dex2oat-filter (jusqu'à Android 11): Filtre de compilateur pour les images de démarrage. Depuis Android 12, le compilateur Le filtre des images de démarrage est toujours speed-profile et ne peut pas être modifié.
    • dalvik.vm.systemservercompilerfilter (depuis Android 13): Filtre de compilateur pour le serveur système. Voir <ph type="x-smartling-placeholder"></ph> PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
    • dalvik.vm.systemuicompilerfilter (depuis Android 13): Filtre de compilateur pour le package UI du système.
    • dalvik.vm.dex2oat-filter (jusqu'à Android 6): Filtre de compilateur pour tout le reste.
    • pm.dexopt.<reason> (depuis Android 7): Filtre de compilateur pour tout le reste. Voir Configuration du service ART pour Android 14 ans et plus Configuration du gestionnaire de paquets pour Android 13 et versions antérieures.

    Autres options pour contrôler la compilation de tout autre élément que les images de démarrage:

    • dalvik.vm.dex2oat-very-large (depuis Android 7.1): taille totale minimale des fichiers DEX en octets pour désactiver la compilation anticipée.
    • dalvik.vm.dex2oat-swap (depuis Android 7.1) (par défaut: true): autorise l'utilisation d'un échange. pour dex2oat. Cela permet d'éviter les plantages de mémoire insuffisante. Notez que même si cette option est activé, dex2oat n'utilise un fichier d'échange que dans certaines conditions, par exemple lorsque le nombre de fichiers dex est volumineux et les conditions sont susceptibles de changer.
    • dalvik.vm.ps-min-first-save-ms (depuis Android 12): le d'attente minimum avant que l'environnement d'exécution génère un profil de l'application. La première fois l'application est lancée.
    • dalvik.vm.ps-min-save-period-ms (depuis Android 12): le délai d'attente minimal avant de mettre à jour le profil de l'application.
    • dalvik.vm.dex2oat64.enabled (depuis Android 11) (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, des nouvelles classes d'un profil pour déclencher une recompilation. S'applique uniquement à la compilation guidée du profil (speed-profile), généralement pendant dexopt. Notez également qu'il existe un seuil d'au moins 50 nouvelles classes en plus le seuil de pourcentage et n'est pas configurable.
    • dalvik.vm.bgdexopt.new-methods-percent (depuis Android 12) (par défaut: 20): Pourcentage minimal, compris entre 0 et 100, des nouvelles méthodes d'un profil pour déclencher une recompilation. S'applique uniquement à la compilation guidée du profil (speed-profile), généralement pendant dexopt. Notez également qu'un seuil d'au moins 100 nouvelles méthodes est requis en plus jusqu'au seuil de pourcentage, et 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 d'images pleines blocs de sorte qu'aucun bloc ne dépasse la taille maximale.
    • dalvik.vm.dex2oat-resolve-startup-strings (depuis Android 10) (par défaut: true) Si la valeur est "true", dex2oat résout toutes les constantes const-string référencées à partir de méthodes marquées comme "démarrage" dans le profil.
    • debug.generate-debug-info (par défaut : "false") Générer ou non des informations de débogage pour le débogage natif, comme le déroulement de la pile des informations, des symboles ELF et des 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 au format LZMA, nécessaires pour imprimer les traces arrière.

    Options de service ART

    Depuis Android 14, la compilation anticipée (ou "dexopt") sur l'appareil gérées par le service ART. Pour en savoir plus sur la configuration du service ART, consultez Configuration du service ART.

    Options du gestionnaire de packages

    Avant Android 14, la compilation anticipée (ou "dexopt") sur l'appareil pour les applications est 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 paquets.

    Configuration spécifique aux tests A/B

    Configuration de la ROM

    À partir d'Android 7.0, les appareils peuvent utiliser deux partitions système pour activer Mises à jour du système A/B Pour économiser la taille de la partition système, les fichiers prédéfinis 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 fichier BoardConfig.mk de l'appareil:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Notez que le code classpath de démarrage, le code du serveur système et le noyau spécifique au produit les applications se compilent toujours sur la partition du système. Par défaut, tous les autres les applications sont compilées sur la deuxième partition système inutilisée. Il peut s'agir contrôlé avec SYSTEM_OTHER_ODEX_FILTER, dont la valeur est définie par valeur par défaut de:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt OTA en arrière-plan

    Sur les appareils compatibles avec les tests A/B, les applications peuvent être compilées en arrière-plan avant le redémarrage à l'aide de l' nouvelle image système. Consultez la section Compilation d'applications dans arrière-plan pour inclure éventuellement le script de compilation et les binaires dans l'image système. La 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 bénéficier de la visite guidée des profils. et d'économiser sur le stockage.

    Options JDWP

    La création d'un thread 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éfini et les threads JDWP ne sont créés que pour les applications débogables. Pour activer les threads JDWP pour les deux pour les applications débogables et non débogables, définissez persist.debug.dalvik.vm.jdwp.enabled à 1. L'appareil doit être redémarré pour que les modifications apportées à la propriété soient prises en compte.

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

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    <ph type="x-smartling-placeholder"> Pour les appareils équipés d'Android 13 ou version antérieure, l'environnement d'exécution crée JDWP. threads pour les applications débogables et non débogables sur les versions userdebug. Cela signifie qu'il est possible pour joindre un débogueur ou profiler une application sur les builds userdebug.