Cycle de vie du FCM

Une version du framework Android comporte plusieurs matrices de compatibilité du 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 la version FCM cible. Dans le cadre du cycle de vie FCM, Android déprécie et supprime les HAL HIDL, puis modifie les fichiers FCM pour refléter l'état de la version HAL .

Pour activer les OTA uniquement sur le framework dans leurs propres écosystèmes, les partenaires qui étendent les interfaces des fournisseurs doivent également déprécier et supprimer les HAL HIDL en utilisant les mêmes méthodes.

Terminologie

Matrice de compatibilité du cadre (FCM) Un fichier XML qui spécifie les exigences du cadre sur les implémentations de fournisseur conformes. La matrice de compatibilité est versionnée et une nouvelle version est gelée pour chaque version du framework. Chaque version de framework contient plusieurs FCM.
Versions de plate-forme FCM (S F ) L'ensemble de toutes les versions de FCM dans une version d'infrastructure. Le framework peut fonctionner avec n'importe quelle implémentation de fournisseur qui satisfait l'un de ces FCM.
Version FCM (F) La version la plus élevée parmi tous les FCM dans une version de framework.
Version cible du FCM (V) La version FCM ciblée (à partir de S F ), déclarée explicitement dans le manifeste de l'appareil, qu'une implémentation de fournisseur satisfait. Une implémentation de 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 manifeste de périphérique.
Version HAL Une version HAL a le format foo@xy , où foo est le nom HAL et xy 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.)
Manifeste de l'appareil Fichiers XML qui spécifient les versions HAL fournies par le côté périphérique de l'interface du fournisseur, y compris les images du fournisseur et ODM. Le contenu d'un manifeste de périphérique est limité par la version FCM cible du périphérique, mais peut répertorier les HAL qui sont strictement plus récents par rapport au FCM correspondant à V.
HAL de l'appareil HAL répertoriées (fournies) dans le manifeste de l'appareil et répertoriées (obligatoires ou facultatives) dans la matrice de compatibilité de l'infrastructure (FCM).
Matrice de compatibilité des appareils (DCM) Un fichier XML qui spécifie les exigences du fournisseur sur les implémentations de framework conformes. Chaque appareil contient un DCM.
Manifeste du cadre Un 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 dans le manifeste du framework sont désactivés dynamiquement en fonction de la version FCM cible de l'appareil.
Framework HAL HAL répertoriées comme fournies dans le manifeste du framework et répertoriées comme obligatoires ou facultatives dans la matrice de compatibilité des appareils (DCM).

Développement dans une nouvelle version du FCM

Android incrémente la version FCM pour chaque version du framework (comme Android 8, 8.1, etc.). Au cours 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 :

  1. Copiez le dernier compatibility_matrix.<F-1>.xml dans compatibility_matrix.F.xml .
  2. Mettez à jour l'attribut level dans le fichier sur F .
  3. Ajoutez les règles de génération correspondantes pour installer cette matrice de compatibilité sur l'appareil.

Présentation d'un nouveau HAL

Au cours du développement, lors de l'introduction d'un nouveau HAL (Wi-Fi, NFC, etc.) sur Android sur la version F actuelle du FCM, ajoutez le HAL à compatibility_matrix.F.xml avec les paramètres optional suivants :

  • optional="false" si les appareils livrés avec V = F doivent se lancer avec cette HAL,

    OU
  • optional="true" si les appareils livrés avec V = F peuvent se lancer sans cette 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 cette HAL, donc l'entrée suivante a é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>

Mise à niveau d'un HAL (mineur)

Pendant le développement, lorsqu'un HAL a une mise à niveau de version mineure de xz vers x.(z+1) à la version actuelle FCM F , si cette version est :

  • Obligatoire sur les appareils lancés avec V = F , le compatibility_matrix.F.xml doit indiquer x.(z+1) et optional="false" .
  • Non requis sur les appareils lancés avec V = F , le compatibility_matrix.F.xml doit copier xy-z et l'optionalité de compatibility_matrix.<F-1>.xml et changer la version en xw-(z+1) (où w >= y ).

