Configurar ARTE

Esta página analiza cómo configurar el tiempo de ejecución de Android (ART) y sus opciones de compilación. Los temas que se abordan aquí incluyen la configuración de la precompilación de la imagen del sistema, las opciones de compilación dex2oat y cómo compensar el espacio de la partición del sistema, el espacio de la partición de datos y el rendimiento.

Consulte ART y Dalvik y el formato ejecutable de Dalvik para trabajar con ART. Consulte Verificación del comportamiento de la aplicación en Android Runtime (ART) para garantizar que sus aplicaciones funcionen correctamente.

Cómo funciona el ARTE

ART utiliza compilación anticipada (AOT) y, a partir de Android 7, utiliza una combinación híbrida de compilación AOT, compilación justo a tiempo (JIT) e interpretación, y la compilación AOT puede estar guiada por perfiles. La combinación de todos estos modos de ejecución es configurable y se discutirá en esta sección. Por ejemplo, los dispositivos Pixel están configurados para funcionar 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. ART AOT compila los métodos enumerados en el perfil de la nube. O, si la aplicación se instala sin un archivo de metadatos dex, no se realiza ninguna compilación AOT.
  2. Las primeras veces que se ejecuta la aplicación, se interpretan los métodos que no están compilados con AOT. Entre los métodos interpretados, aquellos que se ejecutan con frecuencia se compilan en JIT. ART genera un perfil local basado en la ejecución y lo combina con el perfil de la nube (si existe).
  3. Cuando el dispositivo está inactivo y cargándose, se ejecuta un demonio de compilación para volver a compilar la aplicación en función del perfil combinado generado durante las primeras ejecuciones.
  4. En las ejecuciones posteriores de la aplicación, ART utiliza los artefactos generados por el demonio de compilación, que contienen más código compilado con AOT, en comparación con los que se generaron durante Los métodos que no están compilados con AOT aún se interpretan o se compilan con JIT. ART actualiza la instalación del perfil en función de la ejecución, y el perfil será recogido por ejecuciones posteriores del demonio de compilación.

ART comprende un compilador (la herramienta dex2oat ) y un tiempo de ejecución ( libart.so ) que se carga durante el arranque. La herramienta dex2oat toma un archivo APK y genera uno o más archivos de artefactos de compilación que carga el tiempo de ejecución. La cantidad de archivos, sus extensiones y nombres están sujetos a cambios según las versiones, pero a partir de la versión de Android 8, se generan estos archivos:

  • .vdex : contiene algunos metadatos adicionales para acelerar la verificación, a veces junto con el código DEX sin comprimir del APK.
  • .odex : contiene código compilado por AOT para métodos en el APK.
  • .art (optional) contiene representaciones internas ART de algunas cadenas y clases enumeradas en el APK, que se utilizan para acelerar el inicio de la aplicación.

Opciones de compilación

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

  1. Configuración de la ROM del sistema: qué código se compila AOT al crear una imagen del sistema.
  2. Configuración de tiempo de ejecución: cómo ART compila y ejecuta aplicaciones en un dispositivo.

Filtros del compilador

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

  • verify : solo ejecute la verificación del código DEX (sin compilación AOT).
  • quicken : (hasta Android 11) ejecute la verificación del código DEX y optimice algunas instrucciones DEX para obtener un mejor rendimiento del intérprete.
  • speed : ejecute la verificación del código DEX y compile AOT todos los métodos.
  • speed-profile : ejecuta la verificación del código DEX y los métodos de compilación AOT enumerados en un archivo de perfil.

Configuración de la ROM del sistema

Las bibliotecas y aplicaciones preinstaladas se compilan en AOT cuando se crea una imagen del sistema. Este proceso se llama dexpreopt . Estos archivos compilados se pueden utilizar siempre que todas las dependencias permanezcan sin cambios, en particular la ruta de clase de inicio.

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

