Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Ciclo de vida de FCM

Una versión de marco de Android tiene varias Matrices de compatibilidad de marco (FCM), una para cada versión de Target FCM actualizable, que definen lo que puede usar el marco y los requisitos de la versión de Target FCM. Como parte del ciclo de vida de FCM, Android desaprueba y quita HIDL HAL, luego modifica los archivos FCM para reflejar el estado de la versión HAL .

Para habilitar las OTA de solo marco en sus propios ecosistemas, los socios que extienden las interfaces de los proveedores también deben desaprobar y eliminar HIDL HAL utilizando los mismos métodos.

Terminología

Matriz de compatibilidad de marcos (FCM) Un archivo XML que especifica los requisitos del marco para cumplir con las implementaciones de los proveedores. Se versiona la matriz de compatibilidad y se congela una nueva versión para cada versión del marco. Cada versión de marco contiene varios FCM.
Versiones de plataforma FCM (S F ) El conjunto de todas las versiones de FCM en una versión de marco. El marco puede funcionar con cualquier implementación de proveedor que satisfaga uno de estos FCM.
Versión FCM (F) La versión más alta entre todos los FCM en una versión de marco.
Versión de destino FCM (V) La versión de FCM de destino (de S F ), declarada explícitamente en el manifiesto del dispositivo, que satisface la implementación de un proveedor. Se debe generar una implementación de proveedor contra un FCM publicado, aunque puede declarar versiones de HAL más nuevas en su manifiesto de dispositivo.
Versión HAL Una versión HAL tiene el formato foo@xy , donde foo es el nombre HAL y xy es la versión específica; por ejemplo, nfc@1.0 , keymaster@3.0 (el prefijo raíz, por ejemplo, android.hardware , se omite en este documento).
Manifiesto del dispositivo Un archivo XML que especifica qué versiones de HAL proporciona la imagen del proveedor. El contenido de un manifiesto de dispositivo está restringido por la versión Target FCM del dispositivo, pero puede enumerar las HAL que son estrictamente más nuevas en relación con el FCM correspondiente a V.

Desarrollando en una nueva versión de FCM

Android incrementa la versión de FCM para cada versión de marco (como Android 8, 8.1, etc.). Durante el desarrollo, se crea la nueva compatibility_matrix.current.xml ( F ) y la matriz de compatibility_matrix.f.xml existente.f.xml (donde f < F ) ya no se cambia.

Para comenzar a desarrollar en una nueva versión F FCM:

  1. Copie la última compatibility_matrix.<F-1>.xml a la compatibility_matrix.<F-1>.xml de compatibility_matrix.current.xml .
  2. Actualice el atributo de level en el archivo a F
  3. Agregue las reglas de compilación correspondientes para instalar esta matriz de compatibilidad en el dispositivo.

Presentando un nuevo HAL

Durante el desarrollo, al introducir una nueva HAL (Wi-Fi, NFC, etc.) a Android en la versión F FCM actual, agregue la HAL a la compatibility_matrix.current.xml con las siguientes configuraciones optional :

  • optional="false" si los dispositivos que se envían con V = F deben iniciarse con este HAL,

    O
  • optional="true" si los dispositivos que se envían con V = F pueden iniciarse sin esta HAL.

Por ejemplo, Android 8.1 introdujo cas@1.0 como un HAL opcional. Los dispositivos que se inician con Android 8.1 no están obligados a implementar esta HAL, por lo que se agregó la siguiente entrada a compatibility_matrix.current.xml (renombrada como compatibility_matrix.2.xml después del lanzamiento de Android 8.1):

<hal format="hidl" optional="true">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Actualizar un HAL (menor)

Durante el desarrollo, cuando un HAL tiene una actualización de versión menor de xz a x.(z+1) en la versión F FCM actual, si esa versión es:

  • Requerido en dispositivos que se inician con V = F , la compatibility_matrix.current.xml debe indicar x.(z+1) y optional="false" .
  • No se requiere en dispositivos que se inician con V = F , la xw-(z+1) compatibility_matrix.current.xml debe copiar xy-z y la opcionalidad de xw-(z+1) de compatibility_matrix.<F-1>.xml y cambiar la versión a xw-(z+1) (donde w >= y ).

Por ejemplo, Android 8.1 introdujo broadcastradio@1.1 como una actualización de versión menor de 1.0 HAL. La versión anterior, broadcastradio@1.0 , es opcional para dispositivos que se inician con Android 8.0, mientras que la versión más nueva, broadcastradio@1.1 , es opcional para dispositivos que se inician con Android 8.1. En compatibility_matrix.1.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Esta entrada se copió a compatibility_matrix.current.xml (renombrada como compatibility_matrix.2.xml después del lanzamiento de Android 8.1) y se modificó de la siguiente manera:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Actualizar un HAL (mayor)

