Configurar ART

En esta página, se explica cómo configurar el tiempo de ejecución de Android (ART) y sus opciones de compilación. Temas que aquí se abordan incluyen la configuración de compilación previa de la imagen del sistema, dex2oat opciones de compilación y cómo compensar el espacio de partición del sistema, el espacio de partición de datos y rendimiento.

Consulta ART y Dalvik y el formato ejecutable Dalvik para trabajar con ART. Consulta Verificación Comportamiento de la app en Android Runtime (ART) para garantizar que funcionen correctamente.

Cómo funciona ART

ART usa compilación anticipada (AOT) y, a partir de Android 7, usa una combinación híbrida de compilación AOT, compilación justo a tiempo (JIT) e interpretación, y la compilación AOT se puede guiar por perfiles. La combinación de todos estos modos de ejecución configurables y se analizarán en esta sección. Por ejemplo, los dispositivos Pixel están configurados para funcionan en el siguiente flujo:

  1. Inicialmente, se instala una aplicación con un archivo de metadatos dex (.dm) distribuido por Play Store, que contiene un perfil de nube. El AOT de ART compila los métodos enumerados en la nube perfil. O bien, si la aplicación se instala sin un archivo de metadatos dex, no se realizará ninguna compilación AOT una tarea.
  2. Las primeras veces que se ejecuta la aplicación, se interpretan los métodos que no se compilan con AOT. Entre los métodos interpretados, aquellos que se ejecutan con frecuencia se compilan mediante JIT. ARTE genera un perfil local basado en la ejecución y lo combina con el perfil de nube (si existe existe).
  3. Cuando el dispositivo está inactivo y cargándose, se ejecuta un daemon de compilación para volver a compilar la aplicación. según el perfil combinado generado durante las primeras ejecuciones.
  4. En las ejecuciones posteriores de la aplicación, ART usa los artefactos generados por la compilación. daemon, que contienen más código compilado por AOT, en comparación con los generados durante Los métodos que no se compilan con AOT se interpretan o compilan con JIT. ART actualiza el perfil instalación, según la ejecución, y el perfil será recogido por las ejecuciones posteriores de el daemon de compilación.

ART incluye un compilador (la herramienta dex2oat) y un tiempo de ejecución (libart.so) que se carga durante el inicio. El La herramienta dex2oat toma un archivo APK y genera uno o más. Archivos de artefactos de compilación que carga el entorno de ejecución. La cantidad de archivos, su extensiones y nombres están sujetos a cambios en todas las versiones, pero, a partir del Android 8. Se generan los siguientes archivos:

  • .vdex: Contiene algunos metadatos adicionales para acelerar la verificación, en ocasiones junto con el código DEX sin comprimir del APK.
  • .odex: Contiene código compilado por AOT para los métodos de la APK
  • .art (optional) contiene ART interno de algunas cadenas y clases, que se usan para acelerar inicio de la app.

Opciones de compilación

Existen dos categorías de opciones de compilación para ART:

  1. Configuración de la ROM del sistema: ¿Qué código se compila con AOT al compilar un imagen del sistema.
  2. Configuración del tiempo de ejecución: Cómo ART compila y ejecuta aplicaciones en un dispositivo.

Filtros del compilador

Una opción principal de ART para configurar estas dos categorías es el compilador. filtros. Los filtros del compilador controlan la manera en que ART compila código DEX y es un la opción que se pasa a la herramienta dex2oat. A partir de Android 8, Existen cuatro filtros oficialmente admitidos:

  • verify: Solo ejecuta la verificación de código DEX (no una compilación AOT).
  • quicken: (hasta Android 11) ejecuta el código DEX. y optimizar algunas instrucciones DEX para mejorar el rendimiento de los intérpretes.
  • speed: Ejecuta la verificación de código DEX y realiza la compilación con AOT todos los métodos.
  • speed-profile: Ejecuta la verificación de código DEX y los métodos de compilación AOT enumerado en el archivo de perfil.

Configuración de la ROM del sistema

Las bibliotecas y apps preinstaladas se compilan mediante AOT cuando se compila una imagen del sistema. Esta se denomina dexpreopt. Esos archivos compilados se pueden usar siempre que todas las dependencias permanezcan sin cambios, en particular, en la ruta de clase de inicio.

Nota: Si el dispositivo toma el módulo del sistema, la ruta de clase de inicio es muy Es probable que cambie en la próxima actualización, lo que hace que todos los archivos dexpreopt sean obsoletos e inutilizables.

