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é des frameworks (une pour chaque version FCM cible pouvant être mise à niveau), qui définissent ce que que le framework peut utiliser et les exigences de version de FCM cible. Dans le cadre de FCM cycle de vie, Android abandonne et supprime les HAL HIDL, puis modifie les fichiers FCM pour reflètent l'état de la version du HAL.

Pour permettre aux agences de voyage en ligne basées uniquement sur le framework dans leurs propres écosystèmes, les partenaires qui étendent les interfaces des fournisseurs devraient également abandonner et supprimer les HAL HIDL en utilisant le même méthodes.

Terminologie

Matrice de compatibilité des frameworks (FCM): Fichier XML qui spécifie les exigences du framework concernant la conformité du fournisseur mises en œuvre. La matrice de compatibilité comporte 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 cadre peut fonctionner avec toute implémentation de fournisseur qui satisfait 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 l'appareil manifeste, satisfait à l'implémentation d'un fournisseur. L'implémentation d'un fournisseur doit être généré pour un FCM publié, bien qu'il puisse déclarer des versions HAL plus récentes dans ses Fichier manifeste de l'appareil.
Version de HAL: Une version HAL se présente au format foo@x.y, où foo correspond au nom HAL et x.y au nom la version spécifique ; Ex. : nfc@1.0, keymaster@3.0 (préfixe racine, par exemple android.hardware, est omis tout au long de ce document.)
Fichier manifeste de l'appareil: fichiers XML spécifiant les versions HAL côté appareil de l'interface du fournisseur y compris les images du fournisseur et de l'ODM. Le contenu d'un fichier manifeste d'appareil est limité par la version FCM cible de l'appareil, mais peut répertorier les HAL qui sont strictement plus récent que le FC correspondant à V.
HAL des appareils: HAL listés (fournis) dans le fichier manifeste de l'appareil et répertoriés (obligatoire ou facultatif) 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 en ce qui concerne le framework de conformité mises en œuvre. Chaque appareil contient un seul DCM.
Fichier manifeste de framework: Fichier XML spécifiant les versions HAL du côté framework du fournisseur , y compris les images système, system_ext et produit. HAL dans le manifestes du framework sont désactivés dynamiquement en fonction du FCM cible de l'appareil version.
HAL de framework: HAL listés comme fournis dans le fichier manifeste du framework et listés comme obligatoire ou facultative dans la matrice de compatibilité des appareils (CM).

Cycle de vie de FCM dans le codebase

Ce document décrit le cycle de vie de FCM en résumé. Pour afficher les fichiers manifestes pris en charge, reportez-vous hardware/interfaces/compatibility_matrix.<FCM>.xml où FCM est disponible 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 Appareils livrés avec Android 11 généralement dotés du niveau 5 de FCM, FCM 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 FCM pour chaque version du framework (par exemple, Android 8 et 8.1). Pendant le développement, le nouveau compatibility_matrix.F.xml est créé et le compatibility_matrix.f.xml existant (où f < F) n'est pas n'ont plus changé.

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é appareil.

Lancer une nouvelle HAL

Pendant le développement, lorsque vous introduisez un nouveau HAL (Wi-Fi, NFC, etc.) sur 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. Appareils avec Android 8.1 ne sont pas nécessaires pour implémenter cette HAL. l'entrée suivante a été ajoutée à compatibility_matrix.F.xml (qui était auparavant nommé compatibility_matrix.current.xml temporairement pendant le développement sortie):

<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:

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

Par exemple, Android 8.1 a introduit broadcastradio@1.1 en tant que version mineure. une mise à niveau de la version 1.0 HAL. L'ancienne version, broadcastradio@1.0, est facultative pour les appareils équipés d'Android 8.0 alors que la version la plus récente, broadcastradio@1.1 est facultatif 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 vers une version majeure dans FCM actuel. Version F, la nouvelle version majeure x.0 est ajoutée à compatibility_matrix.F.xml avec les paramètres optional suivants:

optional="false" uniquement avec la version x.0, si les appareils livrés avec V = F doit être lancé avec x.0.
optional="false", mais avec les anciennes versions majeures dans le même <hal> , si les appareils livrés avec V = F doivent être lancés avec ce HAL, mais peuvent être lancés avec une ancienne version majeure.
optional="true" si les appareils livrés avec V = F ne doivent pas être lancés le HAL.

Par exemple, Android 9 introduit health@2.0 en tant que mise à niveau vers une version majeure du HAL 1.0 et abandon de l'HAL 1.0. Les plus anciens la 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 doivent fournir la nouvelle version 2.0. Par exemple, supposons que compatibility_matrix.legacy.xml compatibility_matrix.1.xml 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 en tant que ce qui 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 :

Parce que le HAL 2.0 se trouve dans compatibility_matrix.3.xml avec optional="false", appareils équipés d'Android 9 doit être expédié avec 2.0 HAL.
Comme le HAL 1.0 ne se trouve pas dans compatibility_matrix.3.xml, les appareils lancés avec Android 9 ne doivent pas la version HAL 1.0 (étant donné que cette HAL est considérée comme obsolète).
Étant donné que la version HAL 1.0 est présente dans legacy/1/2.xml (les anciennes versions de FCM qui compatible avec Android 9) en tant que HAL facultative, le Le framework Android 9 peut toujours fonctionner avec le HAL 1.0. (qui n'est pas considéré comme une version HAL supprimée).

Nouvelles versions de FCM

Le processus de publication d'une version FCM sur la partition système se fait 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 se créent et démarrent.
Mettre à jour les tests VTS pour s'assurer que les appareils sont équipés du dernier framework au niveau de l'API Shipping) sont associées à la version FCM cible V >= F.
Publier le fichier sur AOSP

