Cette page a été traduite par l'API Cloud Translation.

Cycle de vie de FCM

Une version du framework Android comporte plusieurs matrices de compatibilité de framework (FCM), une pour chaque version FCM cible pouvant être mise à niveau, qui définissent ce que le framework peut utiliser et les exigences de version de FCM cible. Dans le cadre du cycle de vie FCM, Android abandonne et supprime les HAL HIDL, puis modifie les fichiers FCM pour refléter l'état de la version HAL.

Pour permettre aux agences de voyages en ligne basées uniquement sur le framework dans leurs propres écosystèmes, les partenaires qui étendent les interfaces des fournisseurs doivent également abandonner et supprimer les HAL HIDL à l'aide des mêmes méthodes.

Terminologie

Matrice de compatibilité des frameworks (FCM): Fichier XML qui spécifie les exigences du framework concernant la conformité des implémentations des fournisseurs. La matrice de compatibilité possède plusieurs versions et une nouvelle version est figée pour chaque version du framework. Chaque version du framework contient plusieurs FCM.
Versions de la plate-forme FCM (S_F): Ensemble de toutes les versions de FCM dans une version du framework. Le framework peut fonctionner avec n'importe quelle implémentation de fournisseur répondant à l'un de ces FCM.
Version (F) de FCM: Version la plus élevée parmi tous les FCM d'une version du framework.
Version FCM cible (V): Version de FCM ciblée (à partir de S_F), déclarée explicitement dans le fichier manifeste de l'appareil, qui satisfait une implémentation de fournisseur. Une implémentation du fournisseur doit être générée par rapport à un FCM publié, bien qu'elle puisse déclarer des versions plus récentes de HAL dans son fichier manifeste d'appareil.
Version de HAL: Une version HAL se présente au format foo@x.y, où foo correspond au nom HAL et x.y à la version spécifique. Par exemple : nfc@1.0, keymaster@3.0 (le préfixe racine, par exemple android.hardware, est omis tout au long de ce document).
Fichier manifeste de l'appareil: Fichiers XML qui spécifient les versions de HAL fournies par le côté appareil de l'interface fournisseur, y compris les images du fournisseur et de l'ODM. Le contenu du fichier manifeste d'un appareil est limité par la version FCM cible de l'appareil, mais peut répertorier les HAL strictement plus récents par rapport à la FC correspondant à V.
HAL des appareils: HAL listés (fournis) dans le fichier manifeste de l'appareil et listés (obligatoires ou facultatifs) dans la matrice de compatibilité du framework (FCM).
Matrice de compatibilité des appareils (Matrice de compatibilité des appareils): Fichier XML qui spécifie les exigences des fournisseurs concernant les implémentations de framework conformes. Chaque appareil contient un seul DCM.
Fichier manifeste de framework: Fichier XML qui spécifie les versions HAL fournies par le côté framework de l'interface fournisseur, y compris les images système, system_ext et produit. Les HAL dans le fichier manifeste du framework sont désactivées de manière dynamique en fonction de la version FCM cible de l'appareil.
HAL de framework: HAL listés comme fournis dans le fichier manifeste du framework, et listés comme obligatoires ou facultatifs dans la matrice de compatibilité des appareils (DCM).

Cycle de vie de FCM dans le codebase

Ce document décrit le cycle de vie de FCM en résumé. Pour consulter les fichiers manifestes actuellement compatibles, reportez-vous à hardware/interfaces/compatibility_matrix.<FCM>.xml, où FCM est disponible dans system/libvintf/include/vintf/Level.h.

Un appareil qui distribue la version Android correspondante doit avoir une valeur FCM supérieure ou égale au niveau équivalent. Par exemple, un appareil expédié avec Android 11 disposera généralement du niveau FCM 5, mais implémentera FCM le niveau 6 ou supérieur, qui s'accompagne de diverses exigences supplémentaires spécifiées dans les matrices de compatibilité. Voici les niveaux acceptés:

FCM	Version d'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

Lorsqu'Android abandonne un niveau FCM, celui-ci reste compatible avec les appareils existants.

Développer dans une nouvelle version de FCM

Android incrémente la version de FCM pour chaque version du framework (Android 8, 8.1, etc.). Pendant le développement, le nouveau compatibility_matrix.F.xml est créé et le compatibility_matrix.f.xml existant (où f < F) n'est plus modifié.

Pour commencer à développer dans une nouvelle version de FCM F:

