Développement du fichier manifeste de l'appareil

Lors du développement et de la publication de nouveaux appareils, les fournisseurs peuvent définir et déclarer la version FCM cible dans le fichier manifeste de l'appareil (DM). Lors de la mise à niveau de l'image du fournisseur pour les anciens appareils, les fournisseurs peuvent choisir d'implémenter de nouvelles versions de HAL et d'augmenter la version FCM cible.

Développer de nouveaux appareils

Lorsque vous définissez la version FCM cible de l'appareil pour les nouveaux appareils:

  1. Laissez DEVICE_MANIFEST_FILE et PRODUCT_ENFORCE_VINTF_MANIFEST non définis.
  2. Implémentez des HAL pour la version cible de FCM.
  3. Écrivez le fichier manifeste d'appareil approprié.
  4. Écrivez la version cible de FCM dans le fichier manifeste de l'appareil.
  5. Définissez DEVICE_MANIFEST_FILE.
  6. Définissez PRODUCT_ENFORCE_VINTF_MANIFEST sur true.

Lancement de nouveaux appareils

Lorsqu'un nouvel appareil est commercialisé, sa version FCM cible initiale doit être déterminée et déclarée dans le fichier manifeste de l'appareil en tant qu'attribut "target-level" dans l'élément <manifest> de niveau supérieur.

Par exemple, les appareils lancés avec Android 9 doivent avoir une version cible de FCM égale à 3 (la version la plus récente disponible à ce jour). Pour déclarer cela dans le fichier manifeste de l'appareil:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Mettre à niveau l'image du fournisseur

Lors de la mise à niveau de l'image du fournisseur pour un ancien appareil, les fournisseurs peuvent choisir d'implémenter de nouvelles versions de HAL et d'augmenter la version cible de FCM.

Mettre à niveau les HAL

Lors d'une mise à niveau de l'image du fournisseur, les fournisseurs peuvent implémenter de nouvelles versions de HAL à condition que le nom de HAL, le nom de l'interface et le nom de l'instance soient identiques. Exemple :

  • Appareils Google Pixel 2 et Pixel 2 XL commercialisés avec la version 2 de FCM cible, qui implémente le HAL audio 2.0 requisandroid.hardware.audio@2.0::IDeviceFactory/default.
  • Pour le HAL audio 4.0 publié avec Android 9, les appareils Google Pixel 2 et Pixel 2 XL peuvent utiliser une mise à jour OTA complète pour passer à la version 4.0 du HAL, qui implémente android.hardware.audio@4.0::IDeviceFactory/default.
  • Même si compatibility_matrix.2.xml spécifie uniquement l'audio 2.0, l'exigence concernant une image du fournisseur avec la version 2 de FCM cible a été assouplie, car le framework Android 9 (version 3 de FCM) considère l'audio 4.0 comme un remplacement de l'HAL audio 2.0 en termes de fonctionnalités.

Pour résumer, étant donné que compatibility_matrix.2.xml nécessite l'audio 2.0 et compatibility_matrix.3.xml l'audio 4.0, les exigences sont les suivantes:

Version de FCM (système) Version cible de FCM (fournisseur) Conditions requises
2 (8.1) 2 (8.1) Audio 2.0
3 (9) 2 (8.1) Audio 2.0 ou 4.0
3 (9) 3 (9) Audio 4.0

Mettre à niveau la version cible de FCM

Lors d'une mise à niveau de l'image du fournisseur, les fournisseurs peuvent également augmenter la version FCM cible pour spécifier la version FCM ciblée avec laquelle l'image du fournisseur mise à niveau peut fonctionner. Pour mettre à jour la version cible de FCM d'un appareil, les fournisseurs doivent:

  1. Implémentez toutes les nouvelles versions HAL requises pour la version FCM cible.
  2. Modifiez les versions HAL dans le fichier manifeste de l'appareil.
  3. Modifiez la version cible de FCM dans le fichier manifeste de l'appareil.
  4. Suppression des versions HAL obsolètes.

Par exemple, les appareils Google Pixel et Pixel XL ont été lancés avec Android 7.0. Leur version cible de FCM doit donc être ancienne. Toutefois, le fichier manifeste de l'appareil déclare la version 2 de FCM cible, car l'image du fournisseur a été mise à jour pour être conforme à compatibility_matrix.2.xml:

<manifest version="1.0" type="device" target-level="2">

Si les fournisseurs n'implémentent pas toutes les nouvelles versions HAL requises ou ne suppriment pas les versions HAL obsolètes, la version FCM cible ne peut pas être mise à niveau.

Par exemple, les appareils Google Pixel 2 et Pixel 2 XL ciblent la version 2 de FCM. Bien qu'ils implémentent certains HAL requis par compatibility_matrix.3.xml (tels que l'audio 4.0, la santé 2.0, etc.), ils ne suppriment pas android.hardware.radio.deprecated@1.0, qui est obsolète à partir de la version 3 de FCM (Android 9). Par conséquent, ces appareils ne peuvent pas passer à la version 3 de FCM.

Exiger des exigences de noyau lors d'une mise à jour OTA

Mettre à jour des appareils équipés d'Android 9 ou version antérieure

Sur les appareils équipés d'Android 9 ou version antérieure, assurez-vous que les CL suivantes sont sélectionnées:

Ces modifications introduisent l'indicateur de compilation PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS et ne définissent pas l'indicateur pour les appareils lancés avec Android 9 ou version antérieure.

  • Lors de la mise à jour vers Android 10, les clients OTA sur les appareils équipés d'Android 9 ou version antérieure ne vérifient pas correctement les exigences du noyau dans le package OTA. Ces modifications sont nécessaires pour supprimer les exigences du kernel du package OTA généré.
  • Lors de la mise à niveau vers Android 11, il est facultatif de définir l'indicateur de compilation PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS pour vérifier la compatibilité VINTF lors de la génération du package de mise à jour.

Pour en savoir plus sur cet indicateur de compilation, consultez la section Mettre à jour les appareils à partir d'Android 10.

Mettre à jour les appareils à partir d'Android 10

Android 10 introduit un nouvel indicateur de compilation, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. Pour les appareils lancés avec Android 10, cet indicateur est automatiquement défini sur true. Lorsque l'indicateur est défini sur true, un script extrait la version du noyau et les configurations du noyau à partir de l'image du noyau installée.

  • Lors de la mise à jour vers Android 10, le package de mise à jour OTA contient la version et la configuration du noyau. Les clients OTA sur les appareils équipés d'Android 10 lisent ces informations pour vérifier la compatibilité.
  • Lors de la mise à jour vers Android 11, la génération de packages OTA lit la version et la configuration du noyau pour vérifier la compatibilité.

Si le script ne parvient pas à extraire ces informations pour votre image de kernel, effectuez l'une des opérations suivantes:

  • Modifiez le script pour qu'il prenne en charge votre format de noyau et contribuez à AOSP.
  • Définissez BOARD_KERNEL_VERSION sur la version du kernel et BOARD_KERNEL_CONFIG_FILE sur le chemin d'accès du fichier de configuration du kernel compilé .config. Les deux variables doivent être mises à jour lorsque l'image du noyau est mise à jour.
  • Vous pouvez également définir PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS sur false pour ignorer la vérification des exigences du kernel. Cette méthode n'est pas recommandée, car toute incompatibilité est masquée et n'est découverte que lors de l'exécution de tests VTS après la mise à jour.

Vous pouvez consulter le code source du script d'extraction d'informations du kernel extract_kernel.py.