Hay varias opciones de compilación ART disponibles para configurar dexpreopt. La forma de configurar estas opciones depende del espacio de almacenamiento disponible para la imagen del sistema y la cantidad de aplicaciones preinstaladas. Los JAR/APK que se compilan en una ROM del sistema se pueden dividir en cuatro categorías:

  • Código de ruta de clase de arranque: compilado con el filtro del compilador de speed-profile de forma predeterminada.
  • Código del servidor del sistema (consulte 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 el filtro del compilador de speed-profile de forma predeterminada o compilado con el filtro del compilador de speed si no se proporciona un perfil.
    • (Android 13 y versiones anteriores) Compilado con el filtro del compilador de speed de forma predeterminada.
    Configurable a través de PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (ver más adelante en este documento).
  • Aplicaciones principales específicas del producto (consulte PRODUCT_DEXPREOPT_SPEED_APPS más adelante en este documento): compiladas con el filtro del compilador de speed de forma predeterminada.
  • Todas las demás aplicaciones: compiladas con el filtro del compilador de speed-profile de forma predeterminada o compiladas con el filtro del compilador verify si no se proporciona un perfil.

    Configurable a través de PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (ver más adelante en este documento).

Opciones de archivo Make

  • WITH_DEXPREOPT

    • Si se invoca dex2oat en el código DEX instalado en la imagen del sistema. Habilitado de forma predeterminada.

  • DONT_DEXPREOPT_PREBUILTS (Android 5 y superior)

    • Habilitar DONT_DEXPREOPT_PREBUILTS evita que las precompilaciones sean dexpreoptadas. Estas son aplicaciones que include $(BUILD_PREBUILT) especificado en su Android.mk . Omitir dexpreopt de aplicaciones prediseñadas que probablemente se actualizarán a través de Google Play ahorra espacio en la imagen del sistema, pero aumenta el tiempo de primer inicio. Tenga en cuenta que esta opción no tiene ningún efecto en las aplicaciones prediseñadas definidas en Android.bp .

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 y superior)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER especifica el filtro del compilador predeterminado para aplicaciones dexpreopted. Estas aplicaciones están definidas en Android.bp o include $(BUILD_PREBUILT) especificado en su Android.mk . Si no se especifica, el valor predeterminado es speed-profile o verify si el valor no está especificado y no se proporciona un perfil.

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (desde Android 8 MR1)

    • Al habilitar WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts solo la ruta de clase de inicio y los archivos jar del servidor del sistema.

  • LOCAL_DEX_PREOPT

    • Dexpreopt también se puede habilitar o deshabilitar en una aplicación individual especificando la opción LOCAL_DEX_PREOPT en la definición del módulo. Esto puede ser útil para deshabilitar dexpreopt de aplicaciones que pueden recibir inmediatamente actualizaciones de Google Play, ya que las actualizaciones dejarían obsoleto el código dexpreopt en la imagen del sistema. Esto también es útil para ahorrar espacio en las OTA de actualización de versiones principales porque es posible que los usuarios ya tengan versiones más nuevas de aplicaciones en la partición de datos.

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

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • Pasa opciones a dex2oat para controlar cómo se compila la imagen de arranque. Se puede utilizar para especificar listas de clases de imágenes personalizadas, listas de clases compiladas y filtros del compilador.

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

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

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

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

  • PRODUCT_DEXPREOPT_SPEED_APPS (desde Android 8)

    • Lista de aplicaciones que se han identificado como principales para los productos y que es deseable compilar con el filtro del compilador de speed . Por ejemplo, las aplicaciones persistentes como SystemUI tienen la oportunidad de utilizar la compilación guiada por perfiles solo en el siguiente reinicio, por lo que podría ser mejor para el producto tener estas aplicaciones siempre compiladas con AOT.

  • PRODUCT_SYSTEM_SERVER_APPS (desde Android 8)

    • Lista de aplicaciones que carga el servidor del sistema. Estas aplicaciones se compilan de forma predeterminada con el filtro del compilador de speed .

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (desde Android 8)

    • Si se debe incluir una versión de depuración de ART en el dispositivo. De forma predeterminada, esto está habilitado para compilaciones de depuración de usuario y de ingeniería. El comportamiento se puede anular estableciendo explícitamente la opción en true o false .

    De forma predeterminada, el dispositivo utiliza la versión sin depuración ( libart.so ). Para cambiar, establezca 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, se puede especificar WITH_DEXPREOPT_PIC para habilitar el código independiente de la posición (PIC). Con esto, no es necesario reubicar el código compilado de la imagen desde /system a /data/dalvik-cache , ahorrando espacio en la partición de datos. Sin embargo, hay un ligero impacto en el tiempo de ejecución porque deshabilita una optimización que aprovecha el código dependiente de la posición. Normalmente, los dispositivos que quieran ahorrar espacio en /data deberían habilitar la compilación PIC.

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

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (hasta Android 7 MR1)

    • Esta opción fue reemplazada por WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY que también preopta 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, se usa el filtro del compilador de speed-profile , o se usa el filtro del compilador speed si no se proporciona un perfil.
    • (Android 13 y versiones anteriores) Si no se especifica, se utiliza el filtro del compilador speed .
    • Si se establece en speed , se utiliza 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 para verify , se utiliza 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 archivos JAR cargados por el servidor del sistema. Los JAR se compilan con el filtro del compilador especificado por PRODUCT_SYSTEM_SERVER_COMPILER_FILTER .

    • (Obligatorio) PRODUCT_SYSTEM_SERVER_JARS : Lista de JAR de classpath del servidor del sistema en la plataforma (es decir, como parte de SYSTEMSERVERCLASSPATH ). Es necesario agregar JAR de classpath del servidor del sistema a esta lista. Si no se agregan los JAR de classpath del servidor del sistema a la lista, esos JAR no se cargarán.
    • (Obligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS : Lista de JAR de classpath del servidor del sistema entregados con APEX (es decir, como parte de SYSTEMSERVERCLASSPATH ). El formato es <apex name>:<jar name> . Es necesario agregar JAR de classpath del servidor del sistema APEX a esta lista. Si no se agregan los JAR de ruta de clases del servidor del sistema APEX a esta lista, esos JAR no se cargarán.
    • (Opcional, Android 13 y versiones anteriores) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS : lista de archivos JAR que el servidor del sistema carga dinámicamente utilizando cargadores de clases separados (a través de SystemServiceManager.startServiceFromJar ). No es necesario agregar archivos JAR de servidor de sistema independiente a esta lista, pero se recomienda encarecidamente porque hace que los archivos JAR se compilen y, por lo tanto, tengan un buen rendimiento en tiempo de ejecución.
    • (obligatorio, desde Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS : Lista de JAR entregados con APEX que el servidor del sistema carga dinámicamente utilizando cargadores de clases separados (es decir, a través de SystemServiceManager.startServiceFromJar o declarado como <apex-system-service> ). El formato es <apex name>:<jar name> . Es necesario agregar JAR del servidor del sistema APEX independiente a esta lista. Si no se agregan los archivos JAR del servidor del sistema APEX independiente a esta lista, se producirá un error de arranque.

    Configuración de classpath de arranque

    La lista de clases precargadas es una lista de clases que Zygote inicializa al inicio. Esto evita que cada aplicación 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 archivo de lista de clases precargadas se encuentra en frameworks/base/config/preloaded-classes de forma predeterminada y contiene una lista adaptada al uso típico del teléfono. Esto podría ser diferente para otros dispositivos, como los portátiles, y debe ajustarse en consecuencia. Tenga cuidado al ajustar esto; agregar demasiadas clases desperdicia memoria cuando se cargan clases no utilizadas. Agregar muy pocas clases obliga a cada aplicación a tener su propia copia, lo que nuevamente desperdicia memoria.

    Uso de ejemplo (en el device.mk del producto):

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

    Nota: Debe colocar esta línea antes de heredar cualquier archivo MAKE de configuración del producto que obtenga el predeterminado de build/target/product/base.mk .

    Configuración de tiempo de ejecución

    Opciones JIT

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

    • dalvik.vm.usejit : si JIT está habilitado o no.
    • dalvik.vm.jitinitialsize (64K predeterminado): la capacidad inicial del caché de código. El caché de código se GC periódicamente y aumentará si es necesario.
    • dalvik.vm.jitmaxsize (predeterminado 64M): la capacidad máxima del caché de código.
    • dalvik.vm.jitthreshold (predeterminado 10000): el umbral que el contador de "calor" de un método debe pasar para que el método se compile JIT. El contador de "calor" es una métrica interna del tiempo de ejecución. Incluye la cantidad de llamadas, bifurcaciones hacia atrás y otros factores.
    • dalvik.vm.usejitprofiles (hasta Android 13): si los perfiles JIT están habilitados o no; esto puede usarse incluso si dalvik.vm.usejit es falso. Tenga en cuenta que si esto es falso, el speed-profile del filtro del compilador no compila AOT ningún método y es equivalente a verify . Desde Android 14, los perfiles JIT siempre están habilitados y no se pueden desactivar.
    • dalvik.vm.jitprithreadweight (predeterminado en dalvik.vm.jitthreshold / 20): el peso de las "muestras" JIT (consulte jitthreshold) para el subproceso de la interfaz de usuario de la aplicación. Úselo para acelerar la compilación de métodos que afectan directamente la experiencia de los usuarios al interactuar con la aplicación.
    • dalvik.vm.jittransitionweight (predeterminado en dalvik.vm.jitthreshold / 10): el peso de la invocación del método que realiza la transición entre el código de compilación y el intérprete. Esto ayuda a garantizar que los métodos involucrados se compilen para minimizar las transiciones (que son costosas).

    Opciones de avena Dex2

    Estas opciones afectan la compilación en el dispositivo (también conocida como dexopt ), y algunas de ellas también afectan a dexpreopt, mientras que las opciones analizadas en la sección de configuración de ROM del sistema anterior solo afectan 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 (ver a continuación) que se usarán para las imágenes de arranque.
    • dalvik.vm.boot-dex2oat-threads / dalvik.vm.boot-dex2oat-cpu-set :
      • (hasta Android 11) La cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) que se usarán durante el tiempo de arranque para todo lo que no sea imágenes de arranque.
      • (desde Android 12) La cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) que se usarán durante el tiempo de arranque para todo, incluidas las imágenes de arranque.
        • Específicamente, desde Android 14, esto corresponde a la clase de prioridad PRIORITY_BOOT en ART Service.
    • dalvik.vm.restore-dex2oat-threads / dalvik.vm.restore-dex2oat-cpu-set :
      • (desde Android 11, hasta Android 13) La cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) que se usarán para restaurar desde la copia de seguridad en la nube.
      • (desde Android 14) La cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) que se usarán para todo lo que sea más sensible a la latencia de lo normal, incluida la restauración desde la copia de seguridad en la nube.
        • Específicamente, esto corresponde a la clase de prioridad PRIORITY_INTERACTIVE_FAST en el Servicio ART.
    • dalvik.vm.background-dex2oat-threads / dalvik.vm.background-dex2oat-cpu-set (desde Android 14): la cantidad de subprocesos y el conjunto de núcleos de CPU (ver a continuación) para usar en segundo plano.
      • Específicamente, esto corresponde a la clase de prioridad PRIORITY_BACKGROUND en ART Service.
    • 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 como una lista de identificadores de CPU separados por comas. Por ejemplo, para ejecutar dex2oat en los núcleos de CPU 0-3, configure:

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

    Al configurar las propiedades de afinidad de la CPU, recomendamos hacer coincidir la propiedad correspondiente para la cantidad de subprocesos dex2oat para que coincida con la cantidad de CPU seleccionadas para evitar memoria innecesaria y contención de E/S:

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

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

    Los perfiles de tareas admitidos son:

    • Dex2OatBackground (desde Android 14) (por defecto hereda Dex2OatBootComplete ): Controla los recursos a utilizar en segundo plano.
      • Específicamente, esto corresponde a la clase de prioridad PRIORITY_BACKGROUND en ART Service.
    • Dex2OatBootComplete :
      • (hasta Android 13) Controla el recurso que se utilizará para todo después del arranque.
      • (desde Android 14) Controla el recurso que se utilizará para todo después del arranque y no en segundo plano.
        • Específicamente, esto corresponde a la clase de prioridad PRIORITY_INTERACTIVE_FAST y PRIORITY_INTERACTIVE en ART Service.

    Cuando se especifican tanto las propiedades del sistema como los perfiles de tarea, ambos entran en vigor.

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

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

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

    Opciones para controlar el filtro del compilador:

    • dalvik.vm.image-dex2oat-filter (hasta Android 11): el filtro del compilador para imágenes de arranque. Desde Android 12, el filtro del compilador para imágenes de arranque siempre es speed-profile y no se puede cambiar.
    • dalvik.vm.systemservercompilerfilter (desde Android 13): el filtro del compilador para el servidor del sistema. Consulte PRODUCT_SYSTEM_SERVER_COMPILER_FILTER .
    • dalvik.vm.systemuicompilerfilter (desde Android 13): el filtro del compilador para el paquete de interfaz de usuario 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. Consulte Configuración del servicio ART para Android 14 y versiones posteriores, o Configuración del administrador de paquetes para Android 13 y versiones posteriores.

    Otras opciones para controlar la compilación de todo lo que no sean imágenes de arranque:

    • dalvik.vm.dex2oat-very-large (desde Android 7.1): tamaño mínimo total del archivo dex en bytes para deshabilitar la compilación AOT.
    • dalvik.vm.dex2oat-swap (desde Android 7.1) (predeterminado: verdadero): permite usar un archivo de intercambio para dex2oat. Esto puede ayudar a evitar fallas por falta de memoria. Tenga en cuenta que incluso si esta opción está activada, dex2oat solo usará un archivo de intercambio bajo ciertas condiciones, como cuando la cantidad de 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 tiempo de ejecución genere un perfil de la aplicación, la primera vez que 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: falso): si se debe utilizar la versión de 64 bits de dex2oat.
    • dalvik.vm.bgdexopt.new-classes-percent (desde Android 12) (predeterminado: 20): el porcentaje mínimo, entre 0 y 100, de nuevas clases en un perfil para activar una recompilación. Solo se aplica a la compilación guiada por perfiles ( speed-profile ), generalmente durante el dexopt en segundo plano. Tenga en cuenta que también hay un umbral de al menos 50 clases nuevas además del umbral de porcentaje, y no es configurable.
    • dalvik.vm.bgdexopt.new-methods-percent (desde Android 12) (predeterminado: 20): el porcentaje mínimo, entre 0 y 100, de nuevos métodos en un perfil para activar una recompilación. Solo se aplica a la compilación guiada por perfiles ( speed-profile ), generalmente durante el dexopt en segundo plano. Tenga en cuenta que también hay un umbral de al menos 100 métodos nuevos además del umbral de porcentaje, y no es configurable.
    • dalvik.vm.dex2oat-max-image-block-size (desde Android 10) (predeterminado: 524288) Tamaño máximo de bloque sólido para imágenes comprimidas. Una imagen grande se divide en un conjunto de bloques sólidos de modo que ningún bloque sea mayor que el tamaño máximo.
    • dalvik.vm.dex2oat-resolve-startup-strings (desde Android 10) (predeterminado: verdadero) Si es verdadero, hace que dex2oat resuelva todas las cadenas constantes a las que se hace referencia desde los métodos marcados como "inicio" en el perfil.
    • debug.generate-debug-info (predeterminado: falso) Si se genera o no información de depuración para la depuración nativa, como información de desenrollado de pila, símbolos ELF y secciones enanas.
    • dalvik.vm.dex2oat-minidebuginfo (desde Android 9) (predeterminado: verdadero) Si se genera o no una cantidad mínima de información de depuración comprimida con LZMA necesaria para imprimir seguimientos.

    Opciones de servicio ART

    Desde Android 14, ART Service se encarga de la compilación AOT en el dispositivo para aplicaciones (también conocida como dexopt). Para obtener información sobre la configuración del Servicio ART, consulte Configuración del Servicio ART .

    Opciones del administrador de paquetes

    Antes de Android 14, el administrador de paquetes manejaba la compilación AOT en el dispositivo para aplicaciones (también conocida como dexopt). Para obtener información sobre cómo configurar el administrador de paquetes para dexopt, consulte Configuración del administrador de paquetes .

    Configuración específica A/B

    configuración de ROM

    A partir de Android 7.0, los dispositivos pueden usar dos particiones del sistema para habilitar las 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 no utilizada. Luego se copian a la partición de datos en el primer arranque.

    Uso de ejemplo (en device-common.mk ):

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

    Y en BoardConfig.mk del dispositivo:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    Tenga en cuenta que el código de classpath de arranque, el código del servidor del sistema y las aplicaciones principales específicas del producto siempre se compilan en la partición del sistema. De forma predeterminada, todas las demás aplicaciones se compilan en la segunda partición del sistema no utilizada. Esto se puede controlar con SYSTEM_OTHER_ODEX_FILTER , que tiene un valor por defecto de:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    Antecedentes OTA dexopt

    En dispositivos habilitados para A/B, las aplicaciones se pueden compilar en segundo plano antes del reinicio con la nueva imagen del sistema. Consulte Compilación de aplicaciones en segundo plano para incluir opcionalmente el script de compilación y los archivos binarios en la imagen del sistema. El filtro de compilación utilizado para esta compilación se controla con:

    pm.dexopt.ab-ota=speed-profile

    Recomendamos utilizar speed-profile para aprovechar la compilación guiada por perfiles y ahorrar almacenamiento.

    Opciones de JDWP

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

    Para depurar una aplicación no depurable en una compilación de depuración de usuario, habilite JDWP ejecutando el siguiente comando:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Para dispositivos con Android 13 y versiones anteriores, el tiempo de ejecución crea subprocesos JDWP para aplicaciones depurables y no depurables en compilaciones de depuración de usuario. Esto significa que es posible adjuntar un depurador o perfilar cualquier aplicación en compilaciones de depuración de usuario.