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 el framework puede usar 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 las OTA solo de framework en sus propios ecosistemas, los socios que extiendan las interfaces del proveedor también deben dejar de usar y quitar los HAL de HIDL con los mismos métodos.

Terminología

Matriz de compatibilidad del framework (FCM)
Es un archivo XML que especifica los requisitos del framework en las implementaciones de proveedores que cumplen con los requisitos. La matriz de compatibilidad tiene versiones, y se congela una versión nueva para cada lanzamiento del framework. Cada versión del framework contiene varios FCM.
Versiones de FCM de la plataforma (SF)
Es el conjunto de todas las versiones de FCM en una versión del framework. El framework puede funcionar con cualquier implementación del proveedor que satisfaga uno de estos FCM.
Versión de FCM (F)
Es la versión más alta entre todos los FCM en un lanzamiento de framework.
Versión de FCM objetivo (V)
Versión de FCM objetivo (de SF), declarada de forma explícita en el manifiesto del dispositivo, que satisface una implementación del proveedor. Se debe generar una implementación del proveedor en función de un FCM publicado, aunque puede declarar versiones de HAL más recientes en su manifiesto del dispositivo.
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 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 HALs que son estrictamente más recientes en relación con el FC correspondiente a V.
HALs de dispositivos
HALs que se enumeran (proporcionan) en el manifiesto del dispositivo y en la matriz de compatibilidad del marco de trabajo (FCM).
Matriz de compatibilidad de dispositivos (DCM)
Es un archivo XML que especifica los requisitos del proveedor en las implementaciones del framework conforme. Cada dispositivo contiene un DCM.
Manifiesto del framework
Es un archivo XML que especifica qué versiones de HAL proporciona el lado del framework de la interfaz del proveedor, incluidas las imágenes de system, system_ext y product. Los HALs del manifiesto del framework se inhabilitan de forma dinámica según la versión de FCM de destino del dispositivo.
HALs del framework
HALs que se indican como proporcionados en el manifiesto del framework y que se enumeran 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 de forma abstracta. Para ver los manifiestos admitidos, consulta hardware/interfaces/compatibility_matrices/compatibility_matrix.<FCM>.xml, donde se puede encontrar FCM en system/libvintf/include/vintf/Level.h.

Se espera que un dispositivo que incluya la versión de lanzamiento de Android correspondiente tenga un valor de FCM mayor o igual que el nivel equivalente. Por ejemplo, un dispositivo que se envía con Android 11 generalmente tendrá el nivel 5 de FCM, pero implementará el nivel 6 o superior de FCM, que incluye varios requisitos adicionales especificados en las matrices de compatibilidad. Los niveles admitidos para Android 15 son los siguientes:

FCM Versión de Android
5 Android 11/R
6 Android 12/S
7 Android 13/T
8 Android 14/U
202404 Android 15/V

El nivel de FCM es igual o más reciente que el nivel de API del proveedor.

Cuando Android deja de admitir un nivel de FCM, este sigue siendo compatible con los dispositivos existentes. Los dispositivos que segmentan niveles de FCM inferiores tienen permiso implícito para usar los HAL que se indican en los niveles de FCM más recientes, siempre y cuando estén disponibles en la rama.

Desarrolla en una nueva versión de FCM

Android incrementa la versión de FCM para cada lanzamiento del framework (como Android 8 y 8.1). Durante el desarrollo, se crea el nuevo compatibility_matrix.F.xml 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 compatibility_matrix.<F-1>.xml más reciente en compatibility_matrix.F.xml.
  2. Actualiza el atributo level en el 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 se introduce una nueva HAL (Wi-Fi, NFC, etc.) en Android en la versión actual de FCM F, agrega la HAL a compatibility_matrix.F.xml.

Por ejemplo, Android 8.1 introdujo cas@1.0. Los dispositivos que se lancen con Android 8.1 pueden implementar esta HAL, por lo que se agregó la siguiente entrada a compatibility_matrix.F.xml (que se denominó compatibility_matrix.current.xml temporalmente durante el desarrollo de esa versión):

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