Durante el desarrollo, cuando una HAL tiene una actualización de versión principal en la versión F FCM actual, la nueva versión principal x.0 se agrega a compatibility_matrix.current.xml con la siguiente configuración optional :

  • optional="false" solo con la versión x.0 , si los dispositivos que se envían con V = F deben x.0 con x.0 .
  • optional="false" pero junto con las versiones principales anteriores en la misma etiqueta <hal> , si los dispositivos que se envían con V = F deben iniciarse con esta HAL, pero pueden iniciarse con una versión principal anterior.
  • optional="true" si los dispositivos que se envían con V = F no tienen que iniciar el HAL.

Por ejemplo, Android 9 presenta health@2.0 como una actualización de la versión principal de 1.0 HAL y desaprueba la 1.0 HAL. La versión anterior, health@1.0 , es opcional para dispositivos que se health@1.0 con Android 8.0 y Android 8.1. Los dispositivos que se inician con Android 9 no deben proporcionar el HAL 1.0 obsoleto y, en su lugar, deben proporcionar la nueva versión 2.0. En compatibility_matrix.legacy.xml , compatibility_matrix.1.xml y compatibility_matrix.2.xml :

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Esta entrada se copia a compatibility_matrix.current.xml (renombrado como compatibility_matrix.3.xml con la versión de Android 9) y se modifica de la siguiente manera:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Restricciones:

  • Debido a que 2.0 HAL está en compatibility_matrix.3.xml con optional="false" , los dispositivos que se inician con Android 9 deben enviarse con 2.0 HAL.
  • Debido a que la HAL 1.0 no está en compatibility_matrix.3.xml , los dispositivos que se inician con Android 9 no deben proporcionar la HAL 1.0 (ya que esta HAL se considera obsoleta).
  • Debido a que 1.0 HAL está presente en legacy / 1 / 2.xml (versiones de FCM más antiguas con las que puede funcionar Android 9) como una HAL opcional, el marco de Android 9 aún puede funcionar con 1.0 HAL (que no se considera una versión de HAL eliminada ).

Nuevas versiones de FCM

El proceso de lanzamiento de una versión de FCM en la partición del sistema lo realiza únicamente Google como parte de un lanzamiento de AOSP e incluye los siguientes pasos:

  1. Cambie el nombre de compatibility_matrix.current.xml a compatibility_matrix.F.xml .
  2. Asegúrese de que el archivo tenga el level="F" atributo level="F" .
  3. Edite las reglas de compilación correspondientes para reflejar el cambio de nombre de archivo.
  4. Asegúrese de que todos los dispositivos se construyan y arranquen.
  5. Actualice las pruebas de VTS para garantizar que los dispositivos que se inician con el marco más reciente (según el nivel de API de envío) tengan Target FCM Versión V >= F
  6. Publicar archivo en AOSP.

Este archivo no se puede cambiar una vez que se renombra y se publica. Por ejemplo, durante el desarrollo de Android 9, se crean los siguientes archivos para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Cuando se lanza Android 9, el nombre de la compatibility_matrix.3.xml compatibility_matrix.current.xml se cambia a compatibility_matrix.3.xml de compatibility_matrix.3.xml y los siguientes archivos se crean para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

Las pruebas de VTS garantizan que los dispositivos que se inician con Android 9 tienen la versión Target FCM> = 3.

Además, los FCM de producto y system_ext también pueden enumerar los requisitos para las versiones de FCM de cada plataforma. El propietario de estas imágenes realiza la publicación de las versiones de FCM en las particiones de producto y system_ext, respectivamente. Los números de versión de FCM en las particiones del producto y system_ext deben coincidir con los de la partición del sistema. De forma similar a las versiones de FCM en la partición del sistema, la matriz de compatibilidad en la versión F de FCM en las particiones product y system_ext refleja los requisitos en un dispositivo con la versión F de FCM de destino.

Desactivación de la versión HAL

Desactivar una versión HAL es una decisión del desarrollador (es decir, para AOSP HAL, Google toma la decisión). Podría suceder cuando se lanza una versión HAL superior (ya sea menor o mayor). Cuando un HAL foo@xy dado está obsoleto en FCM Versión F , significa que cualquier dispositivo que se inicie con Target FCM Versión V = F o posterior no debe implementar foo en la versión xy o cualquier versión anterior a xy . Una versión obsoleta de HAL todavía es compatible con el marco para actualizar dispositivos.

