Esta página presenta varios mecanismos que los OEM de dispositivos Android pueden utilizar para tener su propia imagen de sistema compartida (SSI) en todas las líneas de productos. También propone un procedimiento para basar un SSI propiedad de OEM en una imagen genérica del sistema (GSI) construida por AOSP.
Fondo
Con Project Treble , el Android monolítico se dividió en dos partes: la parte específica del hardware (la implementación del proveedor) y la parte genérica del sistema operativo (el marco del sistema operativo Android). El software de cada uno se instala en una partición separada: la partición del proveedor para el software específico del hardware y la partición del sistema para el software del sistema operativo genérico. Se define y aplica una interfaz versionada, denominada interfaz de proveedor ( VINTF ), en las dos particiones. Al utilizar este sistema de partición, puede modificar la partición del sistema sin modificar la partición del proveedor, y viceversa.
Motivación
El código del marco publicado en AOSP ha sido compatible con la arquitectura Treble y ha mantenido la compatibilidad con implementaciones de proveedores anteriores. Por ejemplo, una imagen genérica del sistema creada a partir de fuentes de Android 10 AOSP se puede ejecutar en cualquier dispositivo compatible con Treble que se ejecute en Android 8 o superior. Los proveedores de SoC y los OEM modifican la versión de Android que se envía en los dispositivos de consumo. (Consulte Vida útil de una versión de Android ). Estos cambios y extensiones que se realizaron en el marco no se escribieron para mantener la compatibilidad con versiones anteriores, lo que se tradujo en una mayor complejidad y un mayor costo en una actualización del sistema operativo. Los cambios y modificaciones específicos del dispositivo aumentan el costo y la complejidad de actualizar una versión del sistema operativo Android.
Antes de Android 11 no existía una arquitectura clara que permitiera a los socios crear extensiones modulares para el marco del sistema operativo Android. Este documento describe los pasos que los proveedores de SoC y los OEM pueden seguir para crear un SSI. Esto significa una imagen, creada a partir de las fuentes del marco del sistema operativo Android para su reutilización en múltiples dispositivos, para mantener la compatibilidad con las implementaciones de los proveedores y para proporcionar una reducción significativa en la complejidad y el costo de las actualizaciones del sistema operativo Android. Para conocer los pasos específicos que necesita para crear un SSI, consulte la sección Pasos sugeridos para SSI basado en GSI y tenga en cuenta que no es necesario seguir los cuatro pasos. Los pasos que elija (solo el Paso 1, por ejemplo) dependen de su implementación.
Descripción general de SSI
Con SSI, los componentes de software específicos del producto y las extensiones OEM se colocan en una nueva partición /product . Los componentes de la partición /product utilizan una interfaz estable y bien definida para interactuar con los componentes de la partición /system . Los OEM pueden optar por crear un SSI o tener una pequeña cantidad de SSI para usar en múltiples SKU de dispositivos. Cuando se lanza una nueva versión del sistema operativo Android, los OEM invierten solo una vez en actualizar sus SSI a la última versión de Android. Pueden reutilizar los SSI para actualizar varios dispositivos sin actualizar la partición /product .
Tenga en cuenta que los OEM y los proveedores de SoC crean SSI que incluyen todas las funciones personalizadas y modificaciones que necesita un OEM. Los mecanismos y las mejores prácticas proporcionados en esta página están destinados a que los utilicen los OEM para alcanzar estos objetivos clave:
- Reutilice el SSI en varios SKU de dispositivos.
- Actualice el sistema Android con las extensiones modulares para facilitar las actualizaciones del sistema operativo.
La idea central de separar componentes específicos del producto en la partición del producto es similar a la idea de Treble de separar componentes específicos de SoC en la partición del proveedor. Una interfaz de producto (similar a VINTF ) permite la comunicación entre SSI y la partición del producto. Tenga en cuenta que con respecto a SSI, el término "componentes" describe todos los recursos, binarios, textos, bibliotecas, etc. que se instalan en imágenes, que esencialmente se convierten en particiones.
Particiones alrededor de SSI
La Figura 1 muestra las particiones alrededor de SSI y las interfaces versionadas en las particiones y las políticas en las interfaces. Esta sección explica cada una de las particiones e interfaces en detalle.
Figura 1. Particiones e interfaces alrededor de SSI
Imágenes y particiones
La información de esta sección distingue entre los términos imagen y partición .
- Una imagen es una pieza conceptual de software que se puede actualizar de forma independiente.
- Una partición es una ubicación de almacenamiento físico que se puede actualizar de forma independiente.
Las secciones en la Figura 1 se definen de la siguiente manera:
SSI: SSI es la imagen común a un OEM y puede existir en varios dispositivos. No tiene componentes específicos de hardware o de producto. Todo lo que hay en un SSI determinado se comparte, por definición, entre todos los dispositivos que utilizan ese SSI. El SSI se compone de una única imagen
/systemo de una partición/systemy/system_ext, como se ve en la Figura 1.La partición
/systemcontiene componentes basados en AOSP, mientras que/system_ext, cuando se implementa, contiene extensiones y componentes de proveedores OEM y SoC que están estrechamente acoplados con los componentes de AOSP. Por ejemplo, una biblioteca de marco Java OEM que proporciona API personalizadas para las propias aplicaciones del OEM encaja mejor en la partición/system_extque en la partición/system. El contenido de las particiones/systemy/system_extse crea a partir de fuentes de Android modificadas por OEM.La partición
/system_extes opcional, pero es beneficioso usarla para cualquier característica y extensión personalizada que esté estrechamente acoplada con componentes basados en AOSP. Esta distinción le ayuda a identificar los cambios que necesita realizar para mover dichos componentes de la partición/system_exta la partición/productdurante un período de tiempo.
Producto: una colección de componentes específicos de un producto o dispositivo que representan personalizaciones OEM y extensiones del sistema operativo Android. Coloque los componentes específicos de SoC en la partición
/vendor. Los proveedores de SoC también pueden utilizar la partición/productpara los componentes apropiados, como los independientes de SoC. Por ejemplo, si un proveedor de SoC proporciona un componente independiente de SoC a sus clientes OEM (que es opcional y se envía con el producto), el proveedor de SoC puede colocar ese componente en la imagen del producto. La ubicación de un componente no está determinada por su propiedad , sino dictada por su propósito .Proveedor : una colección de componentes específicos de SoC.
ODM: una colección de componentes específicos de la placa que no proporciona el SoC. Normalmente, el proveedor de SoC es propietario de la imagen del proveedor, mientras que el fabricante del dispositivo es propietario de la imagen ODM. Cuando no hay una partición
/odmseparada, tanto el proveedor de SoC como las imágenes ODM se fusionan en la partición/vendor.
Interfaces entre imágenes
Existen dos interfaces principales para imágenes de proveedores y productos en torno a SSI:
Interfaz de proveedor (VINTF) : VINTF es la interfaz para los componentes que residen en el proveedor y las imágenes ODM. Los componentes de las imágenes del producto y del sistema solo pueden interactuar con las imágenes del proveedor y ODM a través de esta interfaz. Por ejemplo, la imagen de un proveedor no puede depender de una parte privada de la imagen del sistema y viceversa. Esto se definió originalmente en Project Treble, que dividía las imágenes en particiones de sistema y de proveedor. La interfaz se describe utilizando los siguientes mecanismos:
- HIDL (HAL Passthrough solo está disponible para los módulos
systemysystem_ext) - AIDL estable
- Configuraciones
- API de propiedades del sistema
- API de esquema de archivo de configuración
- VNDK
- API del SDK de Android
- Biblioteca SDK de Java
- HIDL (HAL Passthrough solo está disponible para los módulos
Interfaces del producto : La interfaz del producto es la interfaz entre SSI y la imagen del producto. La definición de una interfaz estable desacopla los componentes del producto de los componentes del sistema en un SSI. La interfaz del producto requiere las mismas interfaces estables que VINTF. Sin embargo, solo se aplican las API VNDK y Android SDK para dispositivos que se inician con Android 11 (y versiones posteriores).
Habilitar SSI en Android 11
Esta sección explica cómo utilizar las nuevas funciones implementadas para admitir SSI en Android 11.
La partición /system_ext
La partición /system_ext se introdujo en Android 11 como una partición opcional. (Es el lugar para los componentes que no son AOSP y que tienen un acoplamiento estrecho con los componentes definidos por AOSP en la partición /system ). Se supone que la partición /system_ext es la extensión específica de OEM para la partición /system , sin una interfaz definida en las dos particiones. Los componentes de la partición /system_ext pueden realizar llamadas API privadas a la partición /system , y los componentes de la partición /system pueden realizar llamadas API privadas a la partición /system_ext .
Debido a que las dos particiones están estrechamente acopladas, ambas particiones se actualizan juntas cuando se lanza una nueva versión de Android. Una partición /system_ext creada para la versión anterior de Android no necesita ser compatible con la partición /system en la próxima versión de Android.
Para instalar un módulo en la partición /system_ext , agregue system_ext_specific: true al archivo Android.bp . Para dispositivos que no tienen una partición /system_ext , instale dichos módulos en el subdirectorio ./system_ext en la partición /system .
Historia
Aquí hay algo de historia sobre la partición /system_ext . El objetivo del diseño era colocar todos los componentes específicos de OEM, independientemente de si son comunes, en la partición /product . Sin embargo, moverlos todos a la vez no era factible, especialmente cuando algunos componentes tenían un acoplamiento estrecho con la partición /system . Para mover un componente estrechamente acoplado a la partición /product , se debe extender la interfaz del producto. Esto a menudo requería que el componente en sí fuera refactorizado exhaustivamente, lo que consume mucho tiempo y esfuerzo. La partición /system_ext comenzó como un lugar para alojar temporalmente aquellos componentes que no están listos para ser movidos a la partición /product . El objetivo del SSI era eliminar eventualmente la partición /system_ext .
Sin embargo, la partición /system_ext es útil para mantener la partición /system lo más cerca posible de AOSP. Con SSI, la mayor parte del esfuerzo de actualización se dedica a los componentes de las particiones /system y /system_ext . Cuando la imagen del sistema se crea a partir de fuentes que son lo más similares posible a las de AOSP, puede centrar el esfuerzo de actualización en la imagen system_ext .
Desagregar componentes de las particiones /system y /system_ext en la partición /product
Android 9 introdujo una partición /product que se combina con la partición /system . Los módulos de la partición /product utilizan los recursos del sistema sin ninguna restricción y viceversa. Para que SSI sea posible en Android 10, los componentes del producto se dividen en las particiones /system_ext y /product . La partición /system_ext no tiene que cumplir con las restricciones sobre el uso de componentes del sistema que la partición /product cumplía en Android 9. A partir de Android 10, la partición /product debe separarse de la partición /system y debe usar interfaces estables de las particiones /system y /system_ext .
El propósito principal de la partición /system_ext es ampliar las funciones del sistema, en lugar de instalar módulos de productos incluidos, como se describe en la sección /system_ext partition . Para hacer esto, desagrupe los módulos específicos del producto y muévalos a la partición /product . La separación de los módulos específicos del producto hace que /system_ext sea común para los dispositivos. (Para obtener más detalles, consulte Cómo hacer que la partición /system_ext sea común ).
Para desagregar la partición /product de los componentes del sistema, la partición /product debe tener la misma política de aplicación que la partición /vendor que ya estaba desagregada con Project Treble.
A partir de Android 11, las interfaces nativas y Java para la partición /product se aplican como se describe a continuación. Para obtener más información, consulte Aplicación de interfaces de partición de productos .
- Interfaces nativas : los módulos nativos en la partición
/productdeben separarse de las otras particiones. Las únicas dependencias permitidas de los módulos del producto son algunas bibliotecas VNDK (incluido LLNDK) de la partición/system. Las bibliotecas JNI de las que dependen las aplicaciones del producto deben ser bibliotecas NDK. - Interfaces Java : los módulos Java (aplicación) en la partición
/productno pueden usar API ocultas porque son inestables. Estos módulos solo deben usar API públicas y API del sistema de la partición/system, y bibliotecas del SDK de Java en la partición/systemo/system_ext. Puede definir bibliotecas de Java SDK para API personalizadas.
Pasos sugeridos para SSI basado en GSI
Figura 2. Particiones sugeridas para SSI basado en GSI
Una imagen genérica del sistema (GSI) es la imagen del sistema que se crea directamente desde AOSP. Se utiliza para las pruebas de cumplimiento de Treble (por ejemplo, CTS-on-GSI) y como plataforma de referencia que los desarrolladores de aplicaciones pueden usar para probar la compatibilidad de sus aplicaciones cuando no tienen un dispositivo real que ejecute la versión requerida de Android.
Los OEM también pueden utilizar GSI para crear su SSI. Como se explica en Imágenes y particiones , SSI consta de la imagen del sistema para los componentes definidos por AOSP y la imagen system_ext para los componentes definidos por OEM. Cuando se utiliza GSI como imagen del system , el OEM puede centrarse en la imagen system_ext para la actualización.
Esta sección proporciona una guía para los OEM que desean modularizar sus personalizaciones en las particiones /system_ext y /product mientras utilizan una imagen del sistema AOSP o casi AOSP. Si los OEM crean la imagen del sistema a partir de fuentes de AOSP, pueden sustituir la imagen del sistema que crean con el GSI proporcionado por AOSP. Sin embargo, los OEM no necesitan llegar al paso final (usando GSI tal como está) de una vez.
Paso 1. Heredar generic_system.mk para la imagen del sistema OEM (OEM GSI)
Al heredar generic_system.mk (que se llamó mainline_system.mk en Android 11 y se renombró a generic_system.mk en AOSP), la imagen del sistema (OEM GSI) incluye todos los archivos que tiene AOSP GSI. Estos archivos pueden ser modificados por los OEM, de modo que el OEM GSI pueda contener los archivos propietarios del OEM además de los archivos AOSP GSI. Sin embargo, los OEM no pueden modificar el archivo generic_system.mk .
Figura 3. Herencia de generic_system.mk para la imagen del sistema del OEM
Paso 2. Hacer que el GSI OEM tenga la misma lista de archivos que el GSI AOSP
El OEM GSI no puede tener archivos adicionales en esta etapa. Los archivos propietarios del OEM deben trasladarse a system_ext o a las particiones product .
Figura 4. Mover archivos agregados fuera del GSI OEM
Paso 3. Definir una lista de permitidos para limitar los archivos modificados en OEM GSI
Para verificar los archivos modificados, los OEM pueden usar la herramienta compare_images y comparar el AOSP GSI con el OEM GSI. Obtenga el AOSP GSI del destino del almuerzo AOSP generic_system_* .
Al ejecutar la herramienta compare_images periódicamente con el parámetro allowlist , puede monitorear las diferencias fuera de la lista permitida. Esto evita la necesidad de modificaciones adicionales al OEM GSI.
Figura 5. Defina una lista de permitidos para reducir la lista de archivos modificados en OEM GSI
Paso 4. Hacer que el GSI OEM tenga los mismos binarios que el GSI AOSP
La limpieza de la lista de permitidos permite a los OEM utilizar AOSP GSI como imagen del sistema para sus propios productos. Para limpiar la lista de permitidos, los OEM pueden abandonar sus cambios en OEM GSI o actualizar sus cambios a AOSP para que AOSP GSI incluya sus cambios.
Figura 6. Hacer que el GSI OEM tenga los mismos binarios que el GSI AOSP
Definición de SSI para OEM
Proteja la partición /system en el momento de la compilación
Para evitar cambios específicos del producto en la partición /system y definir el GSI OEM, los OEM pueden usar una macro de archivo MAKE llamada require-artifacts-in-path para evitar cualquier declaración de módulos del sistema después de llamar a la macro. Consulte el ejemplo Crear archivo MAKE y habilitar verificación de ruta de artefacto .
Los OEM pueden definir una lista para permitir que módulos específicos del producto se instalen temporalmente en la partición /system . Sin embargo, la lista debe estar vacía para que el GSI OEM sea común a todos los productos del OEM. Este proceso es para definir el GSI OEM y puede ser independiente de los pasos para el GSI AOSP .
Aplicar interfaces de productos
Para garantizar que la partición /product esté desagregada, los OEM pueden asegurarse de que sus dispositivos apliquen las interfaces del producto configurando PRODUCT_PRODUCT_VNDK_VERSION:= current para módulos nativos y PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true para módulos Java. Estas variables se configuran automáticamente si PRODUCT_SHIPPING_API_LEVEL del dispositivo es mayor o igual a 30 . Para obtener información detallada, consulte Aplicación de interfaces de partición de productos .
Hacer que la partición /system_ext sea común
La partición /system_ext puede diferir entre dispositivos, porque puede tener módulos incluidos en el sistema específicos del dispositivo. Debido a que SSI consta de particiones /system y /system_ext , las diferencias en la partición /system_ext impiden que los OEM definan un SSI. Los OEM pueden tener su propio SSI y compartir ese SSI entre múltiples dispositivos eliminando cualquier diferencia y haciendo que la partición /system_ext sea común.
Esta sección ofrece recomendaciones para hacer que la partición /system_ext sea común.
Exponer API ocultas en la partición del sistema
Muchas aplicaciones específicas de productos no se pueden instalar en la partición del producto porque utilizan API ocultas, que están prohibidas en la partición del producto. Para mover aplicaciones específicas del dispositivo a la partición del producto, elimine el uso de API ocultas.
La forma preferida de eliminar las API ocultas de las aplicaciones es encontrar API públicas o del sistema alternativas para reemplazarlas. Si no hay API para reemplazar las API ocultas, los OEM pueden contribuir a AOSP para definir las nuevas API del sistema para sus dispositivos.
Alternativamente, los OEM pueden definir API personalizadas creando su propia biblioteca Java SDK en la partición /system_ext . Puede utilizar API ocultas en la partición del sistema y puede proporcionar las API a las aplicaciones en la partición del producto o proveedor. Los OEM deben congelar las API orientadas al producto para lograr compatibilidad con versiones anteriores.
Incluya el superconjunto de todos los APK y omita la instalación de algunos paquetes para cada dispositivo
Ciertos paquetes incluidos con el sistema no son comunes en todos los dispositivos. Desagregar estos módulos APK para moverlos al producto o a la partición del proveedor puede resultar complicado. Como solución provisional, los OEM pueden hacer que el SSI incluya todos los módulos y luego filtrar los no deseados utilizando una propiedad SKU ( ro.boot.hardware.sku ). Para usar el filtro, los OEM superponen los recursos del marco config_disableApkUnlessMatchedSku_skus_list y config_disableApksUnlessMatchedSku_apk_list .
Para configuraciones más precisas, declare un receptor de transmisión que deshabilite los paquetes innecesarios. El receptor de transmisión llama setApplicationEnabledSetting para deshabilitar el paquete cuando recibe el mensaje ACTION_BOOT_COMPLETED .
Defina RRO en lugar de utilizar superposición de recursos estáticos
Una superposición de recursos estáticos manipula los paquetes superpuestos. Sin embargo, puede impedir la definición de un SSI, así que asegúrese de que las propiedades de RRO estén activadas y configuradas correctamente. Al configurar las propiedades de la siguiente manera, los OEM pueden tener todas las superposiciones generadas automáticamente como RRO.
PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty
Si se requiere una configuración detallada, defina un RRO manualmente en lugar de confiar en uno generado automáticamente. Para obtener información detallada, consulte Superposiciones de recursos en tiempo de ejecución (RRO) . Los OEM también pueden definir RRO condicionales que dependen de las propiedades del sistema mediante el uso de los atributos android:requiredSystemPropertyName y android:requiredSystemPropertyValue .
Preguntas frecuentes (FAQ)
¿Puedo definir múltiples SSI?
Depende de los puntos en común y las características de los dispositivos (o grupo de dispositivos). Los OEM pueden intentar hacer que la partición system_ext sea común, como se describe en Cómo hacer que la partición system_ext sea común . Si un grupo de dispositivos tiene muchas diferencias, entonces es mejor definir varios SSI.
¿Puedo modificar generic_system.mk ( mainline_system.mk ) para un GSI OEM?
No. Pero los OEM pueden definir un nuevo archivo MAKE para un GSI OEM que hereda el archivo generic_system.mk y utilizar el nuevo archivo MAKE en su lugar. Para ver un ejemplo, consulte Aplicación de interfaces de partición de productos .
¿Puedo eliminar módulos de generic_system.mk que entren en conflicto con mi implementación?
No. GSI tiene un conjunto mínimo de módulos de arranque y comprobables. Si cree que un módulo no es esencial, presente un error para actualizar el archivo generic_system.mk en AOSP.