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 (SF)
- 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)
- Es la versión de FCM de destino (de SF), declarada explícitamente en el manifiesto del dispositivo, que satisface la implementación de un 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 quefoo
es el nombre de HAL yx.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 nuevos 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) (ya sea obligatorio o opcional).
- 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. 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 HAL de
- que se indican como proporcionados en el manifiesto del framework y como obligatorios o opcionales 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 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 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 |
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.
Desarrolla 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 el desarrollo en una nueva versión F
de FCM, sigue estos pasos:
- Copia el
compatibility_matrix.<F-1>.xml
más reciente encompatibility_matrix.F.xml
. - Actualiza el atributo
level
del archivo aF
. - Agrega las reglas de compilación correspondientes para instalar esta matriz de compatibilidad en el dispositivo.
Cómo presentar una HAL nueva
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
con
la siguiente configuración de optional
:
optional="false"
si los dispositivos que se envían conV = F
deben iniciarse con este HAL- Es
optional="true"
si los dispositivos que se envían conV = F
pueden iniciarse sin esta HAL.
Por ejemplo, Android 8.1 introdujo cas@1.0
como una HAL opcional. Los dispositivos que se inician con Android 8.1 no deben 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" 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 un 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:
- Obligatorio en dispositivos que se inician con
V = F
,compatibility_matrix.F.xml
debe indicarx.(z+1)
yoptional="false"
. - No es obligatorio en dispositivos que se inician con
V = F
.compatibility_matrix.F.xml
debe copiarx.y-z
y la opcionalidad decompatibility_matrix.<F-1>.xml
y cambiar la versión ax.w-(z+1)
(dondew >= 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 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 de optional
:
optional="false"
con solo la versiónx.0
, si los dispositivos que se envían conV = F
deben iniciarse conx.0
.optional="false"
, pero junto con versiones principales anteriores en la misma etiqueta<hal>
, si los dispositivos que incluyenV = 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 conV = 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 deben proporcionar la nueva versión 2.0. Por ejemplo, supongamos que 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 en compatibility_matrix.F.xml
y modifícala 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 el HAL 2.0 está en
compatibility_matrix.3.xml
conoptional="false"
, los dispositivos que se inician con Android 9 deben enviarse con el HAL 2.0. - Como el HAL 1.0 no está en
compatibility_matrix.3.xml
, los dispositivos que se inician con Android 9 no deben proporcionar el HAL 1.0 (ya que este HAL se considera obsoleto). - Como el HAL 1.0 está presente en
legacy/1/2.xml
(versiones anteriores de FCM con las que puede funcionar Android 9) como un HAL opcional, el framework de Android 9 aún puede funcionar con el HAL 1.0 (que no se considera una versión de HAL quitada).
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, para ello, sigue los pasos que se indican a continuación:
- Asegúrate de que
compatibility_matrix.F.xml
tenga el atributolevel="F"
. - Asegúrate de que todos los dispositivos se compilen e 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 con 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 ocurrir cuando se lanza una versión de HAL superior (ya sea menor o superior).
Da de baja una 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 de FCM objetivo V = F
. 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 (principal o secundaria).
- El framework ya no requiere el HAL.
Por ejemplo, en Android 9, health@2.0
se presenta 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, se considera que health@1.0
es 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 V = F
de FCM o una 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 los 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 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. 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 haya implementado las capacidades quitadas o dependiera de ellasQuitar los HAL del framework con
max-level
inferior o igual aV
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 SF 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 encompatibility_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 está 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 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
) que siguen existiendo en compatibility_matrix.3.xml
también se consideran versiones de HAL publicadas y actuales.
En el caso de los HAL del framework, si una versión de HAL se encuentra 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, se lanzó la HAL de displayservice
y está en curso 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 si y solo si se cumplen todas las siguientes condiciones:
- Se lanza.
- No está en la matriz de compatibilidad pública y fija que tiene la versión más reciente de FCM.
- El framework todavía es compatible con una matriz de compatibilidad pública y congelada.
Ejemplos:
- El HAL de
health@1.0
se encuentra encompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ycompatibility_matrix.2.xml
, pero no encompatibility_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á encompatibility_matrix.3.xml
. power@1.0
compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
ycompatibility_matrix.2.xml
.compatibility_matrix.3.xml
tienepower@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
.