Implémenter un test A/B virtuel : correctifs

Sélectionnez les correctifs suivants pour résoudre les problèmes connus ci-dessous.

Vérifier correctement l'espace allouable lors du transfert de fichiers

L'installation d'un package OTA complet sur un appareil Virtual A/B dont la superpartition est plus petite que *2 * sum(taille des groupes de mise à jour) peut échouer avec le message suivant dans le journal de récupération : /tmp/recovery.log.

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Voici un exemple de journal :

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Si vous rencontrez ce problème, sélectionnez CL 1399393, recompilez et flashez la partition de démarrage ou la partition de récupération si l'appareil n'utilise pas la récupération comme démarrage.

Corriger l'erreur de segmentation lors de la fusion

Après l'application d'une mise à jour OTA, lors du processus de fusion VAB, un appel à update_engine_client --cancel entraîne le plantage de CleanupPreviousUpdateAction. Une erreur de pointeur sauvage potentiel existe également lorsque markSlotSuccessful arrive tardivement.

Ce problème a été résolu en ajoutant la fonction StopActionInternal. CleanupPreviousUpdateAction annule les tâches en attente lors de la destruction. Il conserve une variable qui suit l'ID de tâche de la tâche en attente dans la boucle de message. Lors de la destruction, la tâche en attente est annulée pour éviter une erreur de segmentation.

Assurez-vous que les modifications suivantes sont présentes dans votre arborescence source Android 11 pour corriger les plantages SIGSEGV dans update_engine lors de la fusion :

  • CL 1439792 (prérequis pour la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction : annuler les tâches en attente lors de la suppression)
  • CL 1663460 (correction de l'erreur potentielle de pointeur générique lorsque markSlotSuccessful arrive tard)

Empêcher la fusion prématurée d'update_engine

Lorsqu'un appareil démarre (Android 11 et versions ultérieures) et que le démarrage est terminé, update_engine appelle ScheduleWaitMarkBootSuccessful() et WaitForMergeOrSchedule(). Le processus de fusion commence. Toutefois, l'appareil redémarre sur l'ancien emplacement. Comme la fusion a déjà commencé, l'appareil ne parvient pas à démarrer et devient inutilisable.

Ajoutez les modifications suivantes à votre arborescence source. Notez que la CL 1664859 est facultative.

  • CL 1439792 (prérequis pour la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction : annuler les tâches en attente lors de la suppression)
  • CL 1663460 (correction de l'erreur potentielle de pointeur générique lorsque markSlotSuccessful arrive tard)
  • CL 1664859 (facultatif : ajoutez unittest pour CleanupPreviousUpdateAction)

Assurez-vous que la configuration dm-verity est correcte.

Dans Android 11 et versions ultérieures, les appareils peuvent être configurés par inadvertance avec les options dm-verity suivantes :

  • CONFIG_DM_VERITY_AVB=y dans le noyau
  • Le bootloader est configuré pour utiliser n'importe quel mode de vérification (tel que AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) sans AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Avec cette configuration d'appareil, toute erreur de vérification entraîne la corruption de la partition vbmeta et rend les appareils non A/B inutilisables. De même, si une fusion a commencé, les appareils A/B peuvent également devenir inutilisables. N'utilisez que le mode de vérification AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Définissez CONFIG_DM_VERITY_AVB=n dans le noyau.
  2. Configurez les appareils pour qu'ils utilisent plutôt le mode AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Pour en savoir plus, consultez la documentation Verity : Gestion des erreurs dm-verity.

Vérifier que le fichier fusionné est correctement configuré

Si vous créez des images système et des images de fournisseur séparément, puis que vous utilisez merge_target_files pour les fusionner, les configurations Virtual A/B peuvent être supprimées de manière incorrecte lors du processus de fusion. Pour vérifier que les configurations A/B virtuelles sont correctes dans le fichier cible fusionné, appliquez les correctifs suivants : CL 2084183 (fusionner les paires clé/valeur identiques dans les informations de partition dynamique)

Mettre à jour les composants nécessaires

À partir d'Android 13, snapuserd a été déplacé du ramdisk du fournisseur vers le ramdisk générique. Si votre appareil est mis à niveau vers Android 13, il est possible que le ramdisk du fournisseur et le ramdisk générique contiennent tous les deux une copie de snapuserd. Dans ce cas, Virtual A/B nécessite la copie système de snapuserd. Pour vous assurer que la bonne copie de snapuserd est en place, appliquez CL 2031243 (copiez snapuserd dans first_stage_ramdisk).