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 con frameworks (FCMs), una para cada versión de FCM de destino que se pueda actualizar, que definen lo que el marco de trabajo pueda usar los requisitos de la versión de FCM. Como parte de FCM Android da de baja las HAL de HIDL y las quita y, luego, modifica los archivos de FCM para reflejar el estado de la versión del HAL

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

Terminología

Matriz de compatibilidad del marco de trabajo (FCM): Un archivo en formato XML que especifica los requisitos del marco para cumplir con los requisitos del proveedor de Google Cloud. La matriz de compatibilidad cuenta con versiones y una versión nueva se bloquea para cada versión del framework. Cada actualización del framework contiene en varios FCM.
Versiones de FCM para la plataforma (S_F): 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): La versión de FCM de destino (de S_F), declarada explícitamente en el dispositivo manifiesto, que la implementación de un proveedor satisface. La implementación de un proveedor debe ser generado para un FCM publicado, aunque puede declarar versiones más recientes de HAL en su Manifiesto del dispositivo
Versión de HAL: La versión de HAL tiene el formato foo@x.y, en el que foo es el nombre de la 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 las versiones de HAL del lado del dispositivo de la interfaz del proveedor incluidas las imágenes de proveedores y ODM que proporciona. El contenido de un manifiesto de dispositivo se está restringida por la versión de FCM de destino del dispositivo, pero puede enumerar las HAL que tienen estrictamente más reciente en relación con el FC correspondiente a V.
HAL del dispositivo: HAL que se indican (proporcionadas) en el manifiesto del dispositivo y se enumeran (opcional u obligatorio) 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 del marco de Google Cloud. Cada dispositivo contiene un DCM.
Manifiesto del framework: Un archivo en formato XML que especifica las versiones de HAL del framework del proveedor de la API de Google, incluidos system_ext y product images. HAL en el el manifiesto del framework se inhabilitan de forma dinámica según el FCM de destino del dispositivo. versión.
HAL de framework: HAL que se indican como proporcionadas en el manifiesto del framework y se enumeran como son obligatorias u opcionales 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 la manifiestos compatibles, consulta hardware/interfaces/compatibility_matrix.<FCM>.xml en la que puedes encontrar FCM system/libvintf/include/vintf/Level.h

Se espera que un dispositivo que envíe la versión de actualización de Android correspondiente tenga un valor de FCM superior o igual al nivel equivalente Por ejemplo, un el envío de dispositivos con Android 11 generalmente tendrían el nivel 5 de FCM, pero debes implementar Nivel 6 o superior de FCM, que incluye varios requisitos adicionales especificadas 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.

Desarrolla en una versión nueva de FCM

Android aumenta la versión de FCM para cada versión del framework (como Android 8 y 8.1). Durante el desarrollo, el nuevo compatibility_matrix.F.xml se creada y el compatibility_matrix.f.xml existente (donde f < F) no es ya cambió.

Para comenzar el desarrollo en una nueva versión F de FCM, sigue estos pasos:

Copia el último compatibility_matrix.<F-1>.xml en compatibility_matrix.F.xml
Actualiza el atributo level del archivo a F.
Agrega las reglas de compilación correspondientes para instalar la matriz de compatibilidad en la dispositivo.

Cómo presentar una HAL nueva

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 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. Dispositivos que se lanzan con Android 8.1 no son necesarios para implementar esta HAL, por lo que siguiente entrada se agregó a compatibility_matrix.F.xml (que solía ser llamado 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 es la siguiente:

Obligatorio en dispositivos que se lanzan con V = F y compatibility_matrix.F.xml debe indicar x.(z+1) y optional="false".
No se requiere en 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 cambia la versión a x.w-(z+1) (es decir, w >= y).

Por ejemplo, Android 8.1 introdujo broadcastradio@1.1 como una versión secundaria. actualización de 1.0 HAL. La versión anterior, broadcastradio@1.0, es opcional para dispositivos que se lanzan con Android 8.0 mientras 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 el FCM actual Versión F, la nueva versión principal x.0 se agregó a compatibility_matrix.F.xml con la siguiente configuración de optional:

optional="false" solo con la versión x.0 si los dispositivos se envían con Se debe iniciar V = F con x.0.
optional="false", pero junto con versiones principales anteriores en el mismo <hal> si los dispositivos que se envían con V = F deben iniciarse con esta HAL, pero pueden con una versión principal anterior.
optional="true" si no es necesario iniciar los dispositivos que se envían con V = F. 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. El más antiguo versión, 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 deben proporcionan la nueva versión 2.0. Por ejemplo, supongamos compatibility_matrix.legacy.xml: compatibility_matrix.1.xml y compatibility_matrix.2.xml contienen esta entrada:

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>;
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Copia esta entrada a compatibility_matrix.F.xml y modifícala como sigue:

<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", dispositivos que se lanzan con Android 9 se deben enviar con HAL 2.0.
Como la HAL 1.0 no está en compatibility_matrix.3.xml, los dispositivos que se lanzan 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 que Android 9 puede funcionar con) como una HAL opcional, el 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

El proceso de lanzamiento de una versión de FCM en la partición del sistema se realiza únicamente de Google como parte de una versión del AOSP e 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 e inicien.
Cómo actualizar las pruebas de VTS para garantizar que los dispositivos se lancen con el framework más reciente (basado en (en el nivel de la API de envío) tienen la versión de FCM objetivo V >= F.
Publica un archivo en AOSP.

Por ejemplo, pruebas de VTS garantizar que los dispositivos que se lancen con Android 9 tienen una versión de FCM objetivo igual o superior a 3.

Además, es posible que el producto y system_ext FCM también indiquen los requisitos para cada versiones de FCM de la plataforma. Lanzamiento de las versiones de FCM del producto y system_ext el propietario de estas imágenes, respectivamente. Versión de FCM los números en el producto y las particiones 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 las particiones product y system_ext refleja los requisitos de un dispositivo con la versión F de FCM 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, para las HAL del AOSP, Google toma la decisión). Esto puede ocurrir cuando una versión posterior de HAL (ya sea menor o mayor).

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 los dispositivos que se lancen con la versión V = F de FCM o una posterior implementa foo en la versión x.y o en cualquier versión anterior a x.y. Un modelo obsoleto La versión de HAL sigue siendo compatible con el framework para actualizar dispositivos.

