Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

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 framework (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 de 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): La versión más alta de todos los FCM en una versión del framework.
Versión de FCM objetivo (V): La versión de FCM objetivo (de S_F), declarada explícitamente 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 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 de dispositivo está limitado por la versión de FCM objetivo del dispositivo, pero puede enumerar HAL que sean estrictamente más recientes en relación con el FC correspondiente a V.
HAL de dispositivos: HAL que se enumeran (proporcionan) en el manifiesto del dispositivo y en la matriz de compatibilidad del framework (FCM).
Matriz de compatibilidad de dispositivos (DCM): Es un archivo en formato XML que especifica los requisitos de los proveedores en las implementaciones de frameworks que cumplen con los estándares. 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 que se enumeran como proporcionados en el manifiesto del framework y 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íe la versión de lanzamiento correspondiente de Android tenga un valor de FCM mayor o igual que el 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:

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

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.

Cómo desarrollar 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:

Copia el compatibility_matrix.<F-1>.xml más reciente en compatibility_matrix.F.xml.
Actualiza el atributo level del archivo a F.
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.

Por ejemplo, Android 8.1 introdujo cas@1.0. Los dispositivos que se inician con Android 8.1 pueden 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">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Actualiza un HAL (menor)

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

Durante el desarrollo, cuando un 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, Android FCM F introdujo foo@3 como una actualización de versión menor del HAL. La versión anterior, foo@2, se usa para dispositivos segmentados para FCMs más antiguos, mientras que la versión más reciente, foo@3, se puede usar para dispositivos segmentados para F de FCM de Android. La entrada en los FCM 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 actual de FCM F, la nueva versión principal x.0 se agrega a compatibility_matrix.F.xml con la siguiente configuración:

Solo la versión x.0, si los dispositivos que se envían con V = F deben iniciarse 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 presenta 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 dispositivos segmentados para versiones anteriores de FCM. Los dispositivos orientados a 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:

Debido a que el HAL 1.0 no está en compatibility_matrix.F.xml, los dispositivos que se orientan a la versión F de FCM no deben proporcionar el HAL 1.0 (ya que se considera obsoleto).
Debido a que el HAL 1.0 está presente en versiones anteriores de FCM, el framework aún puede trabajar 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 una versión de AOSP y, además, incluye los siguientes pasos:

Asegúrate de que compatibility_matrix.F.xml tenga el atributo level="F".
Asegúrate de que todos los dispositivos se compilen y se inicien.
Actualiza las pruebas de VTS para garantizar que los dispositivos que se inicien con el framework más reciente (según el nivel de API de envío) tengan la versión objetivo de FCM V >= F.
Publica el 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 la versión F de FCM en las particiones product y system_ext refleja los requisitos de un dispositivo con la versión F de FCM objetivo.

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 de HAL superior (menor o superior).

Cómo dar de baja un HAL de dispositivo

Cuando un foo@x.y de HAL de un dispositivo 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 implementar foo en la versión x.y ni en ninguna versión 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 V = F de FCM objetivo. 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 (mayor o menor).
El framework ya no requiere el HAL.

Por ejemplo, en Android 9, se presenta health@2.0 como una actualización de versión importante de HAL 1.0. health@1.0 se quita 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 de FCM V = F o 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 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:

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
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, el HAL de 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 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 los HAL de dispositivos, si una versión de HAL se encuentra en cualquier matriz de compatibilidad pública y fija, se lanza. Por ejemplo, después de que se inmoviliza y publica la versión 3 de FCM en AOSP, el HAL de health@2.0 se considera una versión de HAL publicada y actual.

Si una versión de HAL se encuentra en una matriz de compatibilidad pública y fija 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 aún existen en compatibility_matrix.3.xml también se consideran versiones de HAL publicadas y actuales.

En el caso de los HAL de framework, si una versión de HAL está en el manifiesto del framework de la rama publicada más reciente sin el atributo max-level o (de forma inusual) un max-level igual o superior a la versión de FCM publicada en esta rama, se considera una versión de HAL publicada y actual. 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 los HAL de dispositivos, una versión de HAL deja de estar disponible solo si se cumplen todas las siguientes condiciones:

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 congelada 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 está 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, el HAL de schedulerservice se lanzó, pero dejó de estar disponible 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, inmovilizadas, pero que no son compatibles con el framework, se mantienen 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 los HAL quitados no estén en dispositivos nuevos.

En el caso de los 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 publicada 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 Treble se puede actualizar a F, siempre y cuando su manifiesto 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 de FCM publicadas

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.