Cycle de vie du FCM

Une version du framework Android comporte plusieurs matrices de compatibilité du framework (FCM), une pour chaque version évolutive de Target FCM, qui définissent ce que le framework peut utiliser et les exigences de la version Target FCM. 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 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 framework (FCM)
Un fichier XML qui spécifie les exigences du cadre sur les implémentations conformes des fournisseurs. La matrice de compatibilité est versionnée et une nouvelle version est gelée pour chaque version du framework. Chaque version du framework contient plusieurs FCM.
Versions FCM de la plateforme (S F )
L’ensemble de toutes les versions FCM dans une version framework. 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 framework.
Version FCM cible (V)
Version FCM ciblée (de S F ), déclarée explicitement dans le manifeste de l'appareil, à laquelle satisfait une implémentation du fournisseur. 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 périphérique
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 Target FCM du périphérique mais peut répertorier les HAL strictement plus récents par rapport au FC correspondant à V.
HAL des appareils
HAL répertoriés (fournis) dans le manifeste du périphérique et répertoriés (obligatoires ou facultatifs) dans la matrice de compatibilité du framework (FCM).
Matrice de compatibilité des appareils (DCM)
Un fichier XML qui spécifie les exigences du fournisseur concernant 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é structure 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 Target FCM de l'appareil.
Cadre HAL
HAL répertoriés comme fournis dans le manifeste du framework et répertoriés comme obligatoires ou facultatifs dans la matrice de compatibilité des appareils (DCM).

Cycle de vie FCM dans la base de code

Ce document décrit le cycle de vie du FCM dans le résumé. Pour voir les manifestes actuellement pris en charge, reportez-vous à hardware/interfaces/compatibility_matrix.<FCM>.xml où FCM se trouve dans system/libvintf/include/vintf/Level.h .

Depuis Android 14, les niveaux pris en charge sont :

FCM Version Android
4 Android 10/Q
5 Android 11/R
6 Android 12/S
7 Android 13/T
8 Android 14/U

Développer dans une nouvelle version FCM

Android incrémente la version FCM pour chaque version du framework (comme 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 un nouveau FCM Version 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 construction correspondantes pour installer cette matrice de compatibilité sur l'appareil.

Présentation d'un nouveau HAL

Pendant le développement, lors de l'introduction d'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 livrés avec V = F doivent se lancer avec ce HAL,
  • optional="true" si les appareils livrés avec V = F peuvent se lancer sans ce HAL.

Par exemple, Android 8.1 a introduit cas@1.0 comme HAL facultatif. Les appareils lancés avec Android 8.1 ne sont pas tenus d'implémenter ce HAL, c'est pourquoi l'entrée suivante a été ajoutée à compatibility_matrix.F.xml (qui était auparavant nommée compatibility_matrix.current.xml temporairement lors du 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 (mineur)

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

  • Requis 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'optionnalité 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 la 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)

Pendant le développement, lorsqu'un HAL dispose d'une mise à niveau de version majeure avec la version FCM actuelle 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 ê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 n'ont pas besoin de lancer le HAL.

Par exemple, Android 9 introduit health@2.0 en tant que mise à niveau majeure de la version 1.0 HAL et rend obsolète la 1.0 HAL. 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 version obsolète HAL 1.0 mais doivent plutôt fournir la nouvelle version 2.0. Je 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 2.0 HAL se trouve dans compatibility_matrix.3.xml avec optional="false" , les appareils lancés avec Android 9 doivent être livrés 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 le HAL 1.0 est présent dans le fichier 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 le compatibility_matrix.F.xml possède l'attribut level="F" .
  2. Assurez-vous que tous les appareils sont construits et démarrent.
  3. Mettez à jour les tests VTS pour garantir que les appareils lancés avec le dernier framework (en fonction du niveau de l'API d'expédition) ont Target FCM Version V >= F .
  4. Publier le fichier sur AOSP.

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

De plus, les FCM product et system_ext peuvent également répertorier les exigences pour les versions FCM de chaque 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 produit et system_ext doivent être alignés sur ceux de la partition système. Semblable aux versions FCM sur la partition système, la matrice de compatibilité de 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.

Dépréciation de la version HAL

La dépréciation 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 pourrait se produire lorsqu'une version supérieure de HAL (qu'elle soit mineure ou majeure) est publiée.

Déprécier un appareil HAL

Lorsqu'un appareil donné HAL foo@xy est obsolète dans la version FCM F , cela signifie que tout appareil lancé avec la version cible FCM V = F ou ultérieure ne doit pas implémenter foo dans la version xy ou toute version antérieure à xy . 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 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 cible du FCM 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 le HAL.

Par exemple, dans Android 9, health@2.0 est introduit comme une 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 Compatibilité_matrix.2.xml . Par conséquent, health@1.0 est considéré comme obsolète.

Déprécier un framework HAL

Lorsqu'un framework donné HAL foo@xy est obsolète dans la version FCM F , cela signifie que tout appareil lancé avec la version Target FCM 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 obsolète de HAL est toujours fournie 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 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 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. Voir Manifeste du framework Android 12 .

Suppression de la prise en charge des versions cibles FCM

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

  1. 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 implémentant ou dépendant de la fonctionnalité supprimée.

  2. Suppression des HAL de framework avec max-level inférieur ou égal à V du manifeste du framework et suppression de tout code qui implémente les HAL de 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 effectuer de mise à 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 HAL de périphériques, si une version HAL ne figure dans aucune des matrices de compatibilité publiques et gelées, elle est considérée comme inédite et éventuellement en développement. Cela inclut les versions HAL qui se trouvent uniquement dans compatibility_matrix.F.xml . Exemples:

  • Lors du développement d'Android 9, le HAL health@2.0 était considéré comme un HAL inédit 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 un HAL inédit.

Pour les HAL de framework, si une version de HAL se trouve uniquement dans le 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 de périphériques, 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 possède 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 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 de HAL se trouve dans le manifeste de 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 actuelle de HAL. Par exemple, le displayservice HAL est publié et actuel dans Android 12, comme spécifié par le manifeste du framework Android 12 .

Publié mais obsolète

Pour les HAL d’appareil, 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 qu'a la version FCM la plus élevée.
  • C'est dans une matrice de compatibilité publique et figé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 HAL de framework, si une version de HAL se trouve dans le manifeste de framework de la dernière branche publiée avec un attribut max-level inférieur à la version FCM 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 manifeste du framework Android 12 .

Supprimé

Pour les HAL de périphérique, une version HAL est supprimée si et seulement si les conditions suivantes sont vraies :

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

Les matrices de compatibilité qui sont publiques, gelé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ées ne se trouvent pas sur de nouveaux appareils.

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

  • Il a déjà été publié.
  • Il ne s'agit d'aucun manifeste de cadre de la dernière branche publiée.

FCM hérités

L'héritage de la version Target FCM est une valeur spéciale pour tous les appareils non-Treble. L'ancien FCM, compatibility_matrix.legacy.xml , répertorie les exigences du framework sur les appareils existants (c'est-à-dire les appareils lancés avant Android 8.0).

Si ce fichier existe pour un FCM avec la version F , tout périphérique non-Treble peut être mis à niveau vers F à condition que son manifeste de périphérique soit compatible avec ce fichier. Sa suppression suit la même procédure que les FCM pour les autres versions Target FCM (supprimées une fois que le nombre d'appareils actifs antérieurs à la version 8.0 tombe en dessous d'un certain seuil).

Versions FCM publiées

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

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