Ciclo de vida de FCM

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

Para habilitar actualizaciones OTA solo de framework en sus propios ecosistemas, los socios que extienden interfaces de proveedores también deben dar de baja y quitar los HAL de HIDL con los mismos métodos.

Terminología

Matriz de compatibilidad del marco de trabajo (FCM)

Es un archivo en formato XML que especifica los requisitos del framework en las implementaciones de proveedores que cumplen con los requisitos. La matriz de compatibilidad tiene control de versiones, y se inmoviliza una versión nueva para cada versión del framework. Cada versión del framework contiene varios FCM.

Versiones de FCM para la plataforma (S_F)

Es el conjunto de todas las versiones de FCM en una versión del framework. El framework puede funcionar con cualquier implementación de proveedor que satisfaga uno de estos FCM.

Versión de FCM (F)

Es la versión más alta de todos los FCM en una versión de framework.

Versión de FCM de destino (V)

Es 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 del proveedor en función de un FCM publicado, aunque puede declarar versiones más recientes de HAL en su manifiesto de dispositivos.

Versión de HAL

Una versión de HAL tiene el formato foo@x.y, en el que foo es el nombre de HAL y x.y es la versión específica, p.ej., nfc@1.0, keymaster@3.0 (el prefijo raíz, p.ej., android.hardware, se omite en todo este documento).

Manifiesto del dispositivo

Archivos en formato XML que especifican qué versiones de HAL proporciona el lado del dispositivo de la interfaz del proveedor, incluidas las imágenes del proveedor y del ODM. El contenido de un manifiesto del dispositivo está restringido por la versión de FCM de destino del dispositivo, pero puede enumerar las HAL que son estrictamente más recientes en relación con la FC correspondiente a V.

HAL de dispositivos

Son las HAL que se enumeran (proporcionan) en el manifiesto del dispositivo y se enumeran (ya sea obligatorias u opcionales) en la matriz de compatibilidad del marco de trabajo (FCM).

Matriz de compatibilidad de dispositivos (DCM)

Archivo en formato XML que especifica los requisitos del proveedor sobre el cumplimiento de las implementaciones del framework. Cada dispositivo contiene un DCM.

Manifiesto del framework

Es un archivo en formato XML que especifica qué versiones de HAL proporciona el lado del framework de la interfaz del proveedor, incluidas las imágenes del sistema, system_ext y del producto. Los HAL en el manifiesto del framework se inhabilitan de forma dinámica según la versión de FCM de destino del dispositivo.

HAL de framework

HAL de

que se indican como proporcionados en el manifiesto del framework y como obligatorios o opcionales en la matriz de compatibilidad del dispositivo (DCM).

Ciclo de vida de FCM en la base de código

En este documento, se describe el ciclo de vida de FCM en el resumen. Para ver los manifiestos compatibles, consulta hardware/interfaces/compatibility_matrix.<FCM>.xml, donde se puede encontrar FCM en system/libvintf/include/vintf/Level.h.

Se espera que un dispositivo que envía la versión de actualización de Android correspondiente tenga un valor de FCM superior o igual al nivel equivalente. Por ejemplo, un dispositivo que se envía con Android 11, por lo general, tiene el nivel 5 de FCM, pero implementa el nivel 6 o superior, que incluye varios requisitos adicionales especificados en las matrices de compatibilidad. Los niveles admitidos son los siguientes:

El nivel de FCM es igual o superior al nivel de API del proveedor.

Cuando Android da de baja un nivel de FCM, este sigue siendo compatible con los dispositivos existentes. Los dispositivos que se orientan a niveles inferiores de FCM pueden usar de forma implícita los HAL que se enumeran en niveles de FCM más recientes, siempre que estén disponibles en la rama.

Desarrolla en una nueva versión de FCM

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

Para comenzar a desarrollar en una nueva versión de FCM F, haz lo siguiente:

1. Copia el último compatibility_matrix.<F-1>.xml en compatibility_matrix.F.xml.
2. Actualiza el atributo level del archivo a F.
3. Agrega las reglas de compilación correspondientes para instalar esta matriz de compatibilidad en el dispositivo.

Presenta un nuevo HAL

Durante el desarrollo, cuando introduzcas un nuevo HAL (Wi-Fi, NFC, etcétera) a Android en la versión actual de FCM F, agrega el HAL a compatibility_matrix.F.xml con la siguiente configuración de optional:

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

Por ejemplo, Android 8.1 introdujo cas@1.0 como una HAL opcional. Los dispositivos que se inician con Android 8.1 no deben implementar esta HAL, por lo que se agregó la siguiente entrada a compatibility_matrix.F.xml (que solía llamarse compatibility_matrix.current.xml temporalmente durante el desarrollo de esa versión):

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

Actualiza un HAL (menor)

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

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

Por ejemplo, Android 8.1 introdujo broadcastradio@1.1 como una actualización de versión secundaria de HAL 1.0. La versión anterior, broadcastradio@1.0, es opcional para los dispositivos que se lanzan con Android 8.0, mientras que la versión más reciente, broadcastradio@1.1, es opcional para los dispositivos que se lanzan 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ó en compatibility_matrix.F.xml 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>

