Développement du fichier manifeste de l'appareil

Lors du développement et du lancement de nouveaux appareils, les fournisseurs peuvent définir et déclarer la version FCM cible indiquée 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 de FCM cible de l'appareil pour les nouveaux appareils:

1. Quittez DEVICE_MANIFEST_FILE et PRODUCT_ENFORCE_VINTF_MANIFEST non défini.
2. Implémentez des 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.

Publier de nouveaux appareils

Lors de la sortie d'un nouvel appareil, la version FCM cible initiale doit être déterminé et déclaré dans le fichier manifeste de l'appareil en tant que "target-level" dans l'attribut de niveau supérieur Élément <manifest>.

Par exemple, les appareils équipés d'Android 9 La version cible de FCM doit être égale à 3 (la version la plus élevée disponible à l'heure actuelle). Pour le déclarer dans le fichier manifeste de l'appareil:

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

Mettre à niveau l'image du fournisseur

Lorsqu'ils mettent à jour l'image du fournisseur pour un ancien appareil, les fournisseurs peuvent choisir implémenter de nouvelles versions HAL et incrémenter la version FCM cible.

Mettre à niveau les HAL

Lors de la mise à niveau de l'image d'un fournisseur, les fournisseurs peuvent implémenter de nouvelles versions de HAL. à condition que le nom du 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 FCM cible 2, qui a implémenté la norme audio 2.0 HAL requise android.hardware.audio@2.0::IDeviceFactory/default
• Pour l'audio 4.0 HAL publié avec Android 9, les appareils Google Pixel 2 et Pixel 2 XL peuvent utiliser une mise à niveau OTA complète vers la version 4.0 HAL, qui implémente android.hardware.audio@4.0::IDeviceFactory/default
• Même si compatibility_matrix.2.xml spécifie l'audio 2.0 uniquement, l'exigence concernant une image de fournisseur avec la version 2 de FCM cible a été assoupli, car le framework Android 9 (version FCM) 3) 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 audio 2.0 et compatibility_matrix.3.xml nécessite l'audio 4.0, exigences sont les suivantes:

Mettre à niveau la version FCM cible de la mise à niveau

Lors d'une mise à niveau de l'image d'un fournisseur, les fournisseurs peuvent également incrémenter le FCM cible. version pour spécifier la version de FCM ciblée sur laquelle l'image du fournisseur mis à niveau peut fonctionner . Pour remplacer 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 obsolètes de HAL.

Par exemple, les appareils Google Pixel et Pixel XL équipés d'Android 7.0 Leur version FCM cible doit donc être au moins ancienne. Toutefois, l'appareil fichier manifeste déclare la version 2 de FCM cible, car l'image du fournisseur a a été mis à 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 requises de HAL ou ne suppriment pas versions obsolètes de HAL, la version FCM cible ne peut pas être mise à niveau.

Par exemple, les appareils Google Pixel 2 et Pixel 2 XL sont équipés de FCM version 2 cible. Bien qu'il implémente certaines HAL requises par compatibility_matrix.3.xml (par exemple, audio 4.0, health 2.0, etc.), ils ne suppriment pas android.hardware.radio.deprecated@1.0, qui est obsolète depuis la version 3 de FCM (Android 9). Par conséquent, ces les appareils ne peuvent pas mettre à niveau FCM cible vers la version 3.

Imposer les exigences du noyau pendant l'OTA

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

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

• CL 722283
• CL 722284
• CL 722345

Ces modifications introduisent l'indicateur de compilation PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS et quittez indicateur non défini pour les appareils lancés avec Android 9 ou moins élevée.

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

Pour en savoir plus sur cet indicateur de compilation, consultez Mettre à jour des appareils depuis Android 10.

Mettre à jour des appareils à partir d'Android 10

Android 10 introduit un nouvel indicateur de compilation, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS Pour les appareils lancé avec Android 10, cet indicateur défini automatiquement sur true. Lorsque l'indicateur est défini sur true : un script extrait la version du noyau et celui-ci à 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. Clients OTA sur les appareils équipés d'Android 10 lisez ces informations pour vérifier et la compatibilité avec d'autres appareils.
• Lors de la mise à jour vers Android 11, classification 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 : les éléments suivants:

• Modifiez le script pour prendre en charge le format de votre noyau et contribuer à AOSP.
• Définissez BOARD_KERNEL_VERSION sur la version du noyau. et BOARD_KERNEL_CONFIG_FILE au chemin d'accès au noyau créé fichier de configuration .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 jusqu'à false pour ignorer la vérification des exigences du noyau. Cela n'est pas recommandé, car toute incompatibilité est masquée et n'est détectée que lors de l'exécution de tests VTS après la mise à jour.

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