Par exemple, Android 8.1 a introduit broadcastradio@1.1 en tant que mise à niveau mineure de la version 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>

Mise à niveau d'un HAL (majeur)

Au cours du développement, lorsqu'un HAL a une mise à niveau de version majeure à la version actuelle FCM F , la nouvelle version majeure x.0 est ajoutée à compatibility_matrix.F.xml avec les paramètres optional suivants :

  • optional="false" avec uniquement la version x.0 , si les appareils livrés avec V = F doivent être lancés avec x.0 .
  • optional="false" mais avec les anciennes versions majeures dans la même balise <hal> , si les appareils livrés avec V = F doivent se lancer avec cette HAL, mais peuvent se lancer avec une ancienne version majeure.
  • optional="true" si les appareils livrés avec V = F n'ont pas à lancer HAL.

Par exemple, Android 9 introduit health@2.0 en tant que mise à niveau de la version majeure de la HAL 1.0 et déprécie la HAL 1.0. L'ancienne version, health@1.0 , est facultative pour les appareils lancés avec Android 8.0 et Android 8.1. Les appareils lancés avec Android 9 ne doivent pas fournir la HAL 1.0 obsolète et doivent à la place fournir la nouvelle version 2.0. Dans 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 HAL 2.0 est dans compatibility_matrix.3.xml avec optional="false" , les appareils qui se lancent avec Android 9 doivent être livrés avec la HAL 2.0.
  • Étant donné que la couche HAL 1.0 n'est pas dans compatibility_matrix.3.xml , les appareils qui se lancent avec Android 9 ne doivent pas fournir la couche HAL 1.0 (car cette couche HAL est considérée comme obsolète).
  • Étant donné que le HAL 1.0 est présent dans legacy/1/2.xml (anciennes versions FCM avec lesquelles Android 9 peut fonctionner) 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 HAL supprimée ).

Nouvelles versions du 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 :

  1. Assurez-vous que compatibility_matrix.F.xml a l'attribut level="F" .
  2. Assurez-vous que tous les appareils se construisent et démarrent.
  3. Mettez à jour les tests VTS pour vous assurer que les appareils lancés avec le dernier framework (basé sur le niveau de l'API d'expédition) ont la version FCM cible V >= F .
  4. Publier le fichier sur AOSP.

Par exemple, les tests VTS garantissent que les appareils lancés avec Android 9 ont la version FCM cible >= 3.

En outre, les FCM product et system_ext peuvent également répertorier les exigences pour chaque version de plate-forme FCM. 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 de FCM sur les partitions product et system_ext doivent correspondre à ceux de la partition système. Semblable aux 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 périphérique avec la version FCM cible F.

Obsolescence de la version HAL

