Une version du framework Android comporte plusieurs matrices de compatibilité de framework (FCM), une pour chaque version FCM cible pouvant être mise à niveau, qui définissent ce que le framework peut utiliser et les exigences de 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 permettre aux agences de voyages en ligne basées uniquement sur le framework dans leurs propres écosystèmes, les partenaires qui étendent les interfaces des fournisseurs 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 concernant la conformité des implémentations des fournisseurs. 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 (SF)
- Ensemble de toutes les versions de FCM dans une version du framework. Le framework peut fonctionner avec n'importe quelle implémentation de fournisseur répondant à 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 le fichier manifeste de l'appareil, qui satisfait une implémentation de fournisseur. Une implémentation du fournisseur doit être générée par rapport à un FCM publié, bien qu'elle puisse déclarer des versions plus récentes de HAL dans son fichier manifeste d'appareil.
- Version de HAL
- Une version HAL se présente au format
foo@x.y
, oùfoo
correspond au nom HAL etx.y
à la version spécifique. Par exemple :nfc@1.0
,keymaster@3.0
(le préfixe racine, par exempleandroid.hardware
, est omis tout au long de ce document). - Fichier manifeste de l'appareil
- Fichiers XML qui spécifient les versions de HAL fournies par le côté appareil de l'interface fournisseur, y compris les images du fournisseur et de l'ODM. Le contenu du fichier manifeste d'un appareil est limité par la version FCM cible de l'appareil, mais peut répertorier les HAL strictement plus récents par rapport à la FC correspondant à V.
- HAL des appareils
- 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 (Matrice de compatibilité des appareils)
- Fichier XML qui spécifie les exigences des fournisseurs concernant les implémentations de framework conformes. Chaque appareil contient un seul DCM.
- Fichier manifeste de framework
- Fichier XML qui spécifie les versions HAL fournies par le côté framework de l'interface fournisseur, y compris les images système, system_ext et produit. Les HAL dans le fichier manifeste du framework sont désactivées 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 FCM dans le codebase
Ce document décrit le cycle de vie de FCM en résumé. Pour consulter les fichiers manifestes actuellement 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 appareil expédié avec Android 11 disposera généralement du niveau FCM 5, mais implémentera FCM le 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 de FCM pour chaque version du framework (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é sur l'appareil.
Présentation d'une nouvelle HAL
Pendant le développement, lorsque vous introduisez un nouveau HAL (Wi-Fi, NFC, etc.) dans 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. Les appareils lancés avec Android 8.1 ne sont pas nécessaires pour implémenter cette HAL. L'entrée suivante a donc été ajoutée à compatibility_matrix.F.xml
(qui était temporairement nommé 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)
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:
- Requis sur les appareils lancés avec
V = F
,compatibility_matrix.F.xml
doit indiquerx.(z+1)
etoptional="false"
. - Non requis sur les appareils lancés avec
V = F
, lecompatibility_matrix.F.xml
doit copierx.y-z
et l'option facultative decompatibility_matrix.<F-1>.xml
et remplacer la version parx.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 1.0 HAL. 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 (version majeure)
Pendant le développement, lorsqu'un HAL fait l'objet d'une mise à niveau majeure vers la version actuelle de FCM F
, la nouvelle version majeure x.0
est ajoutée à compatibility_matrix.F.xml
avec les paramètres optional
suivants:
optional="false"
avec la versionx.0
uniquement, si les appareils fournis avecV = F
doivent être lancés avecx.0
.optional="false"
, mais avec les anciennes versions majeures dans la même balise<hal>
, si les appareils fournis avecV = F
doivent être lancés avec cette HAL, mais peuvent être lancés avec une ancienne version majeure.optional="true"
si les appareils fournis avecV = F
n'ont pas besoin de lancer le HAL.
Par exemple, Android 9 introduit health@2.0
en tant que mise à niveau de version majeure du HAL 1.0 et abandonne l'HAL 1.0. L'ancienne 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 ne doivent pas fournir la version obsolète HAL 1.0, mais doivent fournir la nouvelle version 2.0. I
compatibility_matrix.legacy.xml
,
compatibility_matrix.1.xml
et
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 :
- Étant donné que la version HAL 2.0 se trouve dans
compatibility_matrix.3.xml
avecoptional="false"
, les appareils lancés avec Android 9 doivent être fournis avec la version 2.0 HAL. - Étant donné que la HAL 1.0 ne se trouve pas dans
compatibility_matrix.3.xml
, les appareils lancés avec Android 9 ne doivent pas fournir la HAL 1.0 (car cette HAL est considérée comme obsolète). - Étant donné que la HAL 1.0 est présente dans le fichier HAL 1.0 (anciennes versions de FCM compatibles avec Android 9) en tant que HAL facultative, le framework Android 9 peut toujours fonctionner avec la HAL 1.0 (qui n'est pas considérée comme une version de HAL supprimée).
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. Il 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.
- Mettez à jour les tests VTS pour vous assurer que les appareils lancés avec le dernier framework (selon le niveau d'API Shipping) disposent de la version
V >= F
de FCM cible. - Publier le fichier sur AOSP
Par exemple, les tests VSS garantissent que les appareils lancés avec Android 9 disposent de la version 3 de FCM cible ou d'une version ultérieure.
En outre, les FCM product et system_ext peuvent également lister les exigences pour chaque version FCM de la plate-forme. La publication des versions FCM sur les partitions product et system_ext est effectuée respectivement par le propriétaire de ces images. Les numéros de version FCM sur les partitions product et system_ext doivent correspondre à ceux de la partition système. Comme pour les versions FCM sur la partition système, la matrice de compatibilité de FCM version F dans les partitions product et system_ext reflète les exigences d'un appareil avec la version FCM cible.
Abandon de la version HAL
L'abandon d'une version HAL est une décision du développeur (c'est-à-dire que c'est Google qui décide pour les HAL AOSP). Cela peut se produire lorsqu'une version supérieure de HAL (mineur ou majeure) est publiée.
Abandonner une couche HAL d'appareil
Lorsqu'un foo@x.y
d'HAL d'appareil donné est obsolète à partir de 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 de 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 FCM cible 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 (majeure ou mineure) ;
- Le framework ne nécessite plus le HAL.
Par exemple, dans Android 9, health@2.0
est introduit en tant que mise à niveau de version majeure de 1.0 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
d'HAL de framework 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 s'attendre à ce que le framework fournisse foo
à la version x.y
ou à toute version antérieure à 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 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 foo@x.y
HAL. La matrice de compatibilité des appareils lancés avec V = F
ne doit pas répertorier 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 de FCM introduite dans Android 11. Consultez Fichier manifeste du framework Android 12.
Suppression de la compatibilité avec les versions FCM cibles
Lorsque les appareils actifs d'une certaine version FCM cible V
passent en dessous d'un certain seuil, la version FCM cible est supprimée de l'ensemble SF de la prochaine version du framework. Pour ce faire, suivez les deux étapes ci-dessous:
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 de la fonctionnalité supprimée.Suppression des HAL de framework dont la valeur
max-level
est inférieure ou égale àV
du fichier manifeste du framework et suppression de tout code mettant en œuvre les HAL de framework supprimés.
Les appareils dont la version de FCM cible est extérieure à SF pour une version de framework donnée ne peuvent pas être mises à niveau vers cette version.
État de la version HAL
Les sections suivantes décrivent (dans l'ordre chronologique) les états possibles d'une version de HAL.
Non publiées
Pour les HAL d'appareils, si une version HAL ne figure dans aucune des matrices de compatibilité publique et figée, elle est considérée comme non publiée 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, le HAL
health@2.0
é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 et est également considéré comme une HAL non publiée.
Pour les HAL de framework, si une version HAL ne figure que dans le fichier manifeste de framework d'une branche de développement non liée, elle est considérée comme non publiée.
Publié et actuel
Pour les HAL d'appareils, si une version HAL se trouve 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, le HAL health@2.0
est considéré comme une version d'HAL publiée et actuelle.
Si une version de HAL se trouve dans une matrice de compatibilité publique et figée avec la version FCM la plus élevée, la version de HAL est à jour (c'est-à-dire non obsolète). Par exemple, les versions HAL existantes (telles que nfc@1.0
introduites dans compatibility_matrix.legacy.xml
et 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 de framework de la dernière branche publiée sans l'attribut max-level
ou (anormalement) un max-level
égal ou supérieur à la version de FCM publiée dans cette branche, elle est considérée comme une version publiée et actuelle de HAL. Par exemple, le HAL displayservice
est publié et actuel dans Android 12, comme spécifié par le fichier manifeste du framework Android 12.
Disponible, mais obsolète
Pour les HAL d'appareils, une version HAL est obsolète si et seulement si toutes les conditions suivantes sont remplies:
- Il est disponible.
- Elle ne figure pas dans la matrice de compatibilité publique et figée qui possède la version de FCM la plus élevé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 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 dans Android 9. - Le HAL de puissance présente une mise à niveau de version mineure sous Android 9, mais
power@1.0
est toujours danscompatibility_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 figure dans le fichier manifeste de framework de la dernière branche publiée avec un attribut max-level
inférieur à celui de la version de FCM dans cette branche, elle est considérée comme une version publiée, mais obsolète de HAL. Par exemple, le HAL schedulerservice
est publié, mais 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 les conditions suivantes sont remplies:
- Il est déjà sorti.
- 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 code base pour définir les versions de HAL supprimées définies. Ainsi, les 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 conditions suivantes sont remplies:
- 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. 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
.