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 (SF)
- 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 SF), 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 etx.y
au nom la version spécifique ; Ex. :nfc@1.0
,keymaster@3.0
(préfixe racine, par exempleandroid.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 la
fichiers manifestes 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 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,
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
danscompatibility_matrix.F.xml
- Dans le fichier, remplacez l'attribut
level
parF
. - 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 avecV = F
doivent être lancés avec ce HAL ;optional="true"
si les appareils fournis avecV = F
peuvent être lancés sans ce HAL.
Par exemple, Android 8.1 a introduit cas@1.0
en tant que HAL facultatif. Lancement des appareils
avec Android 8.1 ne sont pas nécessaires pour implémenter ce HAL. L'entrée suivante a donc été
ajoutés à compatibility_matrix.F.xml
(qui s'appelait auparavant
compatibility_matrix.current.xml
temporairement 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:
- Obligatoire sur les appareils lancés avec
V = F
etcompatibility_matrix.F.xml
doit indiquerx.(z+1)
etoptional="false"
. - Non requis sur les appareils lancés avec
V = F
,compatibility_matrix.F.xml
doit copierx.y-z
et l'option facultative depuiscompatibility_matrix.<F-1>.xml
et remplacez la version parx.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 versionx.0
, si les appareils livrés avecV = F
doit être lancé avecx.0
.optional="false"
, mais avec les anciennes versions majeures dans le même<hal>
, si les appareils livrés avecV = 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 avecV = 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
ne pas fournir l'HAL 1.0 obsolète, mais fournir la nouvelle version 2.0.
compatibility_matrix.legacy.xml
,
compatibility_matrix.1.xml
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 :
- Parce que le HAL 2.0 se trouve dans
compatibility_matrix.3.xml
avecoptional="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'attributlevel="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 à partir de 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 SF 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 SF 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
des matrices 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 danscompatibility_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 danscompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, etcompatibility_matrix.2.xml
, mais pas danscompatibility_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 toujourscompatibility_matrix.3.xml
power@1.0
compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
, etcompatibility_matrix.2.xml
.compatibility_matrix.3.xml
apower@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 se trouvent pas 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