L'abandon d'une version HAL est une décision du développeur (c'est-à-dire que pour les HAL AOSP, Google prend la décision). Cela peut arriver lorsqu'une version HAL supérieure (qu'elle soit mineure ou majeure) est publiée.

Déprécier un périphérique HAL

Lorsqu'un appareil donné HAL foo@xy est obsolète à la version FCM F , cela signifie que tout appareil lancé avec la version FCM cible V = F ou ultérieure ne doit pas implémenter foo à la version xy ou toute version antérieure à xy . Une version HAL obsolète est toujours prise en charge par le framework pour la mise à niveau des appareils.

Lorsque la version FCM F est publiée, une version HAL foo@xy est considérée comme obsolète si la version HAL spécifique n'est pas explicitement indiquée dans le dernier FCM pour la version FCM cible V = F . Pour les appareils lancés avec V = F , l'une des conditions suivantes est vraie :

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

Par exemple, dans Android 9, health@2.0 est introduit en tant que mise à niveau majeure de la version 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.

Déprécier un framework HAL

Lorsqu'un framework HAL foo@xy est obsolète à la version FCM F , cela signifie que tout périphérique lancé avec la version FCM cible V = F ou ultérieure ne doit pas s'attendre à ce que le framework fournisse foo à la version xy , ou à toute version antérieure à xy . Une version HAL obsolète est toujours fournie par le framework pour la mise à niveau des appareils.

Lorsque la version F de FCM est publiée, une version HAL foo@xy est considérée comme obsolète si le manifeste du framework spécifie max-level=" F - 1 " pour foo@xy . Pour les appareils lancés avec V = F , le framework ne fournit pas le HAL foo@xy . La matrice de compatibilité des appareils sur les 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 FCM introduite dans Android 11. Voir le manifeste du framework Android 12 .

Suppression de la prise en charge des versions cibles de FCM

Lorsque les appareils actifs d'une certaine version V du FCM cible tombent en dessous d'un certain seuil, la version du FCM cible est supprimée de l'ensemble S F de la prochaine version du framework. Cela se fait par les deux étapes suivantes :

  • Suppression de compatibility_matrix.V.xml des règles de construction (afin qu'il ne soit pas installé sur l'image système) et suppression de tout code qui implémentait ou dépendait de la fonctionnalité supprimée.
  • Suppression des HAL du framework avec max-level inférieur ou égal à V du manifeste du framework, et suppression de tout code qui implémente les HAL du framework supprimés.

Les appareils avec une version FCM cible en dehors de S F pour une version de framework donnée ne peuvent pas être mis à niveau vers cette version.

État de la version HAL

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

Inédit

Pour les appareils HAL, si une version HAL ne figure dans aucune des matrices de compatibilité publiques et gelées, elle est considérée comme non publiée et éventuellement en cours de développement. Cela inclut les versions HAL qui se trouvent uniquement 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 compatibiility_matrix.3.xml .
  • La HAL teleportation@1.0 ne figure dans aucune matrice de compatibilité publiée et est également considérée comme une HAL non publiée.

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

Publié et actuel

Pour les appareils HAL, si une version HAL se trouve dans une matrice de compatibilité publique et gelée, elle est publiée. Par exemple, une fois la version 3 de FCM gelé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 se trouve dans une matrice de compatibilité publique et gelée qui a la version FCM la plus élevée, la version HAL est actuelle (c'est-à-dire non 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 framework HAL, si une version HAL se trouve dans le manifeste du framework de la dernière branche publiée sans l'attribut max-level ou (exceptionnellement) un max-level égal ou supérieur à la version FCM publiée dans cette branche, elle est considérée comme une version publiée. et la version HAL actuelle. Par exemple, le displayservice HAL est publié et actuel dans Android 12, comme spécifié par le Android 12framework manifest .

Publié mais obsolète

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

  • Il est libéré.
  • Ce n'est pas dans la matrice de compatibilité publique et gelée qui a la version FCM la plus élevée.
  • C'est dans une matrice de compatibilité publique et gelée que le framework prend toujours en charge.

Exemples:

Par conséquent, power@1.0 est actuel, mais PAS obsolète, dans Android 9.

Pour les framework HAL, si une version HAL se trouve dans le 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 schedulerservice HAL est publié mais obsolète dans Android 12, comme spécifié par le Android 12framework manifest .

Supprimé

Pour les appareils HAL, une version HAL est supprimée si et seulement si les conditions suivantes sont remplies :

  • Il a été publié précédemment.
  • Ce n'est dans aucune matrice de compatibilité publique et gelée que le framework prend en charge.

Les matrices de compatibilité publiques, 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 afin que les tests VTS puissent être écrits pour garantir que les HAL supprimés ne se trouvent pas sur de nouveaux appareils.

Pour les frameworks HAL, une version HAL est supprimée si et seulement si les conditions suivantes sont remplies :

  • Il a été publié précédemment.
  • Ce n'est dans aucun manifeste de framework de la dernière branche publiée.

FCM hérités

L'héritage de la version FCM cible est une valeur spéciale pour tous les appareils non Treble. L'ancien FCM, compatibility_matrix.legacy.xml , répertorie les exigences du cadre sur les appareils hérités (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 manifeste d'appareil 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 après que le nombre d'appareils pré-8.0 actifs tombe en dessous d'un certain seuil).

Versions FCM publiées

La liste des versions publiées de FCM se trouve sous hardware/interfaces/compatibility_matrices .

Pour trouver la version FCM publiée avec une version Android spécifique, consultez Level.h .