À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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é du framework (FCM), une pour chaque version cible de la FCM pouvant être mise à niveau, qui définissent ce que le framework peut utiliser et les exigences de la version cible de la FCM. 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 activer les OTA du framework uniquement dans leurs propres écosystèmes, les partenaires qui étendent les interfaces du fournisseur doivent également abandonner et supprimer les HAL HIDL en utilisant les 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 FCM de la plate-forme (S_F): Ensemble de toutes les versions FCM dans une version du framework. Le framework peut fonctionner avec n'importe quelle implémentation de fournisseur qui satisfait l'un de ces FCM.
Version FCM (F): Version la plus élevée parmi tous les FCM d'une version du framework.
Version FCM cible (V): Version FCM ciblée (à partir de S_F), déclarée explicitement dans le fichier manifeste de l'appareil, qu'une implémentation du fournisseur satisfait. Une implémentation du fournisseur doit être générée par rapport à un FCM publié, bien qu'elle puisse déclarer des versions HAL plus récentes dans son fichier manifeste de l'appareil.
Version HAL: Une version HAL est au format foo@x.y, où foo est le nom HAL et x.y est la version spécifique (par exemple, nfc@1.0, keymaster@3.0). Le préfixe racine (par exemple, android.hardware) est omis dans ce document.
Fichier manifeste de l'appareil: Fichiers XML qui spécifient les versions HAL fournies par le côté appareil de l'interface du fournisseur, y compris les images du fournisseur et de l'ODM. Le contenu d'un fichier manifeste de l'appareil est limité par la version FCM cible de l'appareil, mais peut lister les HAL qui sont strictement plus récents que le FC correspondant à V.
HAL des appareils: HAL listées (fournies) dans le fichier manifeste de l'appareil et listées 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.
Manifeste du framework: Fichier XML qui spécifie les versions HAL fournies par le côté 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 qui sont listées comme fournies 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_matrices/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 aurait généralement un niveau FCM 5, mais implémenterait un niveau FCM 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 pour Android 15 :

FCM	Version d'Android
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ées dans les niveaux FCM plus récents, à condition qu'elles soient disponibles dans la branche.

Développer dans une nouvelle version de FCM

Android incrémente la version FCM pour chaque version du framework (comme 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.

Présenter un nouveau HAL

Lors du développement, lorsque vous introduisez une nouvelle HAL (Wi-Fi, NFC, etc.) dans Android sur la version FCM actuelle F, ajoutez la HAL à 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 lors du 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 (mineur)

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

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

Par exemple, Android FCM F a introduit foo@3 comme mise à niveau mineure de la HAL. L'ancienne version, foo@2, est utilisée pour les appareils ciblant les anciennes FCM, tandis que la nouvelle version, foo@3, peut être utilisée pour les appareils ciblant les FCM Android F. L'entrée dans les anciens FCM 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 être compatible avec 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 (version majeure)

Lors du développement, lorsqu'une HAL fait l'objet d'une mise à niveau de version majeure à la version FCM actuelle F, 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 fournis avec V = F doivent être lancés avec x.0.
Avec les anciennes versions majeures dans la même balise <hal>, 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 comme mise à niveau 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 FCM précédentes. Les appareils ciblant la version F de FCM 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 ciblant la version F de FCM ne doivent pas fournir le HAL 1.0 (car ce HAL est considéré comme obsolète).
Étant donné que la HAL 1.0 est présente dans les anciennes versions de FCM, le framework peut toujours fonctionner avec la HAL 1.0. Il est donc rétrocompatible avec les anciens appareils ciblant les anciennes versions de FCM.

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 et comprend les étapes suivantes :

Assurez-vous que compatibility_matrix.F.xml possède l'attribut level="F".
Assurez-vous que tous les appareils sont compilés 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 d'expédition) ont la version FCM cible V >= F.
Publiez le fichier sur AOSP.

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

De plus, les FCM de produit et system_ext peuvent également lister les exigences pour chaque version de FCM de 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

La décision d'abandonner une version HAL appartient au développeur (c'est-à-dire que Google prend la décision pour les HAL AOSP). Cela peut se produire lorsqu'une version HAL supérieure (mineure ou majeure) est publiée.

Abandonner un HAL d'appareil

Lorsqu'un HAL foo@x.y donné est obsolète dans FCM version 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 à aucune version antérieure à x.y. Une version HAL obsolète 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 spécifique de HAL 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 plus récente (majeure ou mineure).
Le framework n'a plus besoin de la HAL.

Par exemple, dans Android 9, health@2.0 est introduit comme une mise à niveau majeure de la version 1.0 de 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 HAL de framework foo@x.y donné est obsolète dans la version FCM F, cela signifie que tout appareil lancé avec la version FCM cible V = F ou ultérieure ne doit pas s'attendre à ce que le framework fournisse foo dans la version x.y, ni dans aucune version antérieure à x.y. Une version HAL obsolète est toujours fournie par le framework pour la mise à niveau des appareils.

Lorsque la version F de FCM sera publiée, une version foo@x.y de HAL sera 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 lancés avec V = F ne doit pas lister 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 FCM introduite dans Android 11. Consultez le manifeste du framework Android 12.

Suppression de la compatibilité avec les versions FCM cibles

Lorsque le nombre d'appareils actifs d'une certaine version cible de FCM V passe en dessous d'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 qui implémentait ou dépendait 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.

Suppression des HAL entièrement obsolètes

Lorsqu'une version FCM est supprimée, certaines interfaces HAL ou versions d'interfaces HAL ne sont plus présentes dans aucun FCM. Cela signifie qu'Android ne les prend plus du tout en charge, même pour les appareils qui sont mis à niveau.

Lorsqu'une HAL n'est plus prise en charge, les développeurs suppriment les références à cette interface HAL d'Android, y compris dans le code client du framework, l'implémentation par défaut et les cas de test VTS.

S'il n'existe aucune HAL compatible héritant de la HAL supprimée, la définition de la HAL elle-même peut être supprimée en quelques étapes supplémentaires.

Supprimez la définition de l'interface HAL du code source. Cela inclut les fichiers *.aidl et le module Android.bp aidl_interface.
Si HIDL, supprimez le HASH de hardware/interfaces/current.txt.
Si vous utilisez AIDL, supprimez le répertoire aidl_api contenant les fichiers AIDL figés.
Supprimez l'interface de hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

État de la version HAL

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

Non publiées

Pour les HAL d'appareils, 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 sont disponibles que dans compatibility_matrix.F.xml. Exemples :

Lors du développement d'Android 9, la HAL health@2.0 était considérée comme une HAL non publiée et n'était présente 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 HAL ne figure que dans le fichier manifeste du framework d'une branche de développement non associée, elle est considérée comme non publiée.

Publié et actuel

Pour les HAL d'appareil, si une version HAL figure 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, la HAL health@2.0 est considérée comme une version HAL publiée et actuelle.

Si une version HAL figure dans une matrice de compatibilité publique et figée qui possède la version FCM la plus élevée, la version HAL est actuelle (c'est-à-dire qu'elle n'est pas obsolète). Par exemple, les versions HAL existantes (telles que nfc@1.0 introduites 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 se trouve dans le fichier manifeste du framework de la dernière branche publiée sans l'attribut max-level ou (exceptionnellement) 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 actuelle. Par exemple, le HAL displayservice est publié et à jour dans Android 12, comme spécifié par le manifeste du framework Android 12.

Publié, mais obsolète

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

Il est publié.
Elle ne figure pas dans la matrice de compatibilité publique et figée qui contient la version FCM la plus récente.
Il se trouve 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.
La version mineure du HAL d'alimentation a été mise à 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 actuel, mais PAS obsolète dans Android 9.

Pour les HAL de framework, si une version HAL se trouve dans le fichier manifeste du framework de la dernière branche publiée avec un attribut max-level inférieur à la version 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 d'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 et figées, mais non prises en charge par le framework, sont conservées dans la base de code pour définir l'ensemble des versions HAL supprimées. Cela permet d'écrire des tests VTS pour s'assurer que les HAL supprimées ne sont pas présentes 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 n'est présent dans aucun fichier manifeste de framework de la dernière branche publiée.

Anciennes FCM

"Version FCM cible (ancienne)" est une valeur spéciale pour tous les appareils non Treble. L'ancien 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 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 celle des FCM pour les autres versions de FCM cibles (supprimées lorsque le nombre d'appareils actifs antérieurs à la version 8.0 passe 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.