Actualiza un HAL (principal)

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

• optional="false" con solo la versión x.0, si los dispositivos que se envían con V = F deben iniciarse con x.0.
• optional="false", pero junto con versiones principales anteriores en la misma etiqueta <hal>, si los dispositivos que se envían con V = F deben iniciarse con este 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 versión principal de la HAL 1.0 y da de baja la HAL 1.0. La versión anterior, health@1.0, es opcional para los dispositivos que se lanzan con Android 8.0 y Android 8.1. Los dispositivos que se lanzan con Android 9 deben proporcionar la nueva versión 2.0. Por ejemplo, supongamos que compatibility_matrix.legacy.xml, compatibility_matrix.1.xml y compatibility_matrix.2.xml contienen esta entrada:

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

Copia esta entrada en compatibility_matrix.F.xml y modifícala 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:

• Como el HAL 2.0 está en compatibility_matrix.3.xml con optional="false", los dispositivos que se inician con Android 9 deben enviarse con el HAL 2.0.
• Como el HAL 1.0 no está en compatibility_matrix.3.xml, los dispositivos que se inician con Android 9 no deben proporcionar el HAL 1.0 (ya que este HAL se considera obsoleto).
• Como el HAL 1.0 está presente en legacy/1/2.xml (versiones anteriores de FCM con las que puede funcionar Android 9) como un HAL opcional, el framework de Android 9 aún puede funcionar con el HAL 1.0 (que no se considera una versión de HAL quitada).

Versiones nuevas de FCM

Google es el único que realiza el proceso de lanzamiento de una versión de FCM en la partición del sistema como parte de una versión de AOSP y, para ello, sigue los pasos que se indican a continuación:

1. Asegúrate de que compatibility_matrix.F.xml tenga el atributo level="F".
2. Asegúrate de que todos los dispositivos se compilen y se inicien.
3. Actualiza las pruebas de VTS para asegurarte de que los dispositivos que se lancen con el framework más reciente (según el nivel de la API de Shipping) tengan la versión V >= F de FCM objetivo.
4. Publica un archivo en AOSP.

Por ejemplo, las pruebas de VTS se aseguran de que los dispositivos que se inician con Android 9 tengan una versión de FCM objetivo superior o igual a 3.

Además, los FCM de product y system_ext también pueden enumerar los requisitos para cada versión de FCM de la plataforma. El propietario de estas imágenes es quien lanza las versiones de FCM en las particiones product y system_ext, respectivamente. Los números de versión de FCM en las particiones del producto y system_ext deben alinearse con los de la partición del sistema. Al igual que las versiones de FCM en la partición del sistema, la matriz de compatibilidad en FCM versión F en el producto y las particiones system_ext reflejan los requisitos de un dispositivo con FCM versión F de destino.

Baja de la versión de HAL

La baja de una versión de HAL es una decisión del desarrollador (es decir, para los HAL de AOSP, Google toma la decisión). Esto puede suceder cuando se lanza una versión posterior de HAL (ya sea menor o principal).

Cómo dar de baja un HAL de dispositivo

Cuando la HAL foo@x.y de un dispositivo determinado deja de estar disponible en la versión F de FCM, significa que cualquier dispositivo que se lance con la versión V = F de FCM de destino o una posterior no debe implementar foo en la versión x.y ni anterior a x.y. El framework aún admite una versión de HAL obsoleta para actualizar dispositivos.

Cuando se lanza la versión F de FCM, una versión foo@x.y de HAL se considera obsoleta si la versión específica de HAL no se indica de forma explícita en la versión más reciente de FCM para la versión de FCM objetivo V = F. En el caso de los dispositivos que se inician con V = F, se cumple una de las siguientes condiciones:

• El framework requiere una versión superior (principal o secundaria).
• El framework ya no requiere el HAL.

Por ejemplo, en Android 9, health@2.0 se presenta como una actualización de versión importante de HAL 1.0. health@1.0 se quitó 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.

Cómo dar de baja un HAL de framework

Cuando un foo@x.y de HAL de framework determinado deja de estar disponible en la versión F de FCM, significa que cualquier dispositivo que se inicie con la versión objetivo V = F de FCM o una posterior no debe esperar que el framework proporcione foo en la versión x.y ni en ninguna versión anterior a x.y. El framework aún proporciona una versión obsoleta de HAL para actualizar los dispositivos.

Cuando se lanza la versión F de FCM, una versión foo@x.y de HAL se considera obsoleta si el manifiesto del framework especifica max-level="F - 1" para foo@x.y. En el caso de los dispositivos que se inician con V = F, el framework no proporciona el foo@x.y de HAL. La matriz de compatibilidad de dispositivos en los dispositivos que se inician con V = F no debe enumerar los HAL de framework con max-level < V.

Por ejemplo, en Android 12, schedulerservice@1.0 dejó de estar disponible. Su atributo max-level se establece en 5, la versión de FCM que se introdujo en Android 11. Consulta el manifiesto del framework de Android 12.

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

