Ciclo de vida de FCM

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

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

Terminología

Desarrollo 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 la nueva compatibility_matrix.current.xml ( F ) y la 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 matriz_compatibilidad más reciente compatibility_matrix.<F-1>.xml en la 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.

Presentamos un nuevo HAL

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

• optional="false" si los dispositivos que se envían con V = F deben iniciarse con esta 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 HAL opcional. No es necesario que los dispositivos que se inicien con Android 8.1 implementen esta HAL, por lo que se agregó la siguiente entrada a compatibility_matrix.current.xml (renombrado 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>

Actualización de una HAL (menor)

Durante el desarrollo, cuando una HAL tiene una actualización de versión secundaria de xz a x.(z+1) en la versión F de 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 compatibility_matrix.current.xml debe copiar xy-z y la opción 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 secundaria de 1.0 HAL. La versión anterior, broadcastradio@1.0 , es opcional para los dispositivos que se inician con Android 8.0, mientras que la versión más nueva, broadcastradio@1.1 , es opcional para los 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 (renombrado 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>

Actualización de una HAL (principal)

Durante el desarrollo, cuando una HAL tiene una actualización de versión principal en la versión F de 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 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 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 HAL.

Por ejemplo, Android 9 presenta health@2.0 como una actualización de la versión principal de la HAL 1.0 y deja obsoleta la HAL 1.0. La versión anterior, health@1.0 , es opcional para los dispositivos que se inician con Android 8.0 y Android 8.1. Los dispositivos que se inicien con Android 9 no deben proporcionar la HAL 1.0 en desuso 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 en 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 la HAL 1.0 está presente en legacy/1/2.xml (versiones anteriores de FCM con las que puede funcionar Android 9) como una HAL opcional, el marco de trabajo de Android 9 aún puede funcionar con la HAL 1.0 (que no se considera una versión 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 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 asegurarse de que los dispositivos que se inician con el marco más reciente (según el nivel de la API de envío) tengan la versión V >= F .
6. Publicar archivo en AOSP.

Este archivo no se puede cambiar una vez renombrado y publicado. 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, se cambia el nombre de compatibility_matrix.current.xml a compatibility_matrix.3.xml y se crean los siguientes archivos 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 cada versión de FCM de la 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 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 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.

Depreciación de la versión HAL

Rechazar una versión HAL es una decisión del desarrollador (es decir, para las HAL de AOSP, 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 queda 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 de FCM, una versión de HAL foo@xy se considera obsoleta si la versión de HAL específica no se establece explícitamente en el FCM más reciente para la versión de FCM de destino V = F . 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 presenta como una actualización principal de la versión 1.0 HAL. health@1.0 se eliminó de la 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.

Desaprobar un marco HAL

Cuando un marco determinado HAL foo@xy queda 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 obsoleta de HAL 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 los dispositivos que se inician con V = F , el marco no proporciona el HAL foo@xy . La matriz de compatibilidad de dispositivos en los dispositivos que se inician con V = F no debe enumerar las HAL del marco con max-level < V .

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

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

Cuando los dispositivos activos de una determinada versión V de FCM de destino caen por debajo de un umbral determinado, la versión de FCM de destino se elimina del conjunto S _F de la próxima versión del marco. Esto se hace mediante los dos pasos siguientes:

• Eliminando la compatibility_matrix.V.xml de las reglas de compilación (para que no se instale en la imagen del sistema) y eliminando cualquier código que implementara o dependiera de la funcionalidad eliminada.
• Eliminar las HAL del marco con max-level inferior o igual a V del manifiesto del marco y eliminar cualquier código que implemente las HAL del marco eliminadas.

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

En el caso de las HAL de dispositivos, si una versión de HAL no se encuentra en ninguna de las matrices de compatibilidad públicas y congeladas, se considera que no se ha publicado y que posiblemente esté en desarrollo. Esto incluye las versiones de HAL que solo están en compatibility_matrix.current.xml . Ejemplos:

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

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

Lanzado y actual

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

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 la compatibility_matrix.current.xml ), la versión de HAL es actual (es decir, no obsoleta). Por ejemplo, las versiones de HAL existentes (como nfc@1.0 introducida en compatibility_matrix.legacy.xml ) que siguen existiendo en compatibility_matrix.3.xml también se consideran versiones de HAL publicadas y actuales.

Para las HAL del marco, si una versión HAL está en el manifiesto del 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 publicada. y la versión HAL actual. Por ejemplo, el servicio de displayservice HAL se lanzó y está actualizado en Android 12, según lo especificado por el Android 12framework manifest .

Publicado pero en desuso

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

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

Ejemplos:

• El HAL de health@1.0 está 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.
• Power HAL tiene una actualización de versión menor en Android 9, pero power@1.0 todavía está en compatibility_matrix.3.xml .
  • power@1.0 está en 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.

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

Remoto

Para las HAL de dispositivos, se elimina una versión de 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 marcos HAL, una versión HAL se elimina 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

El legado de Target FCM Version 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 (se eliminan después de que la cantidad de dispositivos activos anteriores a la 8.0 cae por debajo de cierto umbral).

Versiones lanzadas de FCM

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 .