Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

Configurar ART

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

Consulta ART y Dalvik y el formato ejecutable de Dalvik para trabajar con ART. Consulta Cómo verificar el comportamiento de la app en el tiempo de ejecución de Android (ART) para asegurarte de que tus apps funcionen correctamente.

Cómo funciona ART

ART usa la compilación anticipada (AOT) y, a partir de Android 7, usa una combinación híbrida de compilación AOT, compilación just-in-time (JIT) y de interpretación, y la compilación AOT puede estar guiada por perfiles. La combinación de todos estos modos de ejecución se puede configurar y se analizará en esta sección. A modo de ejemplo, los dispositivos Pixel están configurados para trabajar en el siguiente flujo:

Una aplicación se instala inicialmente con un archivo de metadatos de dex (.dm) que distribuye Play Store, que contiene un perfil de nube. ART compila de forma anticipada los métodos que se enumeran en el perfil de la nube. O bien, si la aplicación se instala sin un archivo de metadatos dex, no se realiza ninguna compilación de AOT.
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, los que se ejecutan con frecuencia se compilan con JIT. ART genera un perfil local según la ejecución y lo combina con el perfil de nube (si existe uno).
Cuando el dispositivo está inactivo y en carga, se ejecuta un daemon de compilación para volver a compilar la aplicación según el perfil combinado generado durante las primeras ejecuciones.
En las ejecuciones posteriores de la aplicación, ART usa los artefactos generados por el daemon de compilación, que contienen más código compilado por AOT, en comparación con los que se generaron durante la compilación. Los métodos que no se compilan con AOT aún se interpretan o se compilan con JIT. ART actualiza la instalación del perfil según la ejecución, y el perfil se recuperará en las ejecuciones posteriores del daemon de compilación.

ART comprende un compilador (la herramienta dex2oat) y un entorno de ejecución (libart.so) que se carga durante el inicio. 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, sus extensiones y nombres están sujetos a cambios en las versiones, pero a partir de la versión de Android 8, se generan los siguientes 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 los métodos del APK.
.art (optional) contiene representaciones internas de ART de algunas cadenas y clases que se enumeran en el APK, que se usan para acelerar el inicio de la app.

Opciones de compilación

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

Configuración de la ROM del sistema: Es el código que se compila en AOT cuando se compila una imagen del sistema.
Configuración del entorno de ejecución: Indica cómo ART compila y ejecuta apps en un dispositivo.

Filtros del compilador

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

verify: Ejecuta solo la verificación de código DEX (sin compilación AOT).
quicken: (Android 11 o versiones anteriores) Ejecuta la verificación de código DEX y optimiza algunas instrucciones DEX para obtener un mejor rendimiento del intérprete.
speed: Ejecuta la verificación de código DEX y compila todos los métodos con AOT. No optimiza la carga de clases para ninguna clase.
speed-profile: Ejecuta la verificación de código DEX, compila los métodos de AOT que se enumeran en el perfil y optimiza las cargas de clase para las clases del perfil.

Configuración de la ROM del sistema

Las bibliotecas y apps preinstaladas se compilan con AOT cuando se compila una imagen del sistema. Este proceso se denomina dexpreopt. Estos archivos compilados se pueden usar, siempre que todas las dependencias permanezcan sin cambios, en particular, la ruta de acceso de clases de inicio.

Nota: Si el dispositivo recibe actualizaciones del módulo del sistema, es muy probable que la ruta de acceso de inicio cambie en la próxima actualización, lo que hará que todos los archivos de dexpreopt dejen de estar disponibles.

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

Código de classpath de inicio: Se compila con el filtro del compilador speed-profile de forma predeterminada.
Código del servidor del sistema (consulta PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS y PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS más adelante en este documento):
- (Android 14 y versiones posteriores) Se compila con el filtro del compilador speed-profile de forma predeterminada o con el filtro del compilador speed si no se proporciona un perfil.
- (Android 13 y versiones anteriores) Se compila con el filtro del compilador speed de forma predeterminada.
Se puede configurar a través de PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (consulta más adelante en este documento).
Apps principales específicas del producto (consulta PRODUCT_DEXPREOPT_SPEED_APPS más adelante en este documento): Se compilan con el filtro del compilador speed de forma predeterminada.
Todas las demás apps: Se compilan con el filtro del compilador speed-profile de forma predeterminada o con el filtro del compilador verify si no se proporciona un perfil.
Se puede configurar a través de PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (consulta 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)

