Lors du développement et de la commercialisation de nouveaux appareils, les fournisseurs peuvent définir et déclarer la version FCM cible 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 FCM cible.
Développement de nouveaux appareils
Lors de la définition de la version FCM cible de l'appareil pour les nouveaux appareils :
- Laissez
DEVICE_MANIFEST_FILEetPRODUCT_ENFORCE_VINTF_MANIFESTnon définis. - Implémentez les HAL pour la version FCM cible.
- Écrivez le bon fichier manifeste de périphérique.
- Écrivez la version cible du FCM dans le fichier manifeste de l'appareil.
- Définissez
DEVICE_MANIFEST_FILE. - Définissez
PRODUCT_ENFORCE_VINTF_MANIFESTsurtrue.
Sortie de nouveaux appareils
Lorsqu'un nouveau périphérique est publié, sa version FCM cible 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 FCM cible é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 à jour 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 FCM cible.
Mise à niveau des HAL
Lors d'une mise à niveau d'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. Par exemple:
- Appareils Google Pixel 2 et Pixel 2 XL lancés avec Target FCM Version 2, qui implémentait la HAL audio 2.0 requise
android.hardware.audio@2.0::IDeviceFactory/default. - Pour la HAL audio 4.0 publiée avec Android 9, les appareils Google Pixel 2 et Pixel 2 XL peuvent utiliser un OTA complet pour passer à la HAL 4.0, qui implémente
android.hardware.audio@4.0::IDeviceFactory/default. - Même si le
compatibility_matrix.2.xmlspécifie uniquement l'audio 2.0, l'exigence d'une image de 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é .
Pour résumer, étant donné que compatibility_matrix.2.xml nécessite audio 2.0 et compatibility_matrix.3.xml nécessite audio 4.0, les exigences sont les suivantes :
| Version FCM (Système) | Version FCM cible (fournisseur) | Conditions |
|---|---|---|
| 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 |
Mise à niveau de la version FCM cible
Lors d'une mise à niveau d'une image fournisseur, les fournisseurs peuvent également incrémenter la version FCM cible pour spécifier la version FCM ciblée avec laquelle l'image fournisseur mise à niveau peut fonctionner. Pour augmenter la version FCM cible d'un appareil, les fournisseurs doivent :
- Mettre en œuvre toutes les nouvelles versions HAL requises pour la version FCM cible.
- Modifiez les versions HAL dans le fichier manifeste de l'appareil.
- Modifiez la version cible du FCM dans le fichier manifeste de l'appareil.
- Supprimez les versions HAL obsolètes.
Par exemple, les appareils Google Pixel et Pixel XL lancés avec Android 7.0, leur version FCM cible doit donc être au moins héritée. Cependant, le manifeste de l'appareil déclare la cible FCM version 2 car l'image du fournisseur a été mise à jour pour se conformer à 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 la version 2 de Target FCM. Bien qu'ils implémentent certains HAL requis par compatibility_matrix.3.xml (tels que audio 4.0, santé 2.0, etc.), ils ne suppriment pas android.hardware.radio.deprecated@1.0 , qui est obsolète dans la version 3 du FCM (Android 9). Par conséquent, ces appareils ne peuvent pas mettre à niveau la version FCM cible vers 3.
Mandater les exigences du noyau pendant l'OTA
Mise à jour d'appareils à partir d'Android 9 ou d'une 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 construction 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 génération
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTSpour 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 .
Mise à jour des appareils à partir d'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 à 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 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 actions suivantes :
- Modifiez le script pour prendre en charge le format de votre noyau et contribuer à AOSP.
- Définissez
BOARD_KERNEL_VERSIONsur la version du noyau etBOARD_KERNEL_CONFIG_FILEsur 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_REQUIREMENTSsurfalsepour 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 .