Ciclo de vida del FCM

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

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

Terminología

Matriz de compatibilidad del marco (FCM)
Un archivo XML que especifica los requisitos del marco para las implementaciones de proveedores conformes. La matriz de compatibilidad tiene versiones y se congela una nueva versión para cada versión del marco. Cada versión del marco contiene varios FCM.
Versiones de plataforma FCM (S F )
El conjunto de todas las versiones de FCM en una versión del 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 FCM de destino (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 HAL más recientes en su manifiesto de dispositivo.
Versión HAL
Una versión HAL tiene el formato foo@xy , donde foo es el nombre de 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
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 ODM. El contenido de un manifiesto de dispositivo está restringido por la versión FCM de destino del dispositivo, pero puede enumerar HAL que sean estrictamente más recientes en relación con el FC correspondiente a V.
HAL de dispositivo
HAL que se enumeran (proporcionan) en el manifiesto del dispositivo y se enumeran (ya sea obligatorios u opcionales) en la matriz de compatibilidad del marco (FCM).
Matriz de compatibilidad de dispositivos (DCM)
Un archivo XML que especifica los requisitos del proveedor sobre las implementaciones del marco conforme. Cada dispositivo contiene un DCM.
Manifiesto del marco
Un archivo XML que especifica qué versiones de HAL proporciona el lado del marco de la interfaz del proveedor, incluido el sistema, la extensión del sistema y las imágenes del producto. Los HAL en el manifiesto del marco se desactivan dinámicamente según la versión de Target FCM del dispositivo.
HAL marco
HAL que se enumeran según lo dispuesto en el manifiesto del marco y se enumeran como obligatorios u opcionales en la matriz de compatibilidad de dispositivos (DCM).

Ciclo de vida de FCM en el código base

Este documento describe el ciclo de vida de FCM en abstracto. Para ver los manifiestos actualmente admitidos, consulte hardware/interfaces/compatibility_matrix.<FCM>.xml donde se puede encontrar FCM en system/libvintf/include/vintf/Level.h .

A partir de Android 14, los niveles admitidos son:

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

Desarrollando en una nueva versión de FCM

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

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

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

Presentamos un nuevo HAL

Durante el desarrollo, al introducir un nuevo HAL (Wi-Fi, NFC, etc.) en Android en la versión F actual de FCM, agregue el HAL a compatibility_matrix.F.xml con las siguientes configuraciones 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 HAL opcional. Los dispositivos que se inician con Android 8.1 no necesitan implementar este 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>

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 actual de FCM, si esa versión es:

  • Requerido en dispositivos que se inician con V = F , el compatibility_matrix.F.xml debe indicar x.(z+1) y optional="false" .
  • No es necesario en dispositivos que se inician con V = F , el compatibility_matrix.F.xml debe copiar xy-z y la opcionalidad 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 la 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ó 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>

Actualizar 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 las siguientes configuraciones 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 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 HAL.

Por ejemplo, Android 9 presenta health@2.0 como una actualización de la versión principal de HAL 1.0 y deja obsoleto el HAL 1.0. La versión anterior, health@1.0 , es opcional para dispositivos que se inician 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. 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:

  • Debido a que HAL 2.0 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 HAL 1.0 no está en compatibility_matrix.3.xml , los dispositivos que se inician con Android 9 no deben proporcionar HAL 1.0 (ya que este HAL se considera obsoleto).
  • Debido a que HAL 1.0 está presente en Legacy/1/2.xml (versiones FCM anteriores con las que Android 9 puede funcionar) como HAL opcional, el marco de trabajo de Android 9 aún puede funcionar con HAL 1.0 (que no se considera una versión HAL eliminada). ).

Nuevas versiones de FCM

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

  1. Asegúrese de que compatibility_matrix.F.xml tenga el atributo level="F" .
  2. Asegúrese de que todos los dispositivos se construyan y arranquen.
  3. 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 la versión V >= F
  4. Publicar archivo en AOSP.

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

Además, los FCM de producto y system_ext también pueden enumerar los requisitos para cada versión de FCM de plataforma. La publicación de las versiones de FCM en las particiones product y system_ext la realiza el propietario de estas imágenes, respectivamente. Los números de versión de FCM en las particiones producto y system_ext deben coincidir con los de la partición del sistema. De manera 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 producto y system_ext refleja los requisitos en un dispositivo con la versión F de FCM de destino.

Desuso de la versión HAL

Desaprobar 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).

Desaprobar un dispositivo HAL

Cuando un dispositivo determinado HAL foo@xy 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 . El marco para actualizar dispositivos todavía admite una versión HAL obsoleta.