Cuando los dispositivos activos de una versión objetivo de FCM V bajan de un umbral determinado, la versión objetivo de FCM se quita del conjunto S_F de la próxima versión del framework. Para ello, sigue estos dos pasos:

1. Quitar compatibility_matrix.V.xml de las reglas de compilación (para que no se instale en la imagen del sistema) y borrar cualquier código que implemente o dependa de las funciones quitadas

2. Quitar los HAL del framework con max-level inferior o igual a V del manifiesto del framework y borrar cualquier código que implemente los HAL del framework quitados

Los dispositivos con una versión objetivo de FCM fuera de S_F para una versión determinada del framework no pueden actualizarse a esa versión.

Estado de la versión de HAL

En las siguientes secciones, se describen (en orden cronológico) los posibles estados de una versión de HAL.

Beta

En el caso de los HAL de dispositivos, si una versión de HAL no está en ninguna de las matrices de compatibilidad públicas y fijas, se considera que no se lanzó y, posiblemente, que está en desarrollo. Esto incluye las versiones de HAL que solo están en compatibility_matrix.F.xml. Ejemplos:

• Durante el desarrollo de Android 9, la HAL de health@2.0 se consideraba una HAL no publicada y solo estaba presente en compatibility_matrix.3.xml.
• El HAL de teleportation@1.0 no se encuentra en ninguna matriz de compatibilidad publicada y también se considera un HAL sin publicar.

En el caso de los HAL de framework, si una versión de HAL solo está en el manifiesto del framework de una rama de desarrollo no relacionada, se considera que no se lanzó.

Lanzadas y actuales

En el caso de las HAL de dispositivos, si una versión de HAL está en una matriz de compatibilidad pública y congelada, se lanza. Por ejemplo, después de que se bloquea la versión 3 de FCM y se publica en el AOSP, la HAL health@2.0 se considera una versión lanzada y actual de la HAL.

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

En el caso de las HAL del framework, si una versión de HAL se encuentra en el manifiesto del framework de la rama de la versión más reciente sin el atributo max-level o (inusualmente) un max-level igual o superior a la versión de FCM lanzada en esta rama, se considera una versión lanzada y actual de HAL. Por ejemplo, el HAL de displayservice se lanzó y está vigente en Android 12, como se especifica en el manifiesto del framework de Android 12.

Lanzado, pero obsoleto

En el caso de las HAL de dispositivos, la versión de HAL queda obsoleta solo si se cumplen todas las condiciones que se indican a continuación:

• Se publica.
• No está en la matriz de compatibilidad pública y fija que tiene la versión más reciente de FCM.
• Se encuentra en una matriz de compatibilidad pública y fija que el framework aún admite.

Ejemplos:

• El HAL de health@1.0 se encuentra en compatibility_matrix.legacy.xml, compatibility_matrix.1.xml y compatibility_matrix.2.xml, pero no en compatibility_matrix.3.xml. Por lo tanto, se considera obsoleto en Android 9.
• La HAL de energía tiene una actualización de versión menor en Android 9, pero power@1.0 aún está en compatibility_matrix.3.xml.
• power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml y compatibility_matrix.2.xml.
• compatibility_matrix.3.xml tiene power@1.0-1.

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

En el caso de los HAL del framework, si una versión de HAL se encuentra en el manifiesto del framework de la rama más reciente con un atributo max-level inferior a la versión de FCM que se lanzó en esta rama, se considera una versión de HAL publicada, pero obsoleta. Por ejemplo, se lanzó la HAL de schedulerservice, pero obsoleta en Android 12, como se especifica en el manifiesto del framework de Android 12.

Extraído

En el caso de los HAL de dispositivos, se quita una versión de HAL solo si se cumple lo siguiente:

• Se lanzó anteriormente.
• No se encuentra en ninguna matriz de compatibilidad pública y fija que admita el framework.

Las matrices de compatibilidad que son públicas, están inmovilizadas, pero no son compatibles con el framework, se mantienen en la base de código para definir las versiones de HAL que se quitaron, de modo que se puedan escribir las pruebas de VTS para garantizar que las HAL quitadas no estén en dispositivos nuevos.

En el caso de las HAL de framework, se quita una versión de HAL solo si se cumple lo siguiente:

• Se lanzó anteriormente.
• No está en ningún manifiesto de framework de la rama más reciente.

FCM heredados

La versión heredada de FCM objetivo es un valor especial para todos los dispositivos que no son Treble. En FCM heredado, compatibility_matrix.legacy.xml, se enumeran los requisitos del framework 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 de Treble se puede actualizar a F, siempre que el manifiesto del dispositivo sea compatible con este archivo. Su eliminación sigue el mismo procedimiento que los FCM para otras versiones de FCM de destino (se quitan después de que la cantidad de dispositivos activos anteriores a la versión 8.0 disminuye por debajo de un umbral determinado).

Versiones lanzadas de FCM

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

Para encontrar la versión de FCM que se lanzó con una versión específica de Android, consulta Level.h.