Copiez la dernière version de compatibility_matrix.<F-1>.xml dans compatibility_matrix.F.xml.
Dans le fichier, remplacez l'attribut level par F.
Ajoutez les règles de compilation correspondantes pour installer cette matrice de compatibilité sur l'appareil.

Présentation d'une nouvelle HAL

Pendant le développement, lorsque vous introduisez un nouveau HAL (Wi-Fi, NFC, etc.) dans Android sur la version actuelle de FCM F, ajoutez le HAL à compatibility_matrix.F.xml avec les paramètres optional suivants:

optional="false" si les appareils fournis avec V = F doivent être lancés avec ce HAL ;
optional="true" si les appareils fournis avec V = F peuvent être lancés sans ce HAL.

Par exemple, Android 8.1 a introduit cas@1.0 en tant que HAL facultatif. Les appareils lancés avec Android 8.1 ne sont pas nécessaires pour implémenter cette HAL. L'entrée suivante a donc été ajoutée à compatibility_matrix.F.xml (qui était temporairement nommé compatibility_matrix.current.xml pendant le développement de cette version):

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

Mettre à niveau un HAL (version mineure)

Pendant le développement, lorsqu'une version mineure d'un HAL passe de x.z à x.(z+1) à la version actuelle de FCM F, si cette version est:

Requis sur les appareils lancés avec V = F, compatibility_matrix.F.xml doit indiquer x.(z+1) et optional="false".
Non requis sur les appareils lancés avec V = F, le compatibility_matrix.F.xml doit copier x.y-z et l'option facultative de compatibility_matrix.<F-1>.xml et remplacer la version par x.w-(z+1) (où w >= y).

Par exemple, Android 8.1 a introduit broadcastradio@1.1 en tant que mise à niveau de version mineure de 1.0 HAL. L'ancienne version, broadcastradio@1.0, est facultative pour les appareils lancés avec Android 8.0, tandis que la version plus récente, broadcastradio@1.1, est facultative pour les appareils lancés avec Android 8.1. Dans 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>

Cette entrée a été copiée dans compatibility_matrix.F.xml et modifiée comme suit:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Mettre à niveau un HAL (version majeure)

Pendant le développement, lorsqu'un HAL fait l'objet d'une mise à niveau majeure vers la version actuelle de FCM F, la nouvelle version majeure x.0 est ajoutée à compatibility_matrix.F.xml avec les paramètres optional suivants:

optional="false" avec la version x.0 uniquement, si les appareils fournis avec V = F doivent être lancés avec x.0.
optional="false", mais avec les anciennes versions majeures dans la même balise <hal>, si les appareils fournis avec V = F doivent être lancés avec cette HAL, mais peuvent être lancés avec une ancienne version majeure.
optional="true" si les appareils fournis avec V = F n'ont pas besoin de lancer le HAL.

Par exemple, Android 9 introduit health@2.0 en tant que mise à niveau de version majeure du HAL 1.0 et abandonne l'HAL 1.0. L'ancienne version, health@1.0, est facultative pour les appareils équipés d'Android 8.0 et Android 8.1. Les appareils équipés d'Android 9 ne doivent pas fournir la version obsolète HAL 1.0, mais doivent fournir la nouvelle version 2.0. I compatibility_matrix.legacy.xml, compatibility_matrix.1.xml et 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>

Cette entrée est copiée dans compatibility_matrix.F.xml et modifiée comme suit:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Restrictions :

