Ciclo de vida de FCM

Una versión del framework de Android tiene varias matrices de compatibilidad con el framework (FCMs), una para cada versión de FCM de destino que se puede actualizar, que definen lo que puede usar el framework y los requisitos de la versión de FCM objetivo. 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 que reflejen el estado de la versión de HAL.

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

Terminología

Matriz de compatibilidad del marco de trabajo (FCM)
Archivo en formato XML que especifica los requisitos del marco de trabajo para cumplir con las implementaciones del proveedor. Se controla la versión de la matriz de compatibilidad, y se congela una versión nueva para cada actualización del framework. Cada versión del framework contiene varios FCM.
Versiones de FCM para la plataforma (SF)
Es el conjunto de todas las versiones de FCM de una actualización del marco de trabajo. El framework puede funcionar con cualquier implementación de proveedor que cumpla con 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 destino de FCM (V)
Es la versión de FCM de destino (de SF), declarada explícitamente en el manifiesto del dispositivo, que satisface una implementación de un proveedor. Se debe generar una implementación de proveedor en un FCM publicado, aunque puede declarar versiones más recientes de HAL 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 este documento).
Manifiesto del dispositivo
Archivos en formato XML que especifican las versiones de HAL que proporciona el lado del dispositivo de la interfaz del proveedor, incluidas las imágenes del proveedor y de 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 del dispositivo
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 las versiones de HAL que proporciona el lado del framework de la interfaz del proveedor, incluidos el sistema, system_ext y las imágenes de productos. Las HAL del manifiesto del framework se inhabilitan de forma dinámica según la versión de FCM de destino del dispositivo.
HAL de framework
Son las HAL que se indican como se proporciona en el manifiesto del framework y se indican como opcionales o como obligatorias en la matriz de compatibilidad de dispositivos (DCM).

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

En este documento, se describe el ciclo de vida de FCM en resumen. Para ver los manifiestos admitidos actualmente, consulta hardware/interfaces/compatibility_matrix.<FCM>.xml, en la que se encuentra 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 suele tener el nivel 5 de FCM, pero debes implementar el nivel 6 de FCM o una versión posterior, que incluye varios requisitos adicionales especificados en las matrices de compatibilidad. Los niveles admitidos son los siguientes:

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

Aunque Android dé de baja un nivel de FCM, todavía será compatible con los dispositivos existentes.

Desarrollar en una versión nueva de FCM

Android aumenta la versión de FCM para cada versión del framework (como Android 8, 8.1, etcétera). 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 el desarrollo en una nueva versión F de FCM, sigue estos pasos:

  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.

Presentamos un nuevo HAL

Durante el desarrollo, cuando introduzcas 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 con la siguiente configuración de optional:

  • Es optional="false" si los dispositivos que se envían con V = F deben iniciarse con esta HAL.
  • Es 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 una HAL opcional. No es necesario que los dispositivos que se lanzan con Android 8.1 implementen 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>

Cómo actualizar una HAL (menor)

Durante el desarrollo, cuando una 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 tiene las siguientes características:

  • Es obligatorio en los dispositivos que se lanzan con V = F, el compatibility_matrix.F.xml debe indicar x.(z+1) y optional="false".
  • No es obligatorio en los dispositivos que se lanzan 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) (es decir, w >= y).

Por ejemplo, Android 8.1 introdujo broadcastradio@1.1 como una actualización de versión secundaria de la 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>

Cómo actualizar un HAL (principal)

Durante el desarrollo, cuando una 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" solo con 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 incluyen V = F deben iniciarse con esta HAL, pero pueden hacerlo con una versión principal anterior.
  • Es optional="true" si los dispositivos que se envían con V = F no tienen que iniciar la 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 no deben proporcionar la HAL 1.0 obsoleta, sino la nueva versión 2.0. Yo 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 en compatibility_matrix.F.xml 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:

  • Como la HAL 2.0 está en compatibility_matrix.3.xml con optional="false", los dispositivos que se lanzan con Android 9 deben enviarse con HAL 2.0.
  • 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 de 1.0 (ya que esta HAL se considera obsoleta).
  • Debido a que la HAL 1.0 está presente en la versión heredada/1/2.xml (versiones anteriores de FCM con las que Android 9 puede funcionar) como una HAL opcional, el framework de Android 9 aún puede funcionar con la HAL 1.0 (que no se considera una versión de HAL eliminada).