Cuando se lanza la versión F FCM, una versión de HAL foo@xy se considera obsoleta si la versión de HAL específica no se indica explícitamente en la última versión de FCM para Target FCM versión V = F Para los dispositivos que se inician con V , se cumple una de las siguientes condiciones:

  • El marco requiere una versión superior (mayor o menor);
  • El marco ya no requiere el HAL.

Por ejemplo, en Android 9, health@2.0 se presenta como una actualización de la versión principal de 1.0 HAL. health@1.0 se retira de compatibility_matrix.3.xml pero está presente en compatibility_matrix.legacy.xml , compatibility_matrix.1.xml , y compatibility_matrix.2.xml . Por lo tanto, health@1.0 se considera obsoleto.

Eliminación de la compatibilidad con las versiones de Target FCM

Cuando los dispositivos activos de una determinada Target FCM Version V caen por debajo de un cierto umbral, la Target FCM Version se elimina del conjunto S F de la próxima versión del marco. Esto se hace eliminando compatibility_matrix.V.xml de las reglas de compilación (para que ya no esté instalado en la imagen del sistema) y eliminando cualquier código que implementó o dependía de la funcionalidad eliminada. Los dispositivos con una versión de FCM de destino fuera de S F para una versión de marco determinada no pueden actualizarse a esa versión.

Estado de la versión HAL

Las siguientes secciones describen (en orden cronológico) los posibles estados de una versión HAL.

Inédito

Si una versión de HAL no está en ninguna de las matrices de compatibilidad pública y congelada, se considera que no ha sido publicada y posiblemente esté en desarrollo. Esto incluye versiones de HAL que solo están en compatibility_matrix.current.xml . Ejemplos:

  • Durante el desarrollo de Android 9 (antes de que compatibiility_matrix.current.xml se cambiara el nombre a compatibility_matrix.3.xml ), health@2.0 HAL se consideraba un HAL inédito.
  • El teleportation@1.0 HAL no está en ninguna matriz de compatibilidad publicada y también se considera un HAL inédito.

Lanzado y actual

Si una versión HAL está en cualquier matriz de compatibilidad pública y congelada, se publica. Por ejemplo, después de que se congele la versión 3 de FCM (cuando compatibiility_matrix.current.xml se cambia el nombre a compatibility_matrix.3.xml ) y se publica en AOSP, health@2.0 HAL se considera una versión de HAL publicada y actual.

Si una versión de HAL está en una matriz de compatibilidad pública y congelada que tiene la versión de FCM más alta (excluyendo compatibility_matrix.current.xml ), la versión de HAL es actual (es decir, no está obsoleta). Por ejemplo, las versiones de HAL existentes (como nfc@1.0 introducidas en la nfc@1.0 de compatibility_matrix.legacy.xml ) que continúan existiendo en la nfc@1.0 compatibility_matrix.3.xml también se consideran versiones de HAL publicadas y actuales.

Publicado pero desaprobado

Una versión HAL está obsoleta si y solo si:

  • Se libera;
  • No está en la matriz de compatibilidad pública y congelada que tiene la versión FCM más alta;
  • Es en una matriz de compatibilidad pública y congelada que el marco aún admite.

Ejemplos:

Por power@1.0 tanto, power@1.0 es actual, pero NO obsoleto, en Android 9.

Remoto

Una versión HAL se elimina si y solo si:

  • Fue lanzado previamente;
  • No está en ninguna matriz de compatibilidad pública y congelada que admita el marco.

Las matrices de compatibilidad que son públicas, congeladas, pero que no son compatibles con el marco se mantienen en la base del código para definir el conjunto de Versiones de HAL eliminadas, de modo que las pruebas de VTS se puedan escribir para garantizar que las HAL eliminadas no estén en dispositivos nuevos.

FCM heredados

La versión heredada de Target FCM es un valor especial para todos los dispositivos que no son de agudos. El FCM heredado, compatibility_matrix.legacy.xml , enumera los requisitos del marco en dispositivos heredados (es decir, dispositivos lanzados antes de Android 8.0).

Si este archivo existe para un FCM con la versión F , cualquier dispositivo que no sea Treble puede actualizarse a F siempre que su manifiesto de dispositivo sea compatible con este archivo. Su eliminación sigue el mismo procedimiento que los FCM para otras versiones de Target FCM (eliminados después de que el número de dispositivos activos anteriores a 8.0 caiga por debajo de un cierto umbral).

Versiones de FCM publicadas

La lista de versiones de FCM publicadas se puede encontrar en hardware/interfaces/compatibility_matrices .

Para encontrar la versión de FCM lanzada con una versión específica de Android, consulte Level.h .