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.
Switch to English

Tiempo de ejecución

El módulo de tiempo de ejecución ( com.android.runtime.release.apex ) es un módulo APEX para tiempos de ejecución de Android nativos y administrados. El módulo incluye los siguientes componentes:

  • ARTE
  • Biónico
  • Biblioteca central administrada (nuevo en Android 10)
  • Bibliotecas de UCI
  • libnativebridge
  • libnativehelper
  • libnativeloader

El módulo Runtime se genera al compilar Android y contiene los artefactos de compilación de sus proyectos constituyentes. Está estrechamente relacionado con el módulo Conscrypt ( com.android.conscrypt.apex ) y el módulo Time Zone Data ( com.android.tzdata.apex ), también nuevo en Android 10.

Cambios en Android Runtime (ART)

En Android 10, el sistema de compilación ART crea el módulo Runtime en dos variantes: lanzamiento y depuración (contiene herramientas adicionales de diagnóstico y depuración). La versión de lanzamiento se instala en user compilaciones de user y la versión de depuración se instala en las userdebug de userdebug y eng . Cuando se inicia un dispositivo, apexd monta el módulo Runtime en /apex/com.android.runtime .

En el módulo, la ruta de clases de arranque se divide entre clases como Managed Core Library, clases en otros módulos (como Conscrypt y Media) y clases en la partición del sistema (como framework.jar ). Si se actualiza un módulo, dex2oat JIT compila clases de arranque en módulos.

Android 10 incluye los siguientes cambios de API:

  • Una nueva API para el soporte de archivos DEX proporciona una interfaz estable entre el código del sistema (como el desbobinador de pila) y ART.
  • Se utiliza una nueva API como capa de abstracción de plataforma (PAL) específica de ART con el sistema. El elemento del sistema ( libartpalette-system.so ) expone la funcionalidad del sistema de la que depende ART y es accesible a través de una biblioteca cliente ( libartpalette.so ), que carga la biblioteca del sistema instalada en el dispositivo.

Android 10 también refactoriza las rutas de algunos binarios ART, moviendo los siguientes binarios de /system/bin al módulo Runtime: dalvikvm , dalvikvm32 , dalvikvm64 , dex2oat , dexdiag , dexdump , dexlist , dexoptanalyzer , oatdump y profman . Por compatibilidad, el refactor incluye enlaces simbólicos en /system/bin .

Cambios biónicos

tzcode libc utiliza datos de zona horaria proporcionados por el módulo Runtime ( /apex/com.android.runtime/etc/tz/ ) y el módulo Time Zone Data ( /apex/com.android.tzdata/etc/tz/ ). tzcode prioriza los datos de las actualizaciones de zona horaria basadas en APK sobre las actualizaciones de zona horaria basadas en APEX (proporcionadas por el módulo de datos de zona horaria) y tzcode datos de /system .

libc usa una nueva biblioteca ( libandroidicu ) en lugar de libicuuc / libicui18n . Para obtener más información, consulte Managed Core Library .

Finalmente, las bibliotecas compartidas de Bionic y las rutas del enlazador dinámico ahora son enlaces simbólicos (también se aplica a las variantes de 64 bits). Específicamente:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

Cambios en la secuencia de arranque

Para admitir el módulo Runtime, Android 10 actualiza la secuencia de inicio a lo siguiente:

  1. init prepara el bootstrap y los espacios de nombres de montaje predeterminados. Se monta un tmpfs en /apex y el tipo de propagación del punto de montaje se establece en private .
  2. apexd inicia en modo bootstrap, antes que cualquier otro proceso. Activa los archivos APEX en /system/apex y los monta en el espacio de nombres de montaje de arranque.
  3. Se apexd procesos previos al apexd . Estos procesos se encuentran en el espacio de nombres de montaje de arranque y se proporcionan con bibliotecas de archivos APEX del sistema.
  4. /data montajes de /data . init cambia al espacio de nombres de montaje predeterminado e inicia apexd como un demonio.
  5. apexd escanea tanto / data/apex como /system/apex y activa los archivos APEX más recientes en esos directorios. Los archivos APEX activados en esta fase se montan solo en los espacios de nombres predeterminados y no son visibles para los procesos anteriores a apexd .

Biblioteca central administrada

Managed Core Library es una colección de código de bajo nivel, actualizable y administrado ( dex ejecutado por Android Runtime) que antes se conocía como libcore . En Android 10, Managed Core Library incluye varios proyectos de Git (además de platform/libcore/ ), y el nuevo término se refiere a la colección de código.

