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

Cycle de vie de FCM

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

Pour activer les OTA uniquement pour le framework dans leurs propres écosystèmes, les partenaires qui étendent les interfaces du fournisseur 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 sur les implémentations de fournisseurs conformes. La matrice de compatibilité est versionnée, 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 qui répond à l'un de ces FCM.
Version du FCM (F): Version la plus élevée parmi toutes les FCM d'une version de framework.
Version cible de FCM (V): Version FCM ciblée (à partir de S_F), déclarée explicitement dans le fichier manifeste de l'appareil, que l'implémentation d'un fournisseur doit respecter. Une implémentation du fournisseur doit être générée à partir d'un FCM publié, bien qu'elle puisse déclarer des versions HAL plus récentes dans son fichier manifeste de l'appareil.
Version du HAL: Une version HAL se présente sous la forme foo@x.y, où foo est le nom du 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 dans tout ce document.
Fichier manifeste de l'appareil: qui spécifient les versions de HAL fournies par le côté de l'appareil de l'interface du fournisseur, y compris les images du fournisseur et de l'OEM. Le contenu d'un fichier manifeste d'appareil est limité par la version FCM cible de l'appareil, mais peut lister des HAL strictement plus récentes par rapport au FC correspondant à V.
HAL de l'appareil: HAL listés (fournis) dans le fichier manifeste de l'appareil et dans la matrice de compatibilité du framework (FCM).
Matrice de compatibilité des appareils (DCM): Fichier XML qui spécifie les exigences du fournisseur concernant les implémentations de framework conformes. Chaque appareil contient un DCM.
Fichier manifeste du framework: Fichier XML qui spécifie les versions HAL fournies par le côté du framework de l'interface du fournisseur, y compris les images système, system_ext et produit. Les HAL du fichier manifeste du framework sont désactivés de manière dynamique en fonction de la version FCM cible de l'appareil.
HAL de framework: HAL répertoriés comme fournis dans le fichier manifeste du framework et 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 de manière abstraite. Pour afficher les fichiers manifestes compatibles, consultez hardware/interfaces/compatibility_matrix.<FCM>.xml, où FCM se trouve dans system/libvintf/include/vintf/Level.h.

Un appareil équipé de la version Android correspondante doit avoir une valeur FCM supérieure ou égale au niveau équivalent. Par exemple, un appareil livré avec Android 11 dispose généralement du niveau 5 de FCM, mais implémente le niveau 6 ou supérieur, qui est associé à 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

Le niveau FCM est égal ou supérieur au niveau d'API du fournisseur.

Lorsqu'Android abandonne un niveau FCM, il reste compatible avec les appareils existants. Les appareils ciblant des niveaux FCM inférieurs sont implicitement autorisés à utiliser les HAL listés dans les niveaux FCM plus récents, à condition qu'ils soient disponibles dans la branche.

Développer dans une nouvelle version de FCM

Android incrémente la version FCM pour chaque version du framework (par exemple, Android 8 et 8.1). Lors du 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 FCM F:

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

Introduction d'un nouveau HAL

Lors du développement, lorsque vous introduisez un nouveau HAL (Wi-Fi, NFC, etc.) sur Android avec la version actuelle de FCM F, ajoutez-le à compatibility_matrix.F.xml.

Par exemple, Android 8.1 a introduit cas@1.0. Les appareils lancés avec Android 8.1 peuvent implémenter ce HAL. L'entrée suivante a donc été ajoutée à compatibility_matrix.F.xml (qui s'appelait temporairement compatibility_matrix.current.xml pendant le développement de cette version):

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

Mettre à niveau un HAL (version mineure)

Les versions HAL AIDL sont considérées comme des versions mineures de HAL. Les versions d'interface HIDL comportent des versions major.minor telles que 1.2.

Lors du développement, lorsqu'une version HAL AIDL passe de 2 à 3 avec la version FCM actuelle F, la nouvelle version est ajoutée à l'entrée HAL dans compatibility_matrix.F.xml. Le champ de version d'une entrée HAL accepte des plages telles que 2-3.

Par exemple, Android FCM F a introduit foo@3 en tant que mise à niveau de version mineure de l'HAL. L'ancienne version, foo@2, est utilisée pour les appareils ciblant d'anciennes versions de FCM, tandis que la nouvelle version, foo@3, peut être utilisée pour les appareils ciblant Android FCM F. L'entrée dans les FCM plus anciens avant la version 2 se présente comme suit:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Cette entrée a été copiée dans compatibility_matrix.F.xml et modifiée pour prendre en charge la version 3 comme suit:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Mettre à niveau un HAL (majeur)

Lors du développement, lorsqu'une HAL est mise à niveau vers la version majeure F de FCM, la nouvelle version majeure x.0 est ajoutée à compatibility_matrix.F.xml avec les paramètres suivants:

Seule la version x.0, si les appareils livrés avec V = F doivent se lancer avec x.0.
Avec les anciennes versions majeures de la même balise <hal>, si les appareils livrés avec V = F peuvent être lancés avec une ancienne version majeure.

Par exemple, la version F de FCM introduit foo@2.0 en tant que mise à niveau de la version majeure de la HAL 1.0 et abandonne la HAL 1.0. L'ancienne version, foo@1.0, est utilisée pour les appareils ciblant les versions précédentes de FCM. Les appareils ciblant la version FCM F doivent fournir la nouvelle version 2.0 s'ils fournissent le HAL. Dans cet exemple, les versions précédentes de FCM contiennent cette entrée:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Copiez cette entrée dans compatibility_matrix.F.xml et modifiez-la comme suit:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Restrictions :

Étant donné que le HAL 1.0 ne se trouve pas dans compatibility_matrix.F.xml, les appareils qui ciblent la version FCM F ne doivent pas fournir le HAL 1.0 (car ce HAL est considéré comme obsolète).
Étant donné que le HAL 1.0 est présent dans les anciennes versions de FCM, le framework peut toujours fonctionner avec le HAL 1.0, ce qui le rend rétrocompatible avec les anciens appareils qui ciblent les anciennes versions de FCM.

Nouvelles versions de FCM

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

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

Par exemple, les tests VTS garantissent que les appareils lancés avec Android 9 ont une version FCM cible 3 ou supérieure.

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

Abandon de la version HAL

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

Abandonner un HAL d'appareil

Lorsqu'un HAL foo@x.y d'appareil donné est obsolète à la version FCM F, cela signifie que tout appareil lancé avec la version cible FCM V = F ou ultérieure ne doit pas implémenter foo à la version x.y ni à une version antérieure à x.y. Une version obsolète du 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 cible de FCM 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 (majeur ou mineure).
Le framework n'a plus besoin du HAL.

Par exemple, dans Android 9, health@2.0 est introduit comme mise à niveau majeure de la version 1.0 du 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.

Abandonner un HAL de framework

Lorsqu'un foo@x.y HAL de framework donné est obsolète à la version FCM F, cela signifie que tout appareil lancé avec la version cible FCM V = F ou ultérieure ne doit pas s'attendre à ce que le framework fournisse foo à la version x.y ou à une version antérieure à x.y. Une version obsolète du 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 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 HAL foo@x.y. La matrice de compatibilité des appareils sur les appareils lancés avec V = F ne doit pas lister les HAL de 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 FCM introduite dans Android 11. Consultez le fichier manifeste du framework Android 12.

Abandon de la prise en charge des versions FCM cibles

Lorsque le nombre d'appareils actifs d'une certaine version cible de FCM V passe sous un certain seuil, la version cible de FCM est supprimée de l'ensemble S_F de la prochaine version du framework. Pour ce faire, procédez comme suit:

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 implémentant ou dépendant des fonctionnalités supprimées.
Suppression des HAL de framework avec max-level inférieur ou égal à V du fichier manifeste du framework, et suppression de tout code implémentant les HAL de framework supprimés.

Les appareils dont la version FCM cible est en dehors de S_F pour une version de framework donnée ne peuvent pas passer à cette version.

État de la version HAL

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

Non publiées

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

Lors du développement d'Android 9, le HAL health@2.0 était considéré comme un HAL non publié 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 un HAL non publié.

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

Versions publiées et à jour

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

Si une version HAL figure dans une matrice de compatibilité publique et figée qui comporte la version FCM la plus élevée, la version HAL est à jour (c'est-à-dire non obsolète). Par exemple, les versions HAL existantes (telles que nfc@1.0 introduite dans compatibility_matrix.legacy.xml) 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 du framework de la dernière branche publiée sans l'attribut max-level ou (de manière inhabituelle) avec un max-level égal ou supérieur à la version FCM publiée dans cette branche, elle est considérée comme une version HAL publiée et à jour. Par exemple, le HAL displayservice est publié et à jour dans Android 12, comme spécifié par le fichier manifeste du framework Android 12.

Publié, mais obsolète

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

Il est publié.
La version FCM la plus élevée ne figure pas dans la matrice de compatibilité publique et figée.
Il figure dans une matrice de compatibilité publique et figée que le framework prend toujours en charge.

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 d'alimentation a été mis à niveau dans 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 contient power@1.0-1.

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

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

Supprimée

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

Il a déjà été publié.
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 codebase pour définir l'ensemble des versions HAL supprimées afin que des tests VTS puissent être écrits pour s'assurer que les HAL supprimées ne se trouvent pas sur les nouveaux appareils.

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

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

Anciens FCM

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

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

Versions FCM publiées

La liste des versions FCM publiées se trouve sous hardware/interfaces/compatibility_matrices.

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