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 cible de FCM 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 HAL et d'incrémenter 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. Ne définissez pas DEVICE_MANIFEST_FILE et PRODUCT_ENFORCE_VINTF_MANIFEST.
2. Implémentez les HAL pour la version FCM cible.
3. Écrivez le fichier manifeste de l'appareil approprié.
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.

Lancer de nouveaux appareils

Lorsqu'un nouvel appareil est lancé, 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 premier niveau.

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 moment-là). 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 HAL et d'incrémenter la version FCM cible.

Mettre à niveau les HAL

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

• Les appareils Google Pixel 2 et Pixel 2 XL ont été commercialisés avec la version 2 de FCM, qui implémentait le HAL audio 2.0 requis android.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 au HAL 4.0, qui implémente android.hardware.audio@4.0::IDeviceFactory/default.
• Même si compatibility_matrix.2.xml ne spécifie que 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'audio 2.0 HAL en termes de fonctionnalité.

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

Mettre à niveau la version FCM cible

Lors de la mise à niveau d'une image de fournisseur, les fournisseurs peuvent également incrémenter la version FCM cible pour spécifier la version FCM cible avec laquelle l'image de fournisseur mise à niveau peut fonctionner. Pour augmenter la version FCM cible 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 ont été lancés avec Android 7.0. Leur version cible de FCM doit donc être au moins l'ancienne version. 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 sont compatibles avec la version 2 de FCM. Bien qu'ils implémentent certaines HAL requises par compatibility_matrix.3.xml (comme audio 4.0, health 2.0, etc.), ils ne suppriment pas android.hardware.radio.deprecated@1.0, qui est obsolète dans la version 3 de FCM (Android 9). Par conséquent, ces appareils ne peuvent pas mettre à niveau la version FCM cible vers la version 3.

Exiger des exigences du noyau lors de la 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 suivants sont sélectionnés :

• CL 722283
• CL 722284
• CL 722345

Ces modifications introduisent l'indicateur de compilation PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS et laissent l'indicateur non défini 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 à jour 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 Mettre à jour les appareils depuis Android 10.

Mise à jour des appareils depuis 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 et les configurations du noyau à partir de l'image du noyau installé.

• 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 fonctionnant sous 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 du noyau, effectuez l'une des opérations suivantes :

• Modifiez le script pour qu'il soit compatible avec votre format de noyau et contribuez à AOSP.
• Définissez BOARD_KERNEL_VERSION sur la version du noyau et BOARD_KERNEL_CONFIG_FILE sur le chemin d'accès du fichier de configuration du noyau 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 noyau. Nous vous le déconseillons, 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 d'informations du noyau : extract_kernel.py.