La biblioteca principal administrada la proporcionan los módulos Runtime, Time Zone Data y Conscrypt y se basa en bibliotecas nativas presentes en el módulo Runtime, como libjavacore y libandroidicu . El código recopilado proviene de varios proyectos de Git, como libcore , apache-xml , boringssl , bouncycastle , conscrypt , expat , fdlibm , icu , okhttp , ziparchive y zlib . La biblioteca se divide entre varios archivos .jar en la ruta de clases de arranque (por ejemplo, core-oj.jar , core-libart.jar , conscrypt.jar , okhttp.jar , bouncycastle.jar y apache-xml.jar ); sin embargo, no incluye framework.jar o ext.jar .

Reembalaje de componentes

Android 10 bouncycastle/ empaquetar varios componentes ( bouncycastle/ , conscrypt/ , okhttp/ ) que se empaquetaron previamente en android.* Y com.android.* Mediante la manipulación de conscrypt/ okhttp/ . Estos componentes se vuelven a empaquetar mediante la transformación del código fuente para permitir que las anotaciones de Java se utilicen para los metadatos de la API.

API de plataforma central

La API de la plataforma central proporciona una API de código administrado estable para que la utilice el marco de Android, lo que permite que la biblioteca principal administrada se actualice al garantizar que todas las dependencias del marco se entiendan claramente. La API de la plataforma central:

  • Indica dependencias además de las API públicas del SDK. Para el contenido de la API, consulte libcore/mmodules/core_platform_api/ .
  • @libcore.api.CorePlatformApi explícitamente el código administrado con @libcore.api.CorePlatformApi . Para el código en libcore/ojluni/src/ , consulte las anotaciones en libcore/ojluni/annotations/mmodule/ ; para todos los demás proyectos, consulte los archivos fuente principales.

El sistema de compilación utiliza de forma predeterminada la API de la plataforma central al compilar los destinos de la plataforma de origen Java (es decir, en ausencia de "sdk_version:" en archivos .bp o "LOCAL_SDK_VERSION=" en archivos .mk ). Este valor predeterminado garantiza que el código del marco de trabajo de Android esté restringido al uso de API públicas y solo la API de la plataforma central (sin clases de implementación). Otros valores de sdk_version como "core_current" y "current" funcionan como siempre (solo permiten el uso de API de SDK públicas). El sistema de compilación también informa cambios en la superficie de la API de la plataforma central y evita que los destinos (fuera de un pequeño conjunto de excepciones) dependan de los componentes internos de la biblioteca central administrada.

El módulo Runtime realiza comprobaciones de acceso a los campos y métodos cubiertos por la API de la plataforma central. Las comprobaciones se realizan cuando el código de la plataforma accede a métodos en la API de la plataforma central. La propiedad del sistema persist.debug.dalvik.vm.core_platform_api_policy controla la política en torno a estas comprobaciones. Los valores de política válidos están enabled , disabled y just-warn . Para las compilaciones debug y eng, la política estándar es just-warn , que registra una advertencia cuando se detecta una infracción de la política. Para las compilaciones de usuarios, la política predeterminada está disabled y no se realiza ninguna acción. El módulo Runtime también realiza comprobaciones de la API de la plataforma central cuando el código nativo resuelve campos y métodos a través de la interfaz nativa de Java (JNI).

Android 10 también incluye numerosos cambios para simplificar las API, las dependencias en tiempo de ejecución y las dependencias en tiempo de compilación entre el marco de Android y la biblioteca central administrada.

Android 10 org.kxml2 empaquetar el analizador org.kxml2 en com.android.org.kxml2 .

Bibliotecas nativas

Android 10 refactoriza las bibliotecas nativas que son compatibles con Managed Core Library. Varias bibliotecas vinculadas dinámicamente (por ejemplo, libcrypto , libexpat y zlib ) que antes se compartían con otras partes de la plataforma ahora están duplicadas para que el módulo Runtime tenga sus propias copias cargadas en el espacio de nombres del vinculador en tiempo de ejecución. Las bibliotecas nativas vinculadas dinámicamente proporcionadas por el módulo Runtime se encuentran en /apex/com.android.runtime/{lib,lib64} .

Bibliotecas de UCI

El módulo Runtime incluye bibliotecas ICU (ICU4C e ICU4J) y datos asociados.

Android 10 incluye libandroidicu , una nueva biblioteca dinámica que hace que un subconjunto de funciones ICU4C esté disponible para el código del marco. Los símbolos del enlazador para libandroidicu son estables en todas las versiones de ICU (los símbolos terminan con _android lugar de _icu-version-number usado en libicuuc y libicui18n ). Sin embargo, para compatibilidad de aplicaciones, los símbolos libicuuc y libicui18n siguen estando disponibles. También para la compatibilidad de aplicaciones, el enlazador redirige rutas absolutas a bibliotecas de ICU en llamadas dlopen (), es decir, dlopen("/system/lib/libicuuc.so", ...) y dlopen("/system/lib/libicui18n.so", ...) , redirigir a las bibliotecas correspondientes en /apex/com.android.runtime/lib/ para aplicaciones con targetSdkVersion < 29 .

