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 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

Matriz de compatibilidad del marco (FCM)	Un archivo XML que especifica los requisitos del marco en las implementaciones de proveedores conformes. La matriz de compatibilidad está versionada y se congela una nueva versión para cada versión del marco. Cada versión del marco contiene varios FCM.
Versiones de la plataforma FCM (S _F )	El conjunto de todas las versiones de FCM en una versión de 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 objetivo de FCM (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 nuevas en su Manifiesto de dispositivo.
Versión HAL	Una versión de 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á limitado por la versión FCM de destino del dispositivo, pero puede enumerar HAL que son estrictamente más recientes en relación con el FCM correspondiente a V.
HAL del dispositivo	HAL que se enumeran (proporcionadas) en el manifiesto del dispositivo y se enumeran (obligatorias 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 Marco	Un archivo XML que especifica qué versiones de HAL proporciona el lado del marco de la interfaz del proveedor, incluido el sistema, system_ext y las imágenes del producto. Las HAL en el manifiesto del marco se deshabilitan dinámicamente de acuerdo con la versión de FCM de destino del dispositivo.
Marco HAL	HAL que se enumeran como se proporciona en el manifiesto del marco y se enumeran como obligatorios u opcionales en la matriz de compatibilidad de dispositivos (DCM).

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.F.xml 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:

Copie la compatibility_matrix.<F-1>.xml más reciente en la compatibility_matrix.F.xml .
Actualice el atributo level en el archivo a F .
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.F.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 inician con Android 8.1 implementen 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>

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

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

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.F.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.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 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:

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

Por ejemplo, las pruebas de VTS aseguran que los dispositivos que se inicien 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 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 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 . 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 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 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 versiones de HAL que solo están en compatibility_matrix.F.xml . Ejemplos:

Durante el desarrollo de Android 9, el HAL health@2.0 se consideró un HAL inédito y solo estaba presente en compatibiility_matrix.3.xml .
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 la versión 3 de FCM se congele y se publique en AOSP, la HAL health@2.0 se considera una versión 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, 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 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 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 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 .

Terminología

Matriz de compatibilidad del marco (FCM)	Un archivo XML que especifica los requisitos del marco en las implementaciones de proveedores conformes. La matriz de compatibilidad está versionada y se congela una nueva versión para cada versión del marco. Cada versión del marco contiene varios FCM.
Versiones de la plataforma FCM (S _F )	El conjunto de todas las versiones de FCM en una versión de 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 objetivo de FCM (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 nuevas en su Manifiesto de dispositivo.
Versión HAL	Una versión de 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á limitado por la versión FCM de destino del dispositivo, pero puede enumerar HAL que son estrictamente más recientes en relación con el FCM correspondiente a V.
HAL del dispositivo	HAL que se enumeran (proporcionadas) en el manifiesto del dispositivo y se enumeran (obligatorias 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 Marco	Un archivo XML que especifica qué versiones de HAL proporciona el lado del marco de la interfaz del proveedor, incluido el sistema, system_ext y las imágenes del producto. Las HAL en el manifiesto del marco se deshabilitan dinámicamente de acuerdo con la versión de FCM de destino del dispositivo.
Marco HAL	HAL que se enumeran como se proporciona en el manifiesto del marco y se enumeran como obligatorios u opcionales en la matriz de compatibilidad de dispositivos (DCM).

Desarrollo en una nueva versión de FCM

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

Copie la compatibility_matrix.<F-1>.xml más reciente en la compatibility_matrix.F.xml .
Actualice el atributo level en el archivo a F .
Agregue las reglas de compilación correspondientes para instalar esta matriz de compatibilidad en el dispositivo.

Presentamos una nueva HAL

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.

<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.F.xml debe indicar x.(z+1) y optional="false" .
No se requiere en dispositivos que se inician con V = F , la compatibility_matrix.F.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 ).

<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>

Actualización de una HAL (principal)

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.

<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 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:

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

Por ejemplo, las pruebas de VTS aseguran que los dispositivos que se inicien 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 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. 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 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

Desaprobar un dispositivo HAL

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

Desaprobar un marco HAL

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

Eliminando 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

Durante el desarrollo de Android 9, el HAL health@2.0 se consideró un HAL inédito y solo estaba presente en compatibiility_matrix.3.xml .
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

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

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.

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

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 .