Cuando se lanza la versión F de 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 el FCM más reciente para la versión V = F de FCM de destino. Para dispositivos que se inician con V = F , se cumple una de las siguientes condiciones:

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

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

Desaprobar un marco HAL

Cuando un marco determinado HAL foo@xy 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 esperar que el marco proporcione foo en la versión xy , o en cualquier versión anterior a xy . El marco todavía proporciona una versión HAL obsoleta para actualizar dispositivos.

Cuando se lanza la versión F de FCM, una versión HAL foo@xy se considera obsoleta si el manifiesto del marco especifica max-level=" F - 1 " para foo@xy . Para dispositivos que se inician con V = F , el marco no proporciona HAL foo@xy . La matriz de compatibilidad de dispositivos en dispositivos que se inician con V = F no debe incluir HAL de marco con max-level < V .

Por ejemplo, en Android 12, schedulerservice@1.0 está en desuso. Su atributo max-level está establecido en 5 , la versión FCM introducida en Android 11. Consulte el manifiesto del marco de Android 12 .

Eliminación del soporte para las versiones FCM de destino

Cuando los dispositivos activos de una determinada versión V de Target FCM caen por debajo de un cierto umbral, la versión de Target FCM se elimina del conjunto S F de la siguiente versión del marco. Esto se hace mediante los dos pasos siguientes:

  1. Eliminar compatibility_matrix.V.xml de las reglas de compilación (para que no se instale en la imagen del sistema) y eliminar cualquier código que implementara o dependiera de la funcionalidad eliminada.

  2. Eliminar los HAL del marco con max-level inferior o igual a V del manifiesto del marco y eliminar cualquier código que implemente los HAL del marco eliminados.

Los dispositivos con una versión de FCM de destino fuera de SF 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

Para los dispositivos HAL, si una versión de HAL no se encuentra en ninguna de las matrices de compatibilidad públicas y congeladas, se considera inédita y posiblemente en desarrollo. Esto incluye las versiones HAL que solo se encuentran en compatibility_matrix.F.xml . Ejemplos:

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

Para los HAL de marco, si una versión de HAL solo está en el manifiesto de marco de una rama de desarrollo no relacionada, se considera inédita.

Publicado y actual

Para los dispositivos HAL, si una versión de HAL se encuentra en cualquier matriz de compatibilidad pública y congelada, se publica. Por ejemplo, después de que la versión 3 de FCM se congele y se publique en AOSP, la HAL health@2.0 se considera una versión 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, la versión de HAL es la actual (es decir, no está obsoleta). Por ejemplo, las versiones HAL existentes (como nfc@1.0 introducida en compatibility_matrix.legacy.xml que continúan existiendo en compatibility_matrix.3.xml también se consideran versiones HAL publicadas y actuales.

Para los HAL de marco, si una versión de HAL está en el manifiesto de marco de la última rama publicada sin el atributo max-level o (inusualmente) un max-level igual o superior a la versión de FCM publicada en esta rama, se considera una versión lanzada. y versión HAL actual. Por ejemplo, el displayservice HAL se lanzó y está actualizado en Android 12, según lo especificado en el manifiesto del marco de Android 12 .

Publicado pero obsoleto

Para los dispositivos HAL, una versión HAL queda obsoleta si y solo si se cumplen todos los requisitos siguientes:

  • Está liberado.
  • No está en la matriz de compatibilidad pública y congelada la 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 lo tanto, power@1.0 está vigente, pero NO obsoleto, en Android 9.

Para los HAL de marco, si hay una versión de HAL en el manifiesto de marco de la última rama publicada con un atributo max-level inferior a la versión de FCM en esta rama, se considera una versión de HAL publicada pero obsoleta. Por ejemplo, el schedulerservice HAL se lanzó pero está obsoleto en Android 12, según lo especificado en el manifiesto del marco de Android 12 .

Remoto

Para los dispositivos HAL, se elimina una versión HAL si y solo si se cumple lo siguiente:

  • Fue lanzado anteriormente.
  • 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 se puedan escribir pruebas de VTS para garantizar que las HAL eliminadas no estén en dispositivos nuevos.

Para los HAL de marco, se elimina una versión de HAL si y solo si se cumple lo siguiente:

  • Fue lanzado anteriormente.
  • No está en ningún manifiesto de marco de la última rama lanzada.

FCM heredados

La versión heredada de Target FCM es un valor especial para todos los dispositivos que no son Treble. 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 se puede actualizar 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 la cantidad de dispositivos activos anteriores a 8.0 cae por debajo de un cierto umbral).

Versiones FCM publicadas

La lista de versiones 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 .