Versiones nuevas de FCM

Solo Google realiza el proceso de lanzamiento de una versión de FCM en la partición del sistema como parte de un lanzamiento del AOSP. Además, incluye los siguientes pasos:

  1. Asegúrate de que compatibility_matrix.F.xml tenga el atributo level="F".
  2. Asegúrate de que todos los dispositivos se compilen e 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 garantizan que los dispositivos que se lanzan con Android 9 tengan la versión de FCM objetivo 3 o superior.

Además, es posible que el producto y los FCM de system_ext también indiquen los requisitos para cada versión de FCM de la plataforma. El propietario de estas imágenes realiza el lanzamiento de las versiones de FCM en el producto y las particiones de system_ext, respectivamente. Los números de versión de FCM en el producto y las particiones de 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

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

Da de baja una 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 para actualizar dispositivos todavía admite una versión obsoleta de HAL.

Cuando se lanza la versión F de FCM, la 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 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, health@2.0 se presenta como una actualización de versión principal de la 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, se considera que health@1.0 es obsoleto.

Da de baja una HAL de framework

Cuando un framework determinado de HAL 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 de destino o una posterior no debe esperar que el framework proporcione foo en la versión x.y o en una versión anterior a x.y. El framework aún proporciona una versión obsoleta de HAL para la actualización de dispositivos.

Cuando se lanza la versión F de FCM, la 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 lanzan con V = F, el framework no proporciona el objeto foo@x.y de HAL. La matriz de compatibilidad de dispositivos de los que se lanzan con V = F no debe enumerar las HAL de framework con max-level < V.

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

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

Cuando los dispositivos activos de una determinada versión de FCM de destino V dejan de estar por debajo de un umbral determinado, la versión de FCM de destino se quita del conjunto de SF de la siguiente versión del framework. Esto se hace mediante los siguientes 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 haya implementado la funcionalidad que se quitó o dependía de ella

  2. Quitar del manifiesto del framework y quitar las HAL del framework con una max-level inferior o igual a V y borrar el código que implemente las HAL del framework que se quitaron

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

Estado de la versión de HAL

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

Beta

En el caso de las HAL de dispositivos, si su versión no está en ninguna de las matrices de compatibilidad públicas y congeladas, se considera no publicada y posiblemente 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.
  • La HAL de teleportation@1.0 no se encuentra en ninguna matriz de compatibilidad lanzada y también se considera una HAL no publicada.

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

Publicada y actual

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 la versión de HAL está en una matriz de compatibilidad pública y inmovilizada 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 y que continúan 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, se lanzó la HAL de displayservice y está actual en Android 12, como se especifica en el manifiesto del framework de Android 12.

Se lanzó, pero dejó de estar disponible

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 lanza.
  • No está en la matriz de compatibilidad pública y inmovilizada que tiene la versión de FCM más alta.
  • El framework todavía es compatible con una matriz de compatibilidad pública y congelada.

Ejemplos:

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

En el caso de las HAL de 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 de esta rama, se considera una versión de HAL lanzada, 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.

Se quitó

En el caso de las 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 ni bloqueada 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 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 de destino tiene un valor especial para todos los dispositivos que no son de Treble. El FCM heredado, compatibility_matrix.legacy.xml, enumera los requisitos del framework en los dispositivos heredados (es decir, los 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 quita después de que la cantidad de dispositivos activos anteriores a la 8.0 disminuye por debajo de un umbral determinado).

Versiones lanzadas de FCM

Puedes encontrar la lista de las versiones lanzadas de FCM en hardware/interfaces/compatibility_matrices.

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