Cuando se lanza la versión F de FCM, se considera una versión foo@x.y de HAL se dará de baja si la versión específica del HAL no se indica explícitamente en la última FCM para la versión V = F de FCM de destino Para los dispositivos que se lanzan con V = F, uno de se cumplen 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 la 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 de HAL foo@x.y determinado deja de estar disponible en la versión F de FCM, significa que los dispositivos que se lancen con la versión V = F de FCM o una posterior Se espera que el framework proporcione foo en la versión x.y o en cualquier versión anterior que el x.y. El framework aún proporciona una versión obsoleta de HAL para actualizando dispositivos.

Cuando se lanza la versión F de FCM, se considera una versión foo@x.y de HAL obsoleto si el manifiesto del framework especifica max-level="F - 1" por foo@x.y. Para los dispositivos que se lanzan con V = F, el framework no proporciona el objeto foo@x.y de HAL. El dispositivo La matriz de compatibilidad en dispositivos que se lanzan con V = F no debe enumerar el framework. HAL con max-level < V.

Por ejemplo, en Android 12, schedulerservice@1.0 es obsoleto. Su atributo max-level está configurado como 5, la versión de FCM que se introdujo en Android 11. Consulta Framework de Android 12 .

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

Cuando los dispositivos activos de cierta versión de FCM de destino V caen por debajo de un cierto la versión de FCM objetivo se quita del S_F establecido del la próxima versión del framework. Esto se hace mediante los siguientes pasos:

Quitar compatibility_matrix.V.xml de las reglas de compilación (para que no sea instalarse en la imagen del sistema) y borrar el código que implementó o dependía de las capacidades eliminadas.
Quita las HAL del framework con un max-level inferior o igual a V del el manifiesto del framework y borrar cualquier código que implemente HAL del framework.

Dispositivos con una versión de FCM de destino fuera de S_F para un framework determinado versión no se puede actualizar 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 las HAL del dispositivo, si su versión no está en la fase pública y está congelada de compatibilidad, 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 liberada y solo estaba presente en compatibility_matrix.3.xml
La HAL de teleportation@1.0 no está en ninguna matriz de compatibilidad lanzada. también se considera una HAL no publicada.

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

Lanzado y actual

En el caso de las HAL del dispositivo, si su versión es de compatibilidad pública y congelada matrix, se lanza. Por ejemplo, después de que la versión 3 de FCM se inmoviliza y se publica para 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 más alta de FCM: la versión de HAL es la actual (es decir, no es obsoleta). Para ejemplo, 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 las HAL del framework, si el manifiesto del framework incluye una versión de HAL de la rama más reciente sin el atributo max-level o (inusualmente) un max-level igual o superior a la versión de FCM que se lanzó en esta rama se considera una versión lanzada y actual de HAL. Por ejemplo, el Lanzamiento de displayservice HAL y actual en Android 12, según lo especifica el Marco de trabajo de Android 12 de Terraform.

Se lanzó, pero dejó de estar disponible

En el caso de las HALs de dispositivos, estas versiones se darán de baja solo si se cumplen las siguientes condiciones se cumplen:

Se lanza.
No se encuentra en la matriz de compatibilidad pública y inmovilizada que tiene la Versión de FCM.
Es en una matriz de compatibilidad pública y congelada que el framework aún admite.

Ejemplos:

La 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 Android 9
La HAL de energía tiene una actualización de versión secundaria en Android 9, pero power@1.0 todavía está en compatibility_matrix.3.xml
power@1.0 compatibility_matrix.legacy.xml de 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.

En el caso de las HAL del framework, si hay una versión de HAL en el manifiesto del framework de la versión rama lanzada con un atributo max-level inferior a la versión de la versión de FCM de esta rama, se considera una versión de HAL lanzada, pero obsoleta. Para Por ejemplo, se lanzó la HAL de schedulerservice, pero dejó de estar disponible en Android 12, según lo especifica el Manifiesto del framework de Android 12.

Extraído

En el caso de las HAL de dispositivos, estas versiones se quitan solo si se cumple lo siguiente: son verdaderas:

Se lanzó anteriormente.
El framework no se encuentra en ninguna matriz de compatibilidad pública ni inmovilizada. admite.

Matrices de compatibilidad que son públicas, inmovilizadas, pero que no son compatibles con el de la aplicación se mantienen en la base de código para definir las versiones de HAL que se quitaron y, de esta forma, que se puedan escribir pruebas de VTS para garantizar que las HAL que se quitaron no estén en dispositivos nuevos.

En el caso de las HAL de framework, se quita una versión de HAL siempre y cuando se cumpla lo siguiente: se cumplen:

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 heredada, 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 de Treble puede se actualizó a F siempre que el manifiesto del dispositivo sea compatible con este archivo. Es eliminación sigue el mismo procedimiento que los FCM para otras versiones de destino de FCM (se elimina después de que la cantidad de dispositivos activos anteriores a la 8.0 sea inferior a un cierto umbral).

Versiones lanzadas de FCM

Puedes encontrar la lista de las versiones lanzadas de FCM 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