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

Ciclo de vida de FCM

Una versión de marco de Android tiene varias Matrices de compatibilidad de marco (FCM), una para cada versión de Target FCM actualizable, que definen lo que puede usar el marco y los requisitos de la versión de Target FCM. Como parte del ciclo de vida FCM, desaprueba y elimina Android HIDL HAL, a continuación, modifica los archivos FCM para reflejar el estado de la versión de HAL .

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

Terminología

Matriz de compatibilidad de marcos (FCM) Un archivo XML que especifica los requisitos del marco para cumplir con las implementaciones de los proveedores. Se versiona la matriz de compatibilidad y se congela una nueva versión para cada versión del marco. Cada versión de marco contiene varios FCM.
Versiones de 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 de destino FCM (V) La versión FCM objetivo (de S F), declaró explícitamente en el manifiesto del dispositivo, que una implementación proveedor satisface. Se debe generar una implementación de proveedor contra un FCM publicado, aunque puede declarar versiones más nuevas de HAL en su Device Manifest.
Versión HAL Una versión 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 de la raíz, por ejemplo android.hardware , se omite lo largo de 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á restringido por la versión de Target FCM del dispositivo, pero puede enumerar los HAL que son estrictamente más nuevos en relación con el FCM correspondiente a V.
HAL del dispositivo HAL que se enumeran (se proporcionan) en el manifiesto del dispositivo y se enumeran (obligatorios 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 para cumplir con las implementaciones del marco. Cada dispositivo contiene un DCM.
Manifiesto del 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 e imágenes del producto. Las HAL en el manifiesto del marco se deshabilitan dinámicamente según la versión de Target FCM del dispositivo.
HAL marco HAL que se enumeran como se proporcionan en el manifiesto del marco y se enumeran como obligatorios u opcionales en la matriz de compatibilidad de dispositivos (DCM).

Desarrollando en una nueva versión de FCM

Android incrementa la versión de FCM para cada versión de marco (como Android 8, 8.1, etc.). Durante el desarrollo, el nuevo compatibility_matrix.current.xml se crea ( F ) y la existente compatibility_matrix.f.xml (donde f < F ) ya no se cambió.

Para iniciar el desarrollo de una nueva versión FCM F :

  1. Copiar la última compatibility_matrix.<F-1>.xml a compatibility_matrix.current.xml .
  2. Actualizar el level atributo en el archivo de F .
  3. Agregue las reglas de compilación correspondientes para instalar esta matriz de compatibilidad en el dispositivo.

Presentando un nuevo HAL

Durante el desarrollo, al introducir un nuevo HAL (Wi-Fi, NFC, etc.) para Android en la corriente FCM versión F , añadir el HAL a compatibility_matrix.current.xml con los siguientes optional ajustes:

  • optional="false" si los dispositivos que se suministran con V = F deben iniciar con este HAL,

    O
  • optional="true" si los dispositivos que se suministran con V = F pueden lanzar sin este HAL.

Por ejemplo, Android 8.1 introdujo cas@1.0 como HAL opcional. Artefactos de lanzamiento con Android 8.1 no están obligados a poner en práctica este HAL, por lo que la siguiente entrada se añadió a compatibility_matrix.current.xml (renombrado a compatibility_matrix.2.xml después de Android 8.1 liberado):

<hal format="hidl" optional="true">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

Actualizar un HAL (menor)

Durante el desarrollo, cuando un HAL tiene una actualización menor versión de xz a x.(z+1) a corriente FCM versión F , si esa versión es la siguiente:

  • Requerido en los dispositivos de puesta a flote con V = F , la compatibility_matrix.current.xml estado debe x.(z+1) y optional="false" .
  • No se requiere en los dispositivos de puesta a flote con V = F , la compatibility_matrix.current.xml debe copiar xy-z y opcionalidad de compatibility_matrix.<F-1>.xml y cambiar la versión a xw-(z+1) (en donde w >= y ).

Por ejemplo, Android 8.1 introducido broadcastradio@1.1 como una versión menor de actualización de 1,0 HAL. La versión más antigua, broadcastradio@1.0 , es opcional para los dispositivos de puesta a flote con Android 8.0, mientras que la versión más reciente, broadcastradio@1.1 , es opcional para los dispositivos de puesta a flote 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 copia en compatibility_matrix.current.xml (renombrado a compatibility_matrix.2.xml después de Android 8.1 liberado) y modificado 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>

Actualizar un HAL (mayor)

Durante el desarrollo, cuando un HAL tiene una importante actualización de la versión actual en el FCM versión F , la nueva versión principal x.0 se añade a compatibility_matrix.current.xml con los siguientes optional ajustes:

  • optional="false" con la versión única x.0 , si los dispositivos que se suministran con V = F debe lanzar con x.0 .
  • optional="false" pero junto con las principales versiones más antiguas de la misma <hal> etiqueta, si los dispositivos que se suministran con V = F debe iniciar con este HAL, pero puede lanzar con una gran versión más antigua.
  • optional="true" si los dispositivos que se suministran con V = F no tienen que poner en marcha el HAL.

Por ejemplo, Android 9 introduce health@2.0 como un importante-actualización de la versión 1.0 de la HAL y desaprueba la HAL 1.0. La versión más antigua, health@1.0 , es opcional para los dispositivos de puesta a flote con Android 8.0 y Android 8.1. Los dispositivos que se inician con Android 9 no deben proporcionar el HAL 1.0 obsoleto 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 a compatibility_matrix.3.xml con la liberación de Android 9) y modificado 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 el 2.0 HAL está en compatibility_matrix.3.xml con optional="false" los dispositivos, que el lanzamiento de Android 9 debe transportar con 2,0 HAL.
  • Debido a que el 1.0 HAL no está en compatibility_matrix.3.xml , dispositivos que con el lanzamiento de Android deben 9 no proporcionan la HAL 1.0 (como se considera que este HAL se use).
  • Debido a que la HAL 1.0 está presente en la versión heredada / 1 / 2.xml (versiones de FCM más antiguas 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 de 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. Cambiar el nombre de compatibility_matrix.current.xml a compatibility_matrix.F.xml .
  2. Asegúrese de que el archivo tiene el atributo level="F" .
  3. Editar correspondientes reglas de generación para reflejar el cambio de nombre de archivo.
  4. Asegúrese de que todos los dispositivos se construyan y arranquen.
  5. Actualización VTS pone a prueba para asegurar los dispositivos de puesta a flote con la última marco (según el nivel de Envío API) tienen Target FCM Versión V >= F .
  6. Publicar archivo en AOSP.

Este archivo no se puede cambiar una vez cambiado el nombre y publicado. Por ejemplo, durante el desarrollo de Android 9 los siguientes archivos se construyeron para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Cuando se libera Android 9, compatibility_matrix.current.xml se cambia el nombre a compatibility_matrix.3.xml y los siguientes archivos se construyen para hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

Pruebas VTS garantizar que los dispositivos de puesta a flote con Android tienen 9 Objetivo FCM versión> = 3.

Además, los FCM de producto y system_ext también pueden enumerar los requisitos para las versiones de FCM de cada plataforma. El propietario de estas imágenes realiza la publicación de las versiones de FCM en las particiones de producto y system_ext, respectivamente. Los números de versión de FCM en las particiones del producto y system_ext deben coincidir 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.

Desactivación de la versión HAL

Dar de baja una versión HAL es una decisión del desarrollador (es decir, para AOSP HAL, Google toma la decisión). Podría suceder cuando se lanza una versión HAL superior (ya sea menor o mayor).

Dar de baja un dispositivo HAL

Cuando un HAL dispositivo dado foo@xy está en desuso en FCM Versión F , significa que cualquier lanzamiento dispositivo con Target FCM Version V = F o posterior no debe implementar foo en versión xy o cualquier versión más antigua que xy . Una versión obsoleta de HAL todavía es compatible con el marco para actualizar dispositivos.

Cuando FCM Versión F se libera, una versión HAL foo@xy se considera obsoleto si la versión específica HAL no se indica explícitamente en la última FCM para Target FCM Versión V = F . Para los dispositivos de puesta a flote con V = F , una de las siguientes condiciones es verdadera:

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

Por ejemplo, en Android 9, health@2.0 se introduce como una actualización de versión principal de 1,0 HAL. health@1.0 se retira 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.

Dejar obsoleto un marco HAL

Cuando un marco HAL dado foo@xy está en desuso en el FCM versión F , significa que cualquier lanzamiento dispositivo con destino FCM Versión V = F o superior no debe esperar que el marco para proporcionar foo en la versión xy , o en cualquier versión anterior a la xy . El marco todavía proporciona una versión obsoleta de HAL para actualizar dispositivos.

Cuando FCM versión F se libera, un HAL Versión foo@xy se considera obsoleto si el marco especifica manifiestos max-level=" F - 1 " para foo@xy . Para los dispositivos de puesta a flote con V = F , el marco no proporciona el HAL foo@xy . La matriz de compatibilidad del dispositivo en dispositivos de lanzamiento con V = F no debe lista HAL marco con max-level < V .

Por ejemplo, en Android 12, schedulerservice@1.0 está en desuso. Su max-level atributo se establece en 5 , la versión FCM introducido en Android 11. Véase Android 12 manifiesta marco .

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

Cuando los dispositivos activos de un cierto Target FCM Version V caída por debajo de un cierto umbral, la FCM versión de destino se retira del conjunto S F de la siguiente versión marco. Esto se realiza mediante los dos pasos siguientes:

  • Extracción compatibility_matrix.V.xml de las reglas de generación (de modo que no se instala en la imagen del sistema), y eliminar cualquier código que implementa o dependía de la funcionalidad eliminado.
  • Extracción HAL marco con max-level menor que o igual a V desde el manifiesto marco, y eliminar cualquier código que implementa la HAL marco eliminados.

Los dispositivos con un objetivo FCM Version fuera de S F para un lanzamiento marco dado no puede actualizar a que la liberació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

Para los dispositivos HAL, si una versión de HAL no está en ninguna de las matrices de compatibilidad pública y congelada, se considera que no se ha publicado y posiblemente esté en desarrollo. Esto incluye versiones HAL que se encuentran sólo en compatibility_matrix.current.xml . Ejemplos:

  • Durante el desarrollo de Android 9 (antes compatibiility_matrix.current.xml se cambia el nombre a compatibility_matrix.3.xml ), el health@2.0 HAL fue considerado un HAL inédito.
  • El teleportation@1.0 HAL no se encuentra en ningún matrices de compatibilidad liberados, y también se considera un HAL inédito.

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

Lanzado y actual

Para dispositivos HAL, si una versión HAL está en cualquier matriz de compatibilidad pública y congelada, se publica. Por ejemplo, después FCM Version 3 se congela (cuando compatibiility_matrix.current.xml se cambia a compatibility_matrix.3.xml ) y publicado a AOSP, la health@2.0 HAL se considera una versión HAL liberado y actual.

Si hay una versión HAL es en una matriz pública y la compatibilidad congelada que tiene la más alta (excluyendo FCM Versión compatibility_matrix.current.xml ), la versión HAL es actual (es decir, no se use). Por ejemplo, las versiones HAL existentes (tales como nfc@1.0 introducido en compatibility_matrix.legacy.xml ) que siguen existiendo en compatibility_matrix.3.xml también son considerados como versiones HAL liberados y actuales.

Para HAL marco, si hay una versión HAL está en el manifiesto marco de la última rama en libertad sin el max-level atributo o (excepcionalmente) un max-level igual o superior a la versión FCM lanzado en esta rama, se considera una liberados y la versión actual de HAL. Por ejemplo, el displayservice HAL se libera y la corriente en Android 12, tal como se especifica por el Android 12framework manifest .

Publicado pero obsoleto

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

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

Ejemplos:

Por lo tanto power@1.0 es actual, pero no obsoleta, en Android 9.

Para HAL marco, si hay una versión HAL está en el manifiesto marco de la última rama lanzado con un max-level atributo inferior a la versión FCM lanzado en esta rama, se considera una versión liberada HAL aunque no se use. Por ejemplo, el schedulerservice HAL se libera aunque no se use en Android 12, según lo especificado por la Android 12framework manifest .

Remoto

Para los dispositivos HAL, se elimina una versión HAL si y solo si se cumple lo siguiente:

  • Fue lanzado previamente.
  • 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 para que las pruebas de VTS se puedan escribir para garantizar que las HAL eliminadas no estén en dispositivos nuevos.

Para los HAL de marco, se elimina una versión de HAL si y solo si se cumple lo siguiente:

  • Fue lanzado previamente.
  • No está en ningún manifiesto de marco de la última rama publicada.

FCM heredados

La versión heredada de Target FCM es un valor especial para todos los dispositivos que no son de agudos. El FCM legado, compatibility_matrix.legacy.xml , las listas de los requisitos del marco en los dispositivos de legado (es decir, dispositivos en marcha antes de Android 8.0).

Si existe este archivo para un FCM con la versión F , cualquier dispositivo que no sea de agudos se puede actualizar a F presentó su manifiesto del dispositivo es compatible con este archivo. Su eliminación sigue el mismo procedimiento que los FCM para otras versiones de Target FCM (eliminados después de que la cantidad de dispositivos activos anteriores a 8.0 caiga por debajo de un cierto umbral).

Versiones de FCM publicadas

La lista de las versiones liberadas FCM se puede encontrar en hardware/interfaces/compatibility_matrices .

Para encontrar la versión FCM lanzado con una versión específica de Android, consulte Level.h .