Existen varias opciones de compilación de ART disponibles para configurar dexpreopt. Cómo configurar según el espacio de almacenamiento disponible para la imagen del sistema y la cantidad y apps preinstaladas. Los archivos JAR o APK que se compilan en una ROM del sistema se pueden dividir en cuatro categorías:

  • Código de ruta de clase de inicio: compilado con el filtro del compilador speed-profile por de forma predeterminada.
  • El código del servidor del sistema (consulta PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS más adelante en este documento):
      .
    • (Android 14 y versiones posteriores) Compilado con speed-profile de compilación de forma predeterminada; o bien se compila con el filtro del compilador speed si se trata de perfil no proporcionado.
    • (Android 13 y versiones anteriores) Compilado con speed de compilación de forma predeterminada.
    Se puede configurar mediante PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (ver más adelante en este documento).
  • Apps principales específicas de productos (consulta PRODUCT_DEXPREOPT_SPEED_APPS más adelante en este documento): compilado con el filtro del compilador speed de forma predeterminada.
  • Todas las demás apps: compiladas con el filtro del compilador speed-profile de forma predeterminada o compilarse con el filtro de compilador verify si no se proporciona un perfil.

    Se puede configurar mediante PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (ver más adelante en este documento).

Opciones de Makefile

  • WITH_DEXPREOPT

    • Indica si se invoca dex2oat en el código DEX instalado en la imagen del sistema. Habilitada de forma predeterminada.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 y versiones posteriores)

    • Si habilitas DONT_DEXPREOPT_PREBUILTS, no se podrán ejecutar las compilaciones previas dexpreoptado. Estas son apps que tienen include $(BUILD_PREBUILT) especificadas en su Android.mk. Omitir dexpreopt de apps compiladas previamente que probablemente se actualicen mediante Google Play ahorra espacio en la imagen del sistema, pero aumenta el tiempo del primer inicio. Ten en cuenta que esta opción no tiene efecto. en apps compiladas previamente definidas en Android.bp.

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9) y versiones posteriores).

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica el filtro del compilador predeterminado. para las aplicaciones dexpreoptadas. Estas apps se definen en Android.bp o tienen Se especificó include $(BUILD_PREBUILT) en su Android.mk. Si no se especifica, el valor predeterminado es speed-profile o verify si no se especifica y no se proporciona un perfil.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (a partir de Android 8 MR1)

    • Si habilitas WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, solo se anula la suscripción la ruta de clase de arranque y los archivos jar del servidor del sistema.

  • LOCAL_DEX_PREOPT

    • Dexpreopt también se puede habilitar o inhabilitar individualmente en una app Especificando la opción LOCAL_DEX_PREOPT en la definición del módulo Esto puede ser útil para inhabilitar la dexpreopt en apps que podrían actualizaciones de Google Play, ya que estas renderizarían el modelo dexpreoptado el código de la imagen de sistema está obsoleto. Esto también es útil para ahorrar espacio en las actualizaciones OTA de versión porque es posible que los usuarios ya tengan versiones más recientes de las apps en el en la partición de datos.

    LOCAL_DEX_PREOPT admite los valores true o false para habilitar o inhabilitar dexpreopt, respectivamente. Además, nostripping puede especificar si dexpreopt no debe eliminar classes.dex del archivo APK o JAR. Por lo general, este archivo se borra, ya que no es después de dexpreopt, pero esta última opción es necesaria para permitir que las firmas de APK de terceros sigan siendo válidas.

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Pasa opciones a dex2oat para controlar cómo se muestra la imagen de arranque. se compilan. Puede usarse para especificar listas de clases de imágenes personalizadas, compiladas listas de clases y filtros de compilador.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • Pasa opciones a dex2oat para controlar cómo todo, excepto la de arranque se compila la imagen de arranque.

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • Proporciona la capacidad de pasar las opciones de dex2oat para un usuario en particular. configuración de módulo y producto. Se encuentra en el device.mk archivo de $(call add-product-dex-preopt-module-config,<modules>,<option>) donde <modules> es una lista de LOCAL_MODULE y Nombres LOCAL_PACKAGE para los archivos JAR y APK, respectivamente.

  • PRODUCT_DEXPREOPT_SPEED_APPS (desde Android 8)

    • Lista de aplicaciones que se identificaron como principales para los productos que quieres compilar con el filtro speed del compilador. Para Por ejemplo, las apps persistentes, como SystemUI, tienen la oportunidad de usar compilación guiada por perfiles solo en el próximo reinicio, por lo que podría ser mejor para el producto para que estas apps siempre se compilen con AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (desde Android 8)

    • Lista de apps cargadas por el servidor del sistema. Estas apps se compilan de forma predeterminada con el filtro de compilador speed.

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (desde Android 8)

    • Establece si se debe incluir una versión de depuración de ART en el dispositivo. De forma predeterminada, este es habilitado para compilaciones userdebug y eng. El comportamiento se puede anular con configurar la opción en true o false

    De forma predeterminada, el dispositivo usa la versión de no depuración (libart.so). Para realizar el cambio, establece la propiedad del sistema persist.sys.dalvik.vm.lib.2 en libartd.so

  • WITH_DEXPREOPT_PIC (hasta Android 7)

    • En Android 5.1.0 a Android 6.0.1, WITH_DEXPREOPT_PIC puede para habilitar el código independiente de la posición (PIC). Con esto, compilado código de la imagen no tenga que reubicarse desde /system en /data/dalvik-cache, lo que ahorra espacio en la partición de datos Sin embargo, hay un leve impacto en el tiempo de ejecución porque inhabilita una optimización que aprovecha de un código dependiente de la posición. Por lo general, los dispositivos para ahorrar espacio en /data debería permitir la compilación de PIC.

    En Android 7.0, la compilación de PIC estaba habilitada de forma predeterminada.

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (hasta Android 7) MR1)

    • Esta opción se reemplazó por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY que también adopta previamente los JAR del servidor del sistema.

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • Esta opción especifica el filtro del compilador para el servidor del sistema.

    • (Android 14 y versiones posteriores) Si no se especifica, el atributo speed-profile Se usa el filtro del compilador o el filtro del compilador speed si no se usa un perfil que se proporcionan.
    • (Android 13 y versiones anteriores) Si no se especifica, el compilador speed filtro.
    • Si se configura en speed, se usa el filtro del compilador speed.
    • Si se establece en speed-profile, se usa el filtro del compilador speed-profile. o se usa el filtro del compilador verify si no se proporciona un perfil.
    • Si se configura en verify, se usa el filtro del compilador verify.

  • PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • Las siguientes son listas de los archivos JAR que carga el servidor del sistema. Los archivos JAR se compilan con el filtro de compilador especificado por PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • (Obligatorio) PRODUCT_SYSTEM_SERVER_JARS: Lista de archivos JAR de rutas de clase del servidor del sistema activados la plataforma (es decir, como parte de SYSTEMSERVERCLASSPATH). Agregando el servidor del sistema los archivos JAR de ruta de clase a esta lista son obligatorios. No se pudieron agregar los archivos JAR de rutas de clase del servidor del sistema a la lista y hará que no se carguen esos archivos JAR.
    • (Obligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS: Lista de archivos JAR de rutas de clase del servidor del sistema se publiquen con APEX (es decir, como parte de SYSTEMSERVERCLASSPATH). El formato es <apex name>:<jar name> Agrega archivos JAR de rutas de clase del servidor del sistema APEX a esta lista es obligatoria. Si no se agregan los archivos JAR de rutas de clase del servidor del sistema APEX a esta lista, se generará que no se carguen.
    • (Opcional, Android 13 y versiones anteriores) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: Lista de archivos JAR que carga el servidor del sistema de forma dinámica con cargadores de clases separados SystemServiceManager.startServiceFromJar). Agregar archivos JAR de servidores del sistema independientes a Esta lista no es obligatoria, pero se recomienda muy porque hace que los archivos JAR se compilen y por lo tanto, tienen un buen rendimiento del entorno de ejecución.
    • (obligatorio a partir de Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: Lista de JAR entregados con APEX que el servidor del sistema carga dinámicamente usando cargadores de clases separados (que es mediante SystemServiceManager.startServiceFromJar o se declaró como <apex-system-service>). El formato es <apex name>:<jar name> Agregar archivos JAR independientes del servidor del sistema APEX a esta lista es obligatoria. Si no se agregan archivos JAR del servidor del sistema APEX independientes a esta lista, se generará falla de inicio.

    Configuración de la ruta de clase de inicio

    La lista de clases precargadas es una lista de clases en las que se inicializa Zygote. inicio. De esta manera, se evita que cada app tenga que ejecutar estos inicializadores de clase por separado, lo que les permite iniciarse más rápido y compartir páginas en la memoria. El El archivo de lista de clases precargado se encuentra en frameworks/base/config/preloaded-classes de forma predeterminada y contiene una lista ajustada para el uso típico del teléfono. Esto podría ser diferente para otros dispositivos como wearables y se debe ajustar según corresponda. Ten cuidado cuando ajustes esto: agregar demasiados desperdicios de clases de memoria cuando se cargan las clases sin usar. Agregar muy pocas clases fuerza a cada app a debe tener su propia copia, lo que, como dijimos, desperdicia memoria.

    Ejemplo de uso (en el device.mk del producto):

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

    Nota: Debes colocar esta línea antes los archivos makefile de configuración del producto que obtienen el predeterminado build/target/product/base.mk

    Configuración del entorno de ejecución

    Opciones de JIT

    Las siguientes opciones afectan a las versiones de Android solo en las que el compilador ART JIT está disponible.

    • dalvik.vm.usejit: Indica si JIT está habilitado o no.
    • dalvik.vm.jitinitialsize (valor predeterminado de 64 K): la capacidad inicial de la caché de código. La caché de código generará una recolección de elementos no utilizados con regularidad y aumentará si es necesario.
    • dalvik.vm.jitmaxsize (64 M predeterminado): Es la capacidad máxima de la caché de código.
    • dalvik.vm.jitthreshold (el valor predeterminado es 10000): El umbral de "calor" contador de un método debe pasar en orden para que el método se compile con JIT. El "calentamiento" contador es una métrica interna al entorno de ejecución. Incluye la cantidad de llamadas, ramas inversas y otras factores.
    • dalvik.vm.usejitprofiles (hasta Android 13): Indica si no estén habilitados los perfiles JIT. se puede usar incluso si dalvik.vm.usejit es falso. Ten en cuenta que, si es falso, el filtro del compilador speed-profile sí no debe compilar mediante AOT ningún método y es equivalente a verify. Desde En Android 14, los perfiles JIT siempre están habilitados y no se pueden desactivar.
    • dalvik.vm.jitprithreadweight (valor predeterminado: dalvik.vm.jitthreshold / 20): Es el peso de las "muestras" de JIT. (consulta jitthreshold) para el subproceso de IU de la aplicación. Úsala para acelerar la compilación de métodos que afectan directamente la experiencia del usuario al interactuar con el .
    • dalvik.vm.jittransitionweight (valor predeterminado: dalvik.vm.jitthreshold / 10): La ponderación del método que hace la transición entre el código de compilación y el intérprete. Esto ayuda asegúrese de que los métodos involucrados se compilen para minimizar las transiciones (que son costosas).

    Opciones de Dex2oat

    Estas opciones afectan la compilación en el dispositivo (también conocida como dexopt), y algunas de ellas también afectan dexpreopt, mientras que las opciones que se analizaron en la sección anterior solo en la sección Configuración de la ROM del sistema afectará a dexpreopt.

    Opciones para controlar el uso de recursos:

    • dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (hasta Android 11): La cantidad de subprocesos y el conjunto de núcleos de CPU (consulta las secciones a continuación) para usarlos en imágenes de arranque.
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • La cantidad de subprocesos y el conjunto de núcleos de CPU (hasta Android 11) (consulta a continuación) para usar durante el tiempo de inicio con todo excepto en imágenes de arranque.
      • (a partir de Android 12) La cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) para usar durante el tiempo de inicio para todo, incluidas las imágenes de inicio.
        • En concreto, a partir de Android 14, esto corresponde a la la clase de prioridad PRIORITY_BOOT en el servicio de ART.
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (desde Android 11 hasta Android 13). El la cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) que se usarán para restablecer desde la nube crear una copia de seguridad de su contenido.
      • (a partir de Android 14) La cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) para usar en todo lo que sea más sensible a la latencia de lo normal, como restablecer desde la copia de seguridad en la nube.
        • Específicamente, corresponde a la clase de prioridad. PRIORITY_INTERACTIVE_FAST en el servicio de ART.
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (a partir de Android 14): La cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) para usar en segundo plano.
      • Específicamente, esto corresponde a la clase de prioridad PRIORITY_BACKGROUND en Servicio de ART.
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: La cantidad de subprocesos y el conjunto de núcleos de CPU que se usarán para todo lo demás.

    Se debe especificar un conjunto de núcleos de CPU en una lista separada por comas de IDs de CPU. Por ejemplo, para ejecutar en dex2oat en núcleos de CPU 0-3, establece:

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

    Cuando configures las propiedades de afinidad de la CPU, te recomendamos que hagas coincidir la propiedad correspondiente para el cantidad de subprocesos de dex2oat para coincidir con la cantidad de CPU seleccionadas y así evitar memorias y E/S innecesarias contención: 

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

    Además de las propiedades del sistema anteriores, también puedes usar perfiles de tareas para controlar la el uso de recursos de dex2oat (consulta Capa de abstracción de Cgroup).

    Los perfiles de tareas admitidos son los siguientes:

    • Dex2OatBackground (a partir de Android 14) (hereda Dex2OatBootComplete de forma predeterminada): Controla los recursos que se usan en segundo plano.
      • Específicamente, esto corresponde a la clase de prioridad PRIORITY_BACKGROUND en Servicio de ART.
    • Dex2OatBootComplete:
      • Controla el recurso que se usa para todo (hasta Android 13). después del inicio.
      • Controla los recursos que se usarán para todo (a partir de Android 14). después del inicio y no en segundo plano.
        • Específicamente, corresponde a la clase de prioridad. PRIORITY_INTERACTIVE_FAST y PRIORITY_INTERACTIVE en ART Servicio.

    Cuando se especifican las propiedades del sistema y los perfiles de tareas, ambos tienen efecto.

    Opciones para controlar el tamaño del montón:

    • dalvik.vm.image-dex2oat-Xms: Es el tamaño inicial del montón para las imágenes de arranque.
    • dalvik.vm.image-dex2oat-Xmx: Es el tamaño máximo de montón para las imágenes de arranque.
    • dalvik.vm.dex2oat-Xms: Es el tamaño inicial del montón para todo lo demás.
    • dalvik.vm.dex2oat-Xmx: Es el tamaño máximo de montón para todo lo demás.

    Las opciones que controlan el tamaño inicial y máximo de montón Los dex2oat no deben reducirse, ya que podrían limitar lo que se pueden compilar aplicaciones.

    Opciones para controlar el filtro del compilador:

    • dalvik.vm.image-dex2oat-filter (hasta Android 11): El filtro del compilador para imágenes de arranque. A partir de Android 12, el compilador el filtro para las imágenes de arranque siempre es speed-profile y no se puede cambiar.
    • dalvik.vm.systemservercompilerfilter (a partir de Android 13): El filtro del compilador para el servidor del sistema. Consulta PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
    • dalvik.vm.systemuicompilerfilter (a partir de Android 13): El filtro del compilador para el paquete de IU del sistema.
    • dalvik.vm.dex2oat-filter (hasta Android 6): El filtro del compilador para todo lo demás.
    • pm.dexopt.<reason> (desde Android 7): El filtro del compilador para todo lo demás. Consulta Configuración del servicio de ART para Android 14 o más, o Configuración del administrador de paquetes Android 13 o versiones anteriores

    Otras opciones para controlar la compilación de todo, excepto de imágenes de arranque:

    • dalvik.vm.dex2oat-very-large (desde Android 7.1): Tamaño mínimo total de archivo dex en bytes para inhabilitar la compilación AOT.
    • dalvik.vm.dex2oat-swap (a partir de Android 7.1) (predeterminado: verdadero): Permite usar un intercambio para dex2oat. Esto puede ayudar a evitar fallas por falta de memoria. Ten en cuenta que incluso si esta opción es activado, dex2oat solo usará un archivo de intercambio en ciertas condiciones, como cuando se muestra de los archivos dex es grande y las condiciones están sujetas a cambios.
    • dalvik.vm.ps-min-first-save-ms (desde Android 12): el tiempo mínimo de espera antes de que el entorno de ejecución genere un perfil de la aplicación, la primera vez se inicia la aplicación.
    • dalvik.vm.ps-min-save-period-ms (desde Android 12): el tiempo mínimo de espera antes de actualizar el perfil de la aplicación.
    • dalvik.vm.dex2oat64.enabled (desde Android 11) (predeterminado: false): Indica si se debe usar la versión de 64 bits de dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (a partir de Android 12) (valor predeterminado: 20): El porcentaje mínimo, entre 0 y 100, de clases nuevas en un perfil para activar una recompilación. Solo se aplica a la compilación guiada por perfiles (speed-profile), generalmente durante dexopt en segundo plano. Ten en cuenta que también hay un umbral de al menos 50 clases nuevas además de el umbral de porcentaje y no se puede configurar.
    • dalvik.vm.bgdexopt.new-methods-percent (a partir de Android 12) (valor predeterminado: 20): El porcentaje mínimo, entre 0 y 100, de métodos nuevos en un perfil para activar una recompilación. Solo se aplica a la compilación guiada por perfiles (speed-profile), generalmente durante dexopt en segundo plano. Ten en cuenta que también hay un umbral de al menos 100 métodos nuevos además al umbral de porcentaje y no se puede configurar.
    • dalvik.vm.dex2oat-max-image-block-size (a partir de Android 10) (valor predeterminado: 524288) Tamaño máximo de bloque sólido para imágenes comprimidas. Una imagen grande se divide en un conjunto de bloques, de modo que ningún bloque sea mayor que el tamaño máximo.
    • dalvik.vm.dex2oat-resolve-startup-strings (a partir de Android 10) (predeterminado: true) Si es verdadero, dex2oat resuelve todas las cadenas const a las que se hace referencia desde los métodos marcados como “startup” en el perfil.
    • debug.generate-debug-info (predeterminado: falso) Indica si se debe generar información de depuración o no para la depuración nativa, como el desenrollado de pilas. información, símbolos ELF y secciones enanas.
    • dalvik.vm.dex2oat-minidebuginfo (a partir de Android 9) (predeterminado: true) Genera una cantidad mínima de información de depuración comprimida en LZMA necesaria para imprimir seguimientos.

    Opciones de servicio de ART

    A partir de Android 14, la compilación AOT integrada en el dispositivo para apps (también conocida como dexopt) es manejadas por el servicio de ART. Para obtener información sobre la configuración del servicio de ART, consulta Configuración del servicio de ART

    Opciones del administrador de paquetes

    Antes de Android 14, la compilación AOT integrada en el dispositivo para apps (también conocida como dexopt) es manejada por el administrador de paquetes. Para obtener información sobre cómo configurar el administrador de paquetes para dexopt, consulta Configuración del administrador de paquetes.

    Configuración específica de A/B

    Configuración de la ROM

    A partir de Android 7.0, los dispositivos pueden usar dos particiones del sistema para habilitar Actualizaciones del sistema A/B. Para ahorrar en el tamaño de la partición del sistema, los archivos preoptados se pueden instalar en la segunda partición del sistema sin usar. Luego, se copian en la partición de datos en el primer inicio.

    Ejemplo de uso (en device-common.mk):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    Y en el BoardConfig.mk del dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Ten en cuenta que el código de la ruta de clase de inicio, el código del servidor del sistema y el código las apps siempre se compilan en la partición del sistema. De forma predeterminada, todas las demás las apps se compilan en la segunda partición del sistema sin usar. Puede ser se controla con el SYSTEM_OTHER_ODEX_FILTER, que tiene un valor valor predeterminado:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Dexopt inalámbrico en segundo plano

    En los dispositivos habilitados para A/B, las aplicaciones pueden compilarse en segundo plano antes del reinicio con el nueva imagen del sistema. Consulta Compilación de apps en background de manera opcional para incluir la secuencia de comandos de compilación y los objetos binarios en la imagen del sistema. El El filtro de compilación que se usa para esta compilación se controla con lo siguiente:

    pm.dexopt.ab-ota=speed-profile

    Te recomendamos que uses speed-profile para aprovechar las funciones de compilación y ahorrar en almacenamiento.

    Opciones de JDWP

    La creación de subprocesos de Java Debug Wire Protocol (JDWP) en compilaciones de userdebug se controla a través del Propiedad del sistema persist.debug.dalvik.vm.jdwp.enabled. De forma predeterminada, esta propiedad no está configurado, y los subprocesos de JDWP se crean solo para apps depurables. Para habilitar subprocesos de JDWP apps depurables y no depurables, configura persist.debug.dalvik.vm.jdwp.enabled a 1. Debes reiniciar el dispositivo para que se apliquen los cambios en la propiedad.

    Para depurar una app no depurable en una compilación userdebug, habilita JDWP ejecutando el siguiente comando :

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Para dispositivos que ejecutan Android 13 y versiones anteriores, el entorno de ejecución crea JDWP. subprocesos para apps depurables y no depurables en compilaciones userdebug. Esto significa que es posible para adjuntar un depurador o generar un perfil de cualquier app en compilaciones de userdebug.