En tiempo de ejecución, el archivo de datos de ICU se instala en /apex/com.android.runtime/etc/icu/ . Para compatibilidad con la aplicación, Android 10 incluye un enlace simbólico desde la ubicación del archivo de datos de la UCI anterior ( /system/usr/icu/ ) a /apex/com.android.runtime/etc/icu .

Interacciones de conscrypt

Android 10 mueve Conscrypt, que es lógicamente parte de Managed Core Library, a su propio módulo APEX actualizable de forma independiente. Entre los módulos Conscrypt y Runtime, una nueva superficie API bidireccional indica dependencias además de las API públicas del SDK (para obtener más detalles, consulte libcore/mmodules/intracoreapi/ ). Los elementos de la API se anotan explícitamente con @libcore.api.IntraCoreApi .

El sistema de compilación verifica que el código de Conscrypt esté restringido a las API públicas y la API intranúcleo. Otras dependencias de Managed Core Library en Conscrypt se basan en la reflexión; el sistema de compilación registra dichas dependencias siempre que sea posible e informa todos los cambios en la superficie de la API.

Interacciones de datos de zona horaria

En Android 10, la arquitectura libcore, Runtime libcore e ICU4J / ICU4C utilizan datos de zona horaria proporcionados por el módulo Runtime ( /apex/com.android.runtime/etc/tz/ ) y el módulo Time Zone Data ( /apex/com.android.tzdata/etc/tz/ ). Estas bibliotecas:

Cambios varios

Android 10 mueve la API AsynchronousCloseMonitor de libnativehelper.so a libandroidio.so . La API está expuesta por AsynchronousCloseMonitor.h .

cambios libnativebridge

Android 10 mueve la biblioteca libnativebridge al módulo Runtime ya que esta biblioteca está estrechamente acoplada con libnativeloader y las bibliotecas Bionic C que forman parte del módulo Runtime.

cambios libnativehelper

En Android 10, el módulo Runtime hace que libnativehelper esté disponible para el código del sistema y los marcos, mientras que el código fuera del módulo Runtime se vincula con una API de stubs (solo C) para libnativehelper . La biblioteca libnativehelper incluye:

  • Un conjunto reducido de clases, métodos y campos JNI almacenados en caché.
  • Macros JNI mejoradas en platform_include/jni_macros.h .
  • Nuevos métodos de ayuda JNI para acceder a las clases internas de java.nio.Buffer desde código nativo (ver métodos que comienzan con jniGetNio en libnativehelper/include/nativehelper/JNIHelp.h ). Estos métodos son utilizados por el código del marco.

cambios en libnativeloader

En Android 10, el módulo Runtime incluye la biblioteca libnativeloader , que es responsable de crear espacios de nombres de vinculadores para cargadores de clases de Java. Los espacios de nombres del vinculador se aplican a las bibliotecas nativas cargadas por las aplicaciones de Android escritas en código administrado. La biblioteca está estrechamente acoplada al enlazador Bionic, que también se encuentra en el módulo.

cambios de libpac

Android 10 mueve libpac , que proporciona una API C para PacProcessor, al módulo Runtime. La biblioteca libpac contiene un motor JavaScript V8 completo y no debe usarse excepto por PacProcessor (un paquete y proceso independiente).

Cambios en la configuración del vinculador

En Android 10, los espacios de nombres del vinculador se utilizan para separar las dependencias de la biblioteca nativa dinámica interna en el módulo Runtime de la plataforma y otros módulos APEX. El espacio de nombres del enlazador de runtime está configurado para las bibliotecas de módulos de tiempo de ejecución, con los enlaces apropiados hacia y desde otros espacios de nombres para las dependencias externas.

La configuración del enlazador reside en /system/etc/ld.config.txt para binarios en /vendor y /system , y en /apex/com.android.runtime/etc/ld.config.txt para binarios en el módulo Runtime mismo ( /apex/com.android.runtime/bin ).

Cambios en SystemServer y framework

En Android 10, SystemServer aloja un nuevo RuntimeService para reportar información desde el módulo Runtime. Para ver esta información, use el siguiente comando ADB:

adb shell dumpsys runtimeinfo

La información administrada por RuntimeService es extensible. Para el código fuente del servicio, consulte frameworks/base/services/core/java/com/android/server/RuntimeService.java ; por ejemplo, el código de cliente, consulte libcore/luni/src/main/java/libcore/util/CoreLibraryDebug.java .

Android 10 también actualiza el proceso de actualización dex2oat (OTA) para usar dex2oat y otras herramientas del módulo Runtime.