Actualiza un HAL (secundario)

Las versiones de HAL de AIDL se consideran versiones secundarias de HAL. Las versiones de la interfaz HIDL tienen versiones de major.minor, como 1.2.

Durante el desarrollo, cuando una HAL de AIDL tiene una actualización de versión de 2 a 3 en la versión actual de FCM F, la versión nueva se agrega a la entrada de HAL en compatibility_matrix.F.xml. El campo de versión de una entrada de HAL acepta rangos como 2-3.

Por ejemplo, el FCM de Android F introdujo foo@3 como una actualización de versión secundaria del HAL. La versión anterior, foo@2, se usa para los dispositivos que segmentan versiones anteriores de FCM, mientras que la versión más reciente, foo@3, se puede usar para los dispositivos que segmentan la versión F de FCM para Android. La entrada en los FCMs anteriores a la versión 2 se ve de la siguiente manera:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Esta entrada se copió en compatibility_matrix.F.xml y se modificó para admitir la versión 3 de la siguiente manera:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</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 F actual de FCM, la nueva versión principal x.0 se agrega a compatibility_matrix.F.xml con los siguientes parámetros de configuración:

  • Solo la versión x.0, si los dispositivos que se envían con V = F deben lanzarse con x.0.
  • Con versiones principales anteriores en la misma etiqueta <hal>, si los dispositivos que se envían con V = F pueden iniciarse con una versión principal anterior.

Por ejemplo, la versión F de FCM introduce foo@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, foo@1.0, se usa para los dispositivos que segmentan versiones anteriores de FCM. Los dispositivos que segmentan la versión F de FCM deben proporcionar la nueva versión 2.0 si proporcionan el HAL. En este ejemplo, las versiones anteriores de FCM contienen esta entrada:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Copia esta entrada en compatibility_matrix.F.xml y modifícala de la siguiente manera:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Restricciones:

  • Dado que la HAL 1.0 no está en compatibility_matrix.F.xml, los dispositivos que segmentan la versión F de FCM no deben proporcionar la HAL 1.0 (ya que se considera obsoleta).
  • Dado que el HAL 1.0 está presente en versiones anteriores de FCM, el framework aún puede funcionar con el HAL 1.0, por lo que es retrocompatible con dispositivos antiguos que se orientan a versiones anteriores de FCM.

Nuevas versiones 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 un lanzamiento del AOSP, y este incluye los siguientes pasos:

  1. Asegúrate de que el 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 garantizar que los dispositivos que se lancen con el framework más reciente (según el nivel de API de envío) tengan la versión de FCM objetivo V >= F.
  4. Publica el archivo en AOSP.

Por ejemplo, las pruebas de VTS garantizan que los dispositivos que se lanzan con Android 9 tengan la versión de FCM de destino >= 3.

Además, los FCMs de product y system_ext también pueden enumerar 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 product y system_ext deben coincidir con los de la partición system. Al igual que 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.

Baja de la versión del HAL

La baja de una versión de HAL es una decisión del desarrollador (es decir, en el caso de los HAL de AOSP, Google toma la decisión). Esto podría ocurrir cuando se lanza una versión de HAL superior (ya sea secundaria o principal).

Cómo dejar de usar un HAL de dispositivo

Cuando un HAL de dispositivo determinado foo@x.y 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 objetivo o una posterior no debe implementar foo en la versión x.y ni en ninguna versión anterior a x.y. El framework sigue admitiendo una versión de HAL obsoleta para actualizar dispositivos.

Cuando se lanza la versión F de FCM, se considera que la versión foo@x.y de HAL está obsoleta si la versión específica de HAL no se indica explícitamente en la versión más reciente de FCM para la versión V = F de FCM de destino. En el caso de los dispositivos que se lanzan 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 la HAL.

Por ejemplo, en Android 9, se introduce health@2.0 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 dejar de utilizar un HAL de framework