Habilitar DONT_DEXPREOPT_PREBUILTS evita que los compilados previamente se dexpreopten. Estas son apps que tienen include $(BUILD_PREBUILT) especificado en su Android.mk. Omitir el dexpreopt de las apps precompiladas que es probable que se actualicen a través de Google Play ahorra espacio en la imagen del sistema, pero aumenta el tiempo de inicio por primera vez. Ten en cuenta que esta opción no tiene efecto en las apps precompiladas definidas en Android.bp.

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 y versiones posteriores)

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

WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (desde Android 8 MR1)

Habilitar WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts solo la ruta de acceso de compilación de arranque y los archivos JAR del servidor del sistema.

LOCAL_DEX_PREOPT

Dexpreopt también se puede habilitar o inhabilitar en una app individual si se especifica la opción LOCAL_DEX_PREOPT en la definición del módulo. Esto puede ser útil para inhabilitar dexpreopt de apps que pueden recibir actualizaciones de Google Play de inmediato, ya que las actualizaciones harían que el código dexpreopt en la imagen del sistema quede obsoleto. Esto también es útil para ahorrar espacio en las actualizaciones OTA de versiones principales, ya que es posible que los usuarios ya tengan versiones más recientes de las apps en la partición de datos.

LOCAL_DEX_PREOPT admite los valores true o false para habilitar o inhabilitar dexpreopt, respectivamente. Además, se puede especificar nostripping si dexpreopt no debe quitar el archivo classes.dex del archivo APK o JAR. Por lo general, este archivo se quita, ya que ya no es necesario 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 compila la imagen de inicio. Se puede usar 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, excepto la imagen de inicio.

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 establece en el archivo device.mk de un producto a través de $(call add-product-dex-preopt-module-config,<modules>,<option>), en el que <modules> es una lista de nombres LOCAL_MODULE y LOCAL_PACKAGE para archivos JAR y APK, respectivamente.

PRODUCT_DEXPREOPT_SPEED_APPS (desde Android 8)

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

PRODUCT_SYSTEM_SERVER_APPS (desde Android 8)

Es la lista de apps que carga el servidor del sistema. Estas apps se compilan de forma predeterminada con el filtro del compilador speed.

PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (desde Android 8)

Indica si se debe incluir una versión de depuración de ART en el dispositivo. De forma predeterminada, está habilitado para las compilaciones de userdebug y eng. Para anular el comportamiento, configura la opción de forma explícita como true o false.

De forma predeterminada, el dispositivo usa la versión sin depuración (libart.so). Para cambiar, 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 6.0.1, se puede especificar WITH_DEXPREOPT_PIC para habilitar el código independiente de la posición (PIC). Con esto, el código compilado de la imagen no tiene que reubicarse de /system a /data/dalvik-cache, lo que ahorra espacio en la partición de datos. Sin embargo, hay un ligero impacto en el tiempo de ejecución porque inhabilita una optimización que aprovecha el código dependiente de la posición. Por lo general, los dispositivos que desean ahorrar espacio en /data deben habilitar 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 optimiza previamente los archivos 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 speed-profile o el filtro del compilador speed si no se proporciona un perfil.
(Android 13 y versiones anteriores) Si no se especifica, se usa el filtro del compilador speed.
Si se establece en speed, se usa el filtro del compilador speed.
Si se establece en speed-profile, se usa el filtro del compilador speed-profile o el filtro del compilador verify si no se proporciona un perfil.
Si se establece 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 archivos JAR que carga el servidor del sistema. Los archivos JAR se compilan con el filtro de compilador que especifica PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.

PRODUCT_SYSTEM_SERVER_JARS (obligatorio): Es la lista de archivos JAR de la ruta de clase del servidor del sistema en la plataforma (es decir, como parte de SYSTEMSERVERCLASSPATH). Es obligatorio agregar archivos JAR de la ruta de clase del servidor del sistema a esta lista. Si no agregas los archivos JAR de la ruta de clase del servidor del sistema a la lista, no se cargarán esos archivos JAR.
(Obligatorio) PRODUCT_APEX_SYSTEM_SERVER_JARS: Es la lista de archivos JAR de la ruta de clase del servidor del sistema que se entrega con APEX (es decir, como parte de SYSTEMSERVERCLASSPATH). El formato es <apex name>:<jar name>. Es obligatorio agregar los archivos JAR del classpath del servidor del sistema APEX a esta lista. Si no agregas los archivos JAR de la ruta de clase del servidor del sistema APEX a esta lista, no se cargarán esos archivos JAR.
(Opcional, Android 13 y versiones anteriores) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: Es la lista de archivos JAR que el servidor del sistema carga de forma dinámica con cargadores de clases independientes (a través de SystemServiceManager.startServiceFromJar). No es necesario agregar archivos JAR del servidor del sistema independientes a esta lista, pero se recomienda hacerlo porque compila los archivos JAR 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: Es la lista de archivos JAR entregados con APEX que el servidor del sistema carga de forma dinámica con cargadores de clases independientes (es decir, a través de SystemServiceManager.startServiceFromJar o declarados como <apex-system-service>). El formato es <apex name>:<jar name>. Es obligatorio agregar archivos JAR del servidor del sistema APEX independientes a esta lista. Si no agregas archivos JAR de servidor del sistema APEX independientes a esta lista, se producirá un error de inicio.