Étant donné que la version HAL 2.0 se trouve dans compatibility_matrix.3.xml avec optional="false", les appareils lancés avec Android 9 doivent être fournis avec la version 2.0 HAL.
Étant donné que la HAL 1.0 ne se trouve pas dans compatibility_matrix.3.xml, les appareils lancés avec Android 9 ne doivent pas fournir la HAL 1.0 (car cette HAL est considérée comme obsolète).
Étant donné que la HAL 1.0 est présente dans le fichier HAL 1.0 (anciennes versions de FCM compatibles avec Android 9) en tant que HAL facultative, le framework Android 9 peut toujours fonctionner avec la HAL 1.0 (qui n'est pas considérée comme une version de HAL supprimée).

Nouvelles versions de FCM

Le processus de publication d'une version FCM sur la partition système est effectué uniquement par Google dans le cadre d'une version AOSP. Il comprend les étapes suivantes:

Assurez-vous que compatibility_matrix.F.xml possède l'attribut level="F".
Assurez-vous que tous les appareils se créent et démarrent.
Mettez à jour les tests VTS pour vous assurer que les appareils lancés avec le dernier framework (selon le niveau d'API Shipping) disposent de la version V >= F de FCM cible.
Publier le fichier sur AOSP

Par exemple, les tests VSS garantissent que les appareils lancés avec Android 9 disposent de la version 3 de FCM cible ou d'une version ultérieure.

En outre, les FCM product et system_ext peuvent également lister les exigences pour chaque version FCM de la plate-forme. La publication des versions FCM sur les partitions product et system_ext est effectuée respectivement par le propriétaire de ces images. Les numéros de version FCM sur les partitions product et system_ext doivent correspondre à ceux de la partition système. Comme pour les versions FCM sur la partition système, la matrice de compatibilité de FCM version F dans les partitions product et system_ext reflète les exigences d'un appareil avec la version FCM cible.

Abandon de la version HAL

L'abandon d'une version HAL est une décision du développeur (c'est-à-dire que c'est Google qui décide pour les HAL AOSP). Cela peut se produire lorsqu'une version supérieure de HAL (mineur ou majeure) est publiée.

Abandonner une couche HAL d'appareil

Lorsqu'un foo@x.y d'HAL d'appareil donné est obsolète à partir de la version F de FCM, cela signifie que tout appareil lancé avec la version V = F ou ultérieure de FCM cible ne doit pas implémenter foo à la version x.y ou à toute version antérieure à x.y. Une version obsolète de HAL est toujours prise en charge par le framework pour la mise à niveau des appareils.

Lorsque la version F de FCM est publiée, une version foo@x.y de HAL est considérée comme obsolète si la version HAL spécifique n'est pas explicitement indiquée dans la dernière version de FCM pour la version FCM cible V = F. Pour les appareils lancés avec V = F, l'une des conditions suivantes est remplie:

Le framework nécessite une version supérieure (majeure ou mineure) ;
Le framework ne nécessite plus le HAL.

Par exemple, dans Android 9, health@2.0 est introduit en tant que mise à niveau de version majeure de 1.0 HAL. health@1.0 est supprimé de compatibility_matrix.3.xml, mais est présent dans compatibility_matrix.legacy.xml, compatibility_matrix.1.xml et compatibility_matrix.2.xml. Par conséquent, health@1.0 est considéré comme obsolète.

Abandon d'une HAL de framework

Lorsqu'un foo@x.y d'HAL de framework donné est obsolète à la version F de FCM, cela signifie que tout appareil lancé avec la version V = F ou ultérieure de FCM cible ne doit pas s'attendre à ce que le framework fournisse foo à la version x.y ou à toute version antérieure à x.y. Une version obsolète de HAL est toujours fournie par le framework pour la mise à niveau des appareils.

Lorsque la version F de FCM est publiée, une version foo@x.y de la HAL est considérée comme obsolète si le fichier manifeste du framework spécifie max-level="F - 1" pour foo@x.y. Pour les appareils lancés avec V = F, le framework ne fournit pas le foo@x.y HAL. La matrice de compatibilité des appareils lancés avec V = F ne doit pas répertorier les HAL du framework avec max-level < V.

Par exemple, dans Android 12, schedulerservice@1.0 est obsolète. Son attribut max-level est défini sur 5, la version de FCM introduite dans Android 11. Consultez Fichier manifeste du framework Android 12.

Suppression de la compatibilité avec les versions FCM cibles

Lorsque les appareils actifs d'une certaine version FCM cible V passent en dessous d'un certain seuil, la version FCM cible est supprimée de l'ensemble S_F de la prochaine version du framework. Pour ce faire, suivez les deux étapes ci-dessous:

Suppression de compatibility_matrix.V.xml des règles de compilation (afin qu'il ne soit pas installé sur l'image système) et suppression de tout code mis en œuvre ou dépendant de la fonctionnalité supprimée.
Suppression des HAL de framework dont la valeur max-level est inférieure ou égale à V du fichier manifeste du framework et suppression de tout code mettant en œuvre les HAL de framework supprimés.

Les appareils dont la version de FCM cible est extérieure à S_F pour une version de framework donnée ne peuvent pas être mises à niveau vers cette version.

État de la version HAL

Les sections suivantes décrivent (dans l'ordre chronologique) les états possibles d'une version de HAL.

Non publiées

Pour les HAL d'appareils, si une version HAL ne figure dans aucune des matrices de compatibilité publique et figée, elle est considérée comme non publiée et peut-être en cours de développement. Cela inclut les versions HAL uniquement disponibles dans compatibility_matrix.F.xml. Exemples :

Pendant le développement d'Android 9, le HAL health@2.0 était considéré comme une HAL non publiée et n'était présent que dans compatibility_matrix.3.xml.
Le HAL teleportation@1.0 ne figure dans aucune matrice de compatibilité publiée et est également considéré comme une HAL non publiée.

Pour les HAL de framework, si une version HAL ne figure que dans le fichier manifeste de framework d'une branche de développement non liée, elle est considérée comme non publiée.

Publié et actuel

Pour les HAL d'appareils, si une version HAL se trouve dans une matrice de compatibilité publique et figée, elle est publiée. Par exemple, une fois que la version 3 de FCM est figée et publiée sur AOSP, le HAL health@2.0 est considéré comme une version d'HAL publiée et actuelle.

Si une version de HAL se trouve dans une matrice de compatibilité publique et figée avec la version FCM la plus élevée, la version de HAL est à jour (c'est-à-dire non obsolète). Par exemple, les versions HAL existantes (telles que nfc@1.0 introduites dans compatibility_matrix.legacy.xml et qui continuent d'exister dans compatibility_matrix.3.xml) sont également considérées comme des versions HAL publiées et actuelles.

Pour les HAL de framework, si une version HAL figure dans le fichier manifeste de framework de la dernière branche publiée sans l'attribut max-level ou (anormalement) un max-level égal ou supérieur à la version de FCM publiée dans cette branche, elle est considérée comme une version publiée et actuelle de HAL. Par exemple, le HAL displayservice est publié et actuel dans Android 12, comme spécifié par le fichier manifeste du framework Android 12.

Disponible, mais obsolète

Pour les HAL d'appareils, une version HAL est obsolète si et seulement si toutes les conditions suivantes sont remplies:

Il est disponible.
Elle ne figure pas dans la matrice de compatibilité publique et figée qui possède la version de FCM la plus élevée.
Il s'agit d'une matrice de compatibilité publique et figée que le framework accepte toujours.

Exemples :

Le HAL health@1.0 se trouve dans compatibility_matrix.legacy.xml, compatibility_matrix.1.xml et compatibility_matrix.2.xml, mais pas dans compatibility_matrix.3.xml. Elle est donc considérée comme obsolète dans Android 9.
Le HAL de puissance présente une mise à niveau de version mineure sous Android 9, mais power@1.0 est toujours dans compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml et compatibility_matrix.2.xml.
compatibility_matrix.3.xml a power@1.0-1.

Par conséquent, power@1.0 est actuel, mais PAS obsolète, dans Android 9.

Pour les HAL de framework, si une version HAL figure dans le fichier manifeste de framework de la dernière branche publiée avec un attribut max-level inférieur à celui de la version de FCM dans cette branche, elle est considérée comme une version publiée, mais obsolète de HAL. Par exemple, le HAL schedulerservice est publié, mais obsolète dans Android 12, comme spécifié par le fichier manifeste du framework Android 12.

Supprimée

Pour les HAL d'appareils, une version HAL est supprimée si et seulement si les conditions suivantes sont remplies:

Il est déjà sorti.
Il ne figure dans aucune matrice de compatibilité publique et figée prise en charge par le framework.

Les matrices de compatibilité publiques, figées, mais non compatibles avec le framework, sont conservées dans le code base pour définir les versions de HAL supprimées définies. Ainsi, les tests VTS peuvent être écrits pour s'assurer que les HAL supprimées ne sont pas installées sur de nouveaux appareils.

Pour les HAL de framework, une version HAL est supprimée si et seulement si les conditions suivantes sont remplies:

Il est déjà sorti.
Il ne figure dans aucun fichier manifeste de framework de la dernière branche publiée.

Anciens FCM

L'ancienne version de FCM cible est une valeur spéciale pour tous les appareils autres que Treble. L'ancien FCM, compatibility_matrix.legacy.xml, répertorie les exigences du framework sur les anciens appareils (c'est-à-dire ceux lancés avant Android 8.0).

Si ce fichier existe pour un FCM de version F, tout appareil non-Treble peut être mis à niveau vers F à condition que son fichier manifeste soit compatible avec ce fichier. Sa suppression suit la même procédure que les FCM pour les autres versions de FCM cibles (supprimées lorsque le nombre d'appareils actifs antérieurs à la version 8.0 est passé en dessous d'un certain seuil).

Versions FCM publiées

La liste des versions FCM publiées est disponible sous hardware/interfaces/compatibility_matrices.

Pour trouver la version de FCM publiée avec une version Android spécifique, consultez Level.h.