Cuando un HAL de framework determinado foo@x.y se deja de usar en la versión F de FCM, significa que ningún dispositivo que se lance con la versión V = F o posterior de FCM objetivo debe esperar que el framework proporcione foo en la versión x.y o en cualquier versión anterior a x.y. El framework sigue proporcionando una versión de HAL obsoleta para actualizar los dispositivos.

Cuando se lanza la versión F de FCM, se considera que la versión foo@x.y de HAL está obsoleta si el manifiesto del framework especifica max-level="F - 1" para foo@x.y. En el caso de los dispositivos que se lanzan con V = F, el framework no proporciona el HAL foo@x.y. La matriz de compatibilidad de dispositivos que se lancen con V = F no debe incluir HALs 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.

Se quitó la compatibilidad con las versiones de FCM de destino

Cuando los dispositivos activos de una determinada versión de FCM objetivo V caen por debajo de un umbral determinado, la versión de FCM objetivo se quita del conjunto SF de la próxima versión del framework. Esto se logra con los dos pasos siguientes:

  1. Se quitó compatibility_matrix.V.xml de las reglas de compilación (para que no se instale en la imagen del sistema) y se borró cualquier código que implementara o dependiera de las capacidades quitadas.

  2. Quita los HALs del framework con max-level menor o igual que V del manifiesto del framework y borra cualquier código que implemente los HALs del framework quitados.

Los dispositivos con una versión de FCM objetivo fuera de SF para una versión de framework determinada no se pueden actualizar a esa versión.

Se quitaron los HALs completamente obsoletos

Cuando se quita una versión de FCM, algunas interfaces HAL o versiones de interfaces HAL ya no están presentes en ningún FCM. Esto significa que Android ya no los admite en absoluto, ni siquiera para actualizar dispositivos.

Después de que una HAL deja de ser compatible, los desarrolladores quitan las referencias a esa interfaz de HAL de Android, incluido el código de cliente en el framework, la implementación predeterminada y los casos de prueba de VTS.

Si no hay HALs compatibles que hereden del HAL que se quita, la definición del HAL se puede quitar con algunos pasos adicionales.

  1. Quita la definición de la interfaz del HAL del código fuente. Esto incluye los archivos *.aidl y el módulo Android.bp aidl_interface.
  2. Si es HIDL, quita el HASH de hardware/interfaces/current.txt.
  3. Si es AIDL, quita el directorio aidl_api con los archivos AIDL congelados.
  4. Quita la interfaz de hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

Estado de la versión del 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 del HAL no se encuentra en ninguna de las matrices de compatibilidad públicas y congeladas, se considera que no se lanzó y que posiblemente 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, el HAL health@2.0 se consideró un HAL sin publicar 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 no publicado.

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

Lanzada y actual

En el caso de las HAL de dispositivos, si una versión de HAL se encuentra en alguna matriz de compatibilidad pública y congelada, se lanza. Por ejemplo, después de que se congeló y publicó la versión 3 de FCM en AOSP, el HAL health@2.0 se considera una versión de HAL actual y publicada.

Si una versión de HAL se encuentra en una matriz de compatibilidad pública y congelada que tiene la versión de FCM más alta, la versión de HAL es 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 lanzadas y actuales.

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

Se lanzó, pero se dejó de usar

En el caso de los HAL de dispositivos, una versión de HAL se considera obsoleta si y solo si se cumplen todas las siguientes condiciones:

  • Se lanzó.
  • No se encuentra en la matriz de compatibilidad pública y congelada que tiene la versión de FCM más alta.
  • Se encuentra en una matriz de compatibilidad pública y congelada que el framework aún admite.

Ejemplos:

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

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

Extraído

En el caso de las HAL de dispositivos, se quita una versión de HAL si y solo si se cumplen las siguientes condiciones:

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

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

En el caso de las HAL del framework, se quita una versión de HAL solo si se cumplen las siguientes condiciones:

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

FCM heredadas

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

Versiones de FCM publicadas

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

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