Configuración del classpath de arranque

La lista de clases cargadas previamente es una lista de clases que Zygote inicializa en el inicio. Esto 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 archivo de lista de clases precargadas se encuentra en frameworks/base/config/preloaded-classes de forma predeterminada y contiene una lista que está ajustada para el uso típico del teléfono. Esto puede ser diferente para otros dispositivos, como los wearables, y se debe ajustar según corresponda. Ten cuidado cuando realices la configuración. Si agregas demasiadas clases, se desperdiciará la memoria cuando se carguen las clases que no se usen. Si agregas demasiadas clases, cada app deberá tener su propia copia, lo que, nuevamente, 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 de heredar cualquier archivo de configuración de make del producto que obtenga el predeterminado de 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 cuando el compilador JIT de ART está disponible.

dalvik.vm.usejit: Indica si el JIT está habilitado o no.
dalvik.vm.jitinitialsize (64K predeterminado): Es la capacidad inicial de la caché de código. La caché de código realizará la GC con regularidad y aumentará si es necesario.
dalvik.vm.jitmaxsize (64 M de forma predeterminada): Es la capacidad máxima de la caché de código.
dalvik.vm.jitthreshold (predeterminado 10000): Es el umbral que debe pasar el contador de "popularidad" de un método para que este se compile con JIT. El contador de "popularidad" es una métrica interna del entorno de ejecución. Incluye la cantidad de llamadas, las ramas hacia atrás y otros factores.
dalvik.vm.usejitprofiles (hasta Android 13): Indica si los perfiles de JIT están habilitados o no. Se puede usar incluso si dalvik.vm.usejit es falso. Ten en cuenta que, si esto es falso, el filtro del compilador speed-profile no compila ningún método con AOT y es equivalente a verify. A partir de Android 14, los perfiles de JIT siempre están habilitados y no se pueden desactivar.
dalvik.vm.jitprithreadweight (el valor predeterminado es dalvik.vm.jitthreshold / 20): Es el peso de los "muestras" de JIT (consulta jitthreshold) para el subproceso de IU de la aplicación. Úsalo para acelerar la compilación de métodos que afectan directamente la experiencia de los usuarios cuando interactúan con la app.
dalvik.vm.jittransitionweight (el valor predeterminado es dalvik.vm.jitthreshold / 10): Es el peso de la invocación de método que realiza la transición entre el código de compilación y el intérprete. Esto ayuda a asegurarse 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 a dexpreopt, mientras que las opciones que se analizaron en la sección Configuración de la 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): Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán para las imágenes de inicio.
dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
- (hasta Android 11) Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán durante el tiempo de inicio para todo lo que no sean imágenes de inicio.
- (desde Android 12) Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán durante el tiempo de inicio para todo, incluidas las imágenes de inicio.
  - Específicamente, desde Android 14, esto corresponde a 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) Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán para restablecer desde la copia de seguridad en la nube.
- (desde Android 14) Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán para todo lo que sea más sensible a la latencia de lo normal, incluido el restablecimiento 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 (desde Android 14): Es la cantidad de subprocesos y el conjunto de núcleos de CPU (consulta a continuación) que se usarán en segundo plano.
- Específicamente, esto corresponde a la clase de prioridad PRIORITY_BACKGROUND en el servicio de ART.
dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: Es la cantidad de subprocesos y el conjunto de núcleos de CPU que se usarán para todo lo demás.

Un conjunto de núcleos de CPU se debe especificar como una lista de IDs de CPU separados por comas. Por ejemplo, para ejecutar dex2oat en los núcleos de CPU del 0 al 3, establece lo siguiente:

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

Cuando configures las propiedades de afinidad de la CPU, te recomendamos que coincidas con la propiedad correspondiente para la cantidad de subprocesos de dex2oat para que coincida con la cantidad de CPUs seleccionadas para evitar la contención de memoria y E/S innecesarias:

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 el uso de recursos de dex2oat (consulta Capa de abstracción de cgroups).

Los perfiles de tareas compatibles son los siguientes:

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

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

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 del montón para las imágenes de inicio.
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 del montón para todo lo demás.

No se deben reducir las opciones que controlan el tamaño inicial y máximo del montón para dex2oat, 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): Es el filtro del compilador para imágenes de inicio. A partir de Android 12, el filtro del compilador para las imágenes de inicio siempre es speed-profile y no se puede cambiar.
dalvik.vm.systemservercompilerfilter (desde Android 13): Es el filtro del compilador para el servidor del sistema. Consulta PRODUCT_SYSTEM_SERVER_COMPILER_FILTER.
dalvik.vm.systemuicompilerfilter (desde Android 13): Es el filtro del compilador para el paquete de la IU del sistema.
dalvik.vm.dex2oat-filter (hasta Android 6): Es el filtro del compilador para todo lo demás.
pm.dexopt.<reason> (desde Android 7): Es el filtro del compilador para todo lo demás. Consulta Configuración del servicio de ART para Android 14 y versiones posteriores, o Configuración del Administrador de paquetes para Android 13 y versiones anteriores.

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

dalvik.vm.dex2oat-very-large (desde Android 7.1): Es el tamaño mínimo total del archivo DEX en bytes para inhabilitar 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. Ten en cuenta que, incluso si esta opción está activada, dex2oat solo usará un archivo de intercambio en 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): Es el tiempo mínimo de espera antes de que el entorno de ejecución genere un perfil de la aplicación, la primera vez que se inicia.
dalvik.vm.ps-min-save-period-ms (desde Android 12): Es el tiempo mínimo que se debe esperar 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 (desde Android 12) (predeterminado: 20): Es el porcentaje mínimo, entre 0 y 100, de clases nuevas en un perfil para activar una nueva compilación. Solo se aplica a la compilación guiada por perfiles (speed-profile), por lo general, durante el dexopt en segundo plano. Ten en cuenta que también hay un umbral de al menos 50 clases nuevas además del umbral de porcentaje, y no se puede configurar.
dalvik.vm.bgdexopt.new-methods-percent (desde Android 12) (predeterminado: 20): Es el porcentaje mínimo, entre 0 y 100, de métodos nuevos en un perfil para activar una nueva compilación. Solo se aplica a la compilación guiada por perfiles (speed-profile), por lo general, durante el dexopt en segundo plano. Ten en cuenta que también hay un umbral de al menos 100 métodos nuevos, además del umbral de porcentaje, y no se puede configurar.
dalvik.vm.dex2oat-max-image-block-size (desde Android 10) (predeterminado: 524288) es el 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 métodos marcados como "inicio" en el perfil.
debug.generate-debug-info (predeterminado: "false") Indica si se debe generar o no información de depuración para la depuración nativa, como información de desenredo de pila, símbolos ELF y secciones enanas.
dalvik.vm.dex2oat-minidebuginfo (desde Android 9) (predeterminado: verdadero) Indica si se debe generar o no una cantidad mínima de información de depuración comprimida en LZMA necesaria para imprimir seguimientos de pila.

Opciones del servicio de ART

Configuración del servicio de ART

Opciones del administrador de paquetes

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 las actualizaciones del sistema A/B. Para ahorrar en el tamaño de la partición del sistema, los archivos preopcionados se pueden instalar en la segunda partición del sistema que no se usa. Luego, se copian en la partición de datos durante 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 acceso de clases de inicio, el código del servidor del sistema y las apps principales específicas del producto siempre se compilan en la partición del sistema. De forma predeterminada, todas las demás apps se compilan en la segunda partición del sistema que no se usa. Esto se puede controlar con SYSTEM_OTHER_ODEX_FILTER, que tiene un valor predeterminado de:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

Dexopt OTA en segundo plano

En dispositivos habilitados para A/B, las aplicaciones se pueden compilar en segundo plano antes del reinicio con la nueva imagen del sistema. Consulta Compilación de apps en segundo plano para incluir de forma opcional la secuencia de comandos de compilación y los objetos binarios en la imagen del sistema. 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 usar speed-profile para aprovechar la compilación guiada por perfiles y ahorrar en almacenamiento.

Opciones de JDWP

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

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

  adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot

Nota: Configurar la propiedad persist.debug.dalvik.vm.jdwp.enabled en 1 no hace que las apps sean depurables, solo permite que se conecte un depurador al proceso.