Esta página presenta varios mecanismos que los OEM de dispositivos Android pueden usar 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 un OEM en una imagen de sistema genérica (GSI) creada 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 del sistema operativo genérico (el marco del sistema operativo Android). El software para 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. Una interfaz versionada, denominada interfaz de proveedor ( VINTF ), se define y aplica en las dos particiones. Al usar 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 de marco publicado en AOSP ha sido compatible con la arquitectura Treble y ha mantenido la compatibilidad con versiones anteriores con implementaciones de proveedores anteriores. Por ejemplo, una imagen de sistema genérica creada a partir de fuentes AOSP de Android 10 puede ejecutarse 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 habí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 varios dispositivos, para mantener la compatibilidad con versiones anteriores de las implementaciones del proveedor 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 tiene que usar 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 elegir construir un SSI o tener una pequeña cantidad de SSI para usar en varios 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 proveedores de SoC y OEM crean SSI que incluyen todas las funciones y modificaciones personalizadas que necesita un OEM. Los mecanismos y las mejores prácticas proporcionados en esta página están destinados a que los OEM los utilicen para alcanzar estos objetivos clave:
- Reutilice el SSI en múltiples SKU de dispositivos.
- Actualice el sistema Android con las extensiones modulares para facilitar las actualizaciones del sistema operativo.
La idea central de separar los componentes específicos del producto en la partición del producto es similar a la idea de Treble de separar los componentes específicos del 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, archivos binarios, textos, bibliotecas, etc. que se instalan en las imágenes, que esencialmente se convierten en particiones.
Particiones alrededor de SSI
La Figura 1 muestra las particiones alrededor de SSI y las interfaces con versiones 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 de la Figura 1 se definen de la siguiente manera:
SSI: el SSI es la imagen que es común a un OEM y puede existir en varios dispositivos. No tiene ningún componente específico del hardware o del producto. Todo en un SSI dado es, por definición, compartido entre todos los dispositivos que usan ese SSI. El SSI se compone de una sola imagen
/systemo de un/systemy las particiones/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 componentes y extensiones de proveedores OEM y SoC que están estrechamente relacionados con los componentes AOSP. Por ejemplo, una biblioteca de marco Java OEM que proporciona API personalizadas para las propias aplicaciones del OEM encaja mejor en la/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 función y extensión personalizada que esté estrechamente relacionada con los componentes basados en AOSP. Esta distinción lo ayuda a identificar los cambios que debe 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 productos o dispositivos que representan personalizaciones OEM y extensiones para el sistema operativo Android. Coloque los componentes específicos de SoC en la partición
/vendor. Los proveedores de SoC también pueden usar 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 para enviar 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 , está 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. Por lo general, el proveedor de SoC posee la imagen del proveedor, mientras que el fabricante del dispositivo posee la imagen ODM. Cuando no hay una partición
/odmseparada, tanto el proveedor de SoC como las imágenes de 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 del 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 dividió las imágenes en particiones de sistema y proveedor. La interfaz se describe utilizando los siguientes mecanismos:
- HIDL (Passthrough HAL 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 SDK de Android
- Biblioteca Java SDK
- HIDL (Passthrough HAL 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 de VNDK y SDK de Android para los dispositivos que se inician con Android 11 (y versiones posteriores).
Habilitación de SSI en Android 11
Esta sección explica cómo usar las nuevas funciones 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 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 del OEM para la partición /system , sin una interfaz definida a través de las dos particiones. Los componentes de la partición /system_ext pueden realizar llamadas de API privadas a la partición /system , y los componentes de la partición /system pueden realizar llamadas de 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 los 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 del OEM, independientemente de que fueran 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 ampliar la interfaz del producto. Esto a menudo requería que el componente mismo se refactorizara ampliamente, lo que consume mucho tiempo y esfuerzo. La partición /system_ext comenzó como un lugar para hospedar temporalmente aquellos componentes que no están listos para moverse a la partición /product . El objetivo del SSI era eliminar finalmente 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 gasta en 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 .
Desagrupar 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 /system_ext y /product . La partición /system_ext no tiene que cumplir con las restricciones sobre el uso de componentes del sistema que tenía la partición /product en Android 9. A partir de Android 10, la partición /product debe desvincularse de la partición /system y debe usar interfaces estables de las particiones /system y /system_ext .
El objetivo principal de la partición /system_ext es ampliar las características del sistema, en lugar de instalar módulos de productos empaquetados, como se describe en la sección de la /system_ext partition . Para hacer esto, desagrupe los módulos específicos del producto y muévalos a la partición /product . Al desagregar los módulos específicos del producto, /system_ext común a los dispositivos. (Para obtener más detalles, consulte 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 cumplimiento que la partición /vendor que ya se desagregó con Project Treble.
A partir de Android 11, las interfaces Java y nativas 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 desagruparse 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 de Java : los módulos de Java (aplicación) en la partición
/productno pueden usar API ocultas porque son inestables. Estos módulos solo deben usar las API públicas y las API del sistema de la partición/systemy las bibliotecas SDK de Java en la partición/systemo/system_ext. Puede definir bibliotecas 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 usa para las pruebas de cumplimiento de Treble (por ejemplo, CTS-on-GSI) y como una 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 usar GSI para hacer su SSI. Como se explica en Imágenes y particiones , SSI consiste en la imagen del sistema para los componentes definidos por AOSP y la imagen system_ext para los componentes definidos por OEM. Cuando se usa GSI como imagen del system , el OEM puede enfocarse 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 /system_ext y /product mientras usan una imagen del sistema AOSP o casi AOSP. Si los OEM construyen la imagen del sistema a partir de fuentes AOSP, pueden sustituir la imagen del sistema que construyen con el GSI proporcionado por AOSP. Sin embargo, los OEM no necesitan llegar al paso final (utilizando GSI tal cual) de una sola vez.
Paso 1. Heredar generic_system.mk para la imagen del sistema del OEM (OEM GSI)
Al heredar generic_system.mk (que se denominó 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 GSI del OEM pueda contener los archivos propietarios del OEM además de los archivos GSI del AOSP. Sin embargo, los OEM no pueden modificar el archivo generic_system.mk en sí.
Figura 3. Heredar generic_system.mk para la imagen del sistema del OEM
Paso 2. Hacer que el OEM GSI tenga la misma lista de archivos con el AOSP GSI
El OEM GSI no puede tener archivos adicionales en esta etapa. Los archivos de propiedad del OEM se deben mover a system_ext o particiones de product .
Figura 4. Mover archivos agregados fuera del OEM GSI
Paso 3. Definición de una lista de permitidos para limitar los archivos modificados en el 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 AOSP lunch target generic_system_* .
Al ejecutar la herramienta compare_images periódicamente con el parámetro de lista de allowlist , puede monitorear las diferencias fuera de la lista de permitidos. 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 el OEM GSI
Paso 4. Hacer que el OEM GSI tenga los mismos archivos binarios que el AOSP GSI
La limpieza de la lista de elementos 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 el GSI de OEM o subir sus cambios a AOSP para que el GSI de AOSP incluya sus cambios.
Figura 6. Hacer que el OEM GSI tenga los mismos archivos binarios que el AOSP GSI
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 de OEM, los OEM pueden usar una macro makefile 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 un archivo MAKE y habilitar la verificación de la ruta del artefacto .
Los OEM pueden definir una lista para permitir la instalación temporal de módulos específicos del producto en la partición /system . Sin embargo, la lista debe estar vacía para que el GSI del OEM sea común a todos los productos del OEM. Este proceso es para definir el OEM GSI y puede ser independiente de los pasos para el AOSP GSI .
Hacer cumplir las interfaces del producto
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 el 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 común
La partición /system_ext puede diferir entre dispositivos, ya que puede tener módulos integrados en el sistema específicos del dispositivo. Dado que el 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 pueden compartir ese SSI entre varios dispositivos al eliminar cualquier diferencia y hacer que la partición /system_ext común.
Esta sección brinda recomendaciones para hacer que la partición /system_ext común.
Exponer API ocultas en la partición del sistema
Muchas aplicaciones específicas del producto no se pueden instalar en la partición del producto porque usan 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 las API públicas o del sistema alternativas para reemplazarlas. Si no hay API para reemplazar las API ocultas, los OEM pueden contribuir con 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 usar 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 la compatibilidad con versiones anteriores.
Incluya el superconjunto de todos los APK y omita algunas instalaciones de paquetes para cada dispositivo
Ciertos paquetes que se incluyen con el sistema no son comunes en todos los dispositivos. Desagrupar estos módulos APK para moverlos al producto o a la partición del proveedor puede ser difícil. Como solución provisional, los OEM pueden hacer que el SSI incluya todos los módulos y luego filtrar los no deseados mediante 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 paquetes innecesarios. El receptor de difusión llama a setApplicationEnabledSetting para deshabilitar el paquete cuando recibe el mensaje ACTION_BOOT_COMPLETED .
Defina RRO en lugar de usar 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 para 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 de 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 varios SSI?
Depende de la comunidad y las características de los dispositivos (o grupo de dispositivos). Los OEM pueden intentar hacer que la partición system_ext 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, es mejor definir varios SSI.
¿Puedo modificar generic_system.mk ( mainline_system.mk ) para un OEM GSI?
No. Pero los OEM pueden definir un nuevo archivo MAKE para un GSI de OEM que hereda el archivo generic_system.mk y usar 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.