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 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é 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 qui répond à l'un de ces FCM.
Version du FCM (F): Version la plus élevée de tous les FCM d'une version du 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 de 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 listés (obligatoires ou facultatifs) 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 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 la 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, celui-ci 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 de 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 HAL à compatibility_matrix.F.xml avec les paramètres optional suivants:

optional="false" si les appareils livrés 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 tenus d'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" 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)

Lors du développement, lorsqu'une HAL passe d'une version mineure x.z à une version mineure x.(z+1) avec la version FCM actuelle F, si cette version est:

Obligatoire sur les appareils lancés avec V = F, compatibility_matrix.F.xml doit indiquer x.(z+1) et optional="false".
Non obligatoire sur les appareils lancés avec V = F, compatibility_matrix.F.xml doit copier x.y-z et l'optionnalité 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 la HAL 1.0. 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 (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 optional suivants:

optional="false" avec la version x.0 uniquement, si les appareils livrés avec V = F doivent être lancés avec x.0.
optional="false", mais avec d'anciennes versions majeures dans la même balise <hal>, si les appareils livrés avec V = F doivent être lancés avec ce HAL, mais peuvent être lancés avec une version majeure plus ancienne.
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 vers une version majeure du HAL 1.0 et abandonne l'HAL 1.0. La version antérieure, health@1.0, est facultative pour les appareils lancés avec Android 8.0 et Android 8.1. Les appareils équipés d'Android 9 doivent disposer de la nouvelle version 2.0. Par exemple, supposons que compatibility_matrix.legacy.xml, compatibility_matrix.1.xml et compatibility_matrix.2.xml contiennent cette entrée:

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>;
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Copiez cette entrée dans compatibility_matrix.F.xml et modifiez-la 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 le HAL 2.0 se trouve dans compatibility_matrix.3.xml avec optional="false", les appareils lancés avec Android 9 doivent être livrés avec le HAL 2.0.`
Étant donné que le HAL 1.0 ne figure pas dans compatibility_matrix.3.xml, les appareils qui démarrent avec Android 9 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 legacy/1/2.xml (anciennes versions de FCM compatibles avec Android 9) en tant que HAL facultatif, le framework Android 9 peut toujours fonctionner avec le HAL 1.0 (qui n'est pas considéré comme une version de HAL supprimée).

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 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 qui démarrent avec le dernier framework (basé sur le niveau d'API de distribution) 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 une couche HAL d'appareil

Lorsqu'un foo@x.y d'HAL d'appareil 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 implémenter foo à la version x.y ou à toute 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.

Abandon d'une 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 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 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.

Suppression de la compatibilité avec les 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 mis en œuvre ou dépendant des capacité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 une HAL non publiée.

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 qu'elle n'est pas 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 actuel dans Android 12, comme spécifié dans 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 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 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 compatible avec 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 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.