Développement de manifestes de périphériques

Lors du développement et de la publication de nouveaux appareils, les fournisseurs peuvent définir et déclarer la version cible FCM dans le 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 HAL et d'incrémenter la version cible FCM.

Développer de nouveaux appareils

Lors de la définition de la version cible FCM de l'appareil pour les nouveaux appareils :

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

Sortie de nouveaux appareils

Lorsqu'un nouveau périphérique est publié, sa version cible FCM initiale doit être déterminée et déclarée dans le manifeste du périphérique 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 FCM égale à 3 (la version supérieure disponible actuellement). Pour le déclarer dans le manifeste de l'appareil :

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

Mise à niveau de 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 HAL et d'incrémenter la version cible FCM.

Mise à niveau des HAL

Lors d'une mise à niveau d'image de 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. Par exemple:

  • Appareils Google Pixel 2 et Pixel 2 XL publiés avec Target FCM version 2, qui implémente l'audio 2.0 HAL requis android.hardware.audio@2.0::IDeviceFactory/default .
  • Pour le HAL audio 4.0 sorti avec Android 9, les appareils Google Pixel 2 et Pixel 2 XL peuvent utiliser un OTA complet pour passer au HAL 4.0, qui implémente android.hardware.audio@4.0::IDeviceFactory/default .
  • Même si le compatibility_matrix.2.xml spécifie uniquement l'audio 2.0, l'exigence relative à une image du fournisseur avec Target FCM version 2 a été assouplie car le framework Android 9 (FCM version 3) considère l'audio 4.0 comme un remplacement de l'audio 2.0 HAL 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 nécessite l'audio 4.0, les exigences sont les suivantes :

Version FCM (système) Version FCM cible (fournisseur) Exigences
2 (8.1) 2 (8.1) Audio2.0
3 (9) 2 (8.1) Audio 2.0 ou 4.0
3 (9) 3 (9) Audio 4.0

Mise à niveau de la version cible du FCM

Lors d'une mise à niveau de l'image du fournisseur, les fournisseurs peuvent également incrémenter la version FCM cible pour spécifier la version FCM ciblée avec laquelle l'image du fournisseur mise à niveau peut fonctionner. Pour modifier la version cible 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 FCM cible dans le fichier manifeste de l’appareil.
  4. Supprimez les versions HAL obsolètes.

Par exemple, les appareils Google Pixel et Pixel XL lancés avec Android 7.0, leur version Target FCM doit donc être au moins héritée. Cependant, le manifeste de l'appareil déclare la version 2 du 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 ont Target FCM version 2. 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 dans FCM version 3 (Android 9). Par conséquent, ces appareils ne peuvent pas mettre à niveau la version Target FCM vers la version 3.

Imposer les exigences du noyau pendant l'OTA

Mise à jour des appareils à partir d'Android 9 ou version antérieure

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

Ces modifications introduisent l'indicateur de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS et laissent l'indicateur non défini pour les appareils lancés avec Android 9 ou une version antérieure.

  • Lors de la mise à jour vers Android 10, les clients OTA sur les appareils exécutant Android 9 ou une 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 noyau du package OTA généré.
  • Lors de la mise à jour vers Android 11, il est facultatif de définir l'indicateur de build PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS pour vérifier la compatibilité VINTF lorsque le package de mise à jour est généré.

Pour plus d'informations sur cet indicateur de build, consultez Mise à jour des appareils à partir d'Android 10 .

Mettre à jour les appareils depuis Android 10

Android 10 introduit un nouvel indicateur de build, 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 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 exécutant Android 10 lisent ces informations pour vérifier la compatibilité.
  • Lors de la mise à jour vers Android 11, la génération du package 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 noyau, effectuez l'une des opérations suivantes :

  • Modifiez le script pour prendre en charge le format de votre noyau et contribuez à AOSP.
  • Définissez BOARD_KERNEL_VERSION sur la version du noyau et BOARD_KERNEL_CONFIG_FILE sur le chemin du fichier de configuration du noyau construit .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 noyau. Ceci n'est pas recommandé car toute incompatibilité est masquée et n'est découverte que lors de l'exécution des tests VTS après la mise à jour.

Vous pouvez afficher le code source du script d'extraction des informations du noyau extract_kernel.py .