Par exemple, tests VSS. vous assurer que les appareils équipés d'Android 9 ont une version FCM cible 3 ou supérieure.

En outre, les composants FCM product et system_ext peuvent également lister les exigences pour chaque de la plate-forme FCM. Publication des versions de FCM sur le produit et le champ system_ext par le propriétaire de ces images, respectivement. Version de FCM les numéros des partitions product et system_ext doivent correspondre à ceux de la partition système. Comme pour les versions de FCM sur la partition du système, le matrice de compatibilité de FCM version F dans les partitions product et system_ext reflète les exigences sur un appareil équipé de FCM version F cible ;

Abandon de la version HAL

Il appartient aux développeurs de décider d'abandonner une version HAL (par exemple, pour les HAL AOSP, prend la décision). Cela peut se produire lorsqu'une version supérieure de HAL (mineur ou majeur) est publiée.

Abandonner une couche HAL d'appareil

Lorsqu'un élément HAL foo@x.y donné d'un appareil est obsolète à la version F de FCM, cela signifie que les appareils lancés avec la version V = F ou ultérieure de FCM cible ne doivent pas implémenter foo en version x.y ou toute version antérieure à x.y. Une version obsolète La version HAL est toujours compatible avec le framework pour la mise à niveau des appareils.

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

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

Par exemple, sous Android 9, health@2.0 est introduit. comme une mise à niveau de version majeure de 1.0 HAL. health@1.0 a été supprimé de compatibility_matrix.3.xml, mais est présent dans compatibility_matrix.legacy.xml compatibility_matrix.1.xml, et compatibilité_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 de l'HAL de framework donné est obsolète à la version F de FCM, cela signifie que les appareils lancés avec la version V = F ou ultérieure de FCM cible ne doivent pas Attendez-vous à ce que le framework fournisse foo à la version x.y ou à toute version antérieure que 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 HAL est considérée comme 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. L'appareil La matrice de compatibilité sur les appareils lancés avec V = F ne doit pas répertorier le framework HAL avec max-level < V.

Par exemple, sous Android 12, schedulerservice@1.0 est obsolète. Son attribut max-level est défini sur 5, la version de FCM introduite sur Android 11. Voir Framework Android 12 fichier manifeste.

Suppression de la compatibilité avec les versions FCM cibles

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

Supprimer compatibility_matrix.V.xml des règles de compilation (afin qu'il ne soit pas installé sur l'image système) et supprimer tout code qui implémente ou dépendaient des capacités supprimées.
Suppression des HAL du framework avec une max-level inférieure ou égale à V le fichier manifeste du framework et la suppression de tout code mettant en œuvre HAL du framework.

Appareils dont la version de FCM cible est différente de S_F pour un framework donné ne peut pas être mise à niveau vers cette version.

É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 n'est disponible dans aucun domaine public et bloquée de compatibilité, il est considéré comme non publié 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, health@2.0 HAL é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. est également considéré comme une HAL non publiée.

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

Date de sortie et version actuelle

Pour les HAL d'appareil, si une version HAL est dans une compatibilité publique et figée matricielle, elle est publiée. Par exemple, après le blocage et la publication de FCM version 3 vers AOSP, le HAL health@2.0 est considéré comme une version HAL publiée et actuelle.

Si une version de HAL se trouve dans une matrice de compatibilité publique et figée avec le Version FCM la plus élevée. La version du HAL est à jour (c'est-à-dire non obsolète). Pour par exemple, les versions HAL existantes (comme nfc@1.0, introduite dans compatibility_matrix.legacy.xml). qui existent toujours dans compatibility_matrix.3.xml sont également considérés comme versions publiées et actuelles de HAL.

Pour les HAL de framework, si une version de HAL se trouve dans le fichier manifeste du framework de la branche la plus récente sans l'attribut max-level ou (anormalement) max-level est supérieur ou égal à la version de FCM publiée dans cette branche, il est considérée comme une version publiée et actuelle de HAL. Par exemple, Publication et mise à jour de la couche HAL displayservice sur Android 12, comme spécifié par Framework Android 12 le fichier manifeste.

Disponible, mais obsolète

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

Il est disponible.
Elle ne fait pas partie de la matrice de compatibilité publique et figée qui a le plus haut niveau Version de FCM.
C'est dans une matrice de compatibilité publique et figée que le framework compatibles.

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 Android 9.
Une mise à niveau mineure de la version majeure du HAL est disponible dans Android 9, mais power@1.0 est toujours 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 se trouve dans le fichier manifeste du framework branche publiée avec un attribut max-level inférieur à celui de la version de FCM dans cette branche, il s'agit d'une version de HAL publiée, mais obsolète. Pour exemple, le HAL schedulerservice est publié, mais devient 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 : sont vrais:

Il est déjà sorti.
Le framework ne fait partie d'aucune matrice de compatibilité publique et figée compatibles.

Matrices de compatibilité publiques, figées, mais non prises en charge par le sont conservés dans le codebase pour définir les versions HAL supprimées définies afin que des 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 éléments suivants sont rempli:

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. La l'ancienne version de FCM, compatibility_matrix.legacy.xml, répertorie les exigences du framework sur les anciens appareils (c'est-à-dire ceux commercialisés avant Android 8.0).

Si ce fichier existe pour un FCM de version F, tous les appareils autres que Treble peuvent être mis à niveau vers F à condition que le fichier manifeste de son appareil soit compatible avec ce fichier. Son la suppression suit la même procédure que les FCM pour les autres versions FCM cibles. (supprimée lorsque le nombre d'appareils actifs antérieurs à la version 8.0 est passé en dessous d'une certaine d'entrée).

Versions FCM publiées

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

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