Implémenter des correctifs virtuels pour A/B

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

Vérifier correctement l'espace allocable lors du téléchargement latéral

Le téléchargement parallèle d'un package OTA complet sur un appareil virtuel A/B doté d'une superpartition dont la taille est inférieure à *2 * somme(taille des groupes de mises à 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, reconstruisez 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 avoir appliqué une mise à jour OTA, lors du processus de fusion VAB, un appel à update_engine_client --cancel provoque le plantage de CleanupPreviousUpdateAction. Une erreur de pointeur sauvage potentielle existe également lorsque markSlotSuccessful arrive en retard.

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

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

  • CL 1439792 (condition préalable à la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: annuler les tâches en attente lors de la destruction)
  • CL 1663460 (correction de l'erreur potentielle de pointeur sauvage lorsque markSlotSuccessful arrive en retard)

Empêcher la fusion prématurée de update_engine

Lorsqu'un appareil démarre (Android 11 ou version ultérieure) et que le démarrage est terminé, update_engine appelle ScheduleWaitMarkBootSuccessful() et WaitForMergeOrSchedule(). Cela lance le processus de fusion. Cependant, l'appareil redémarre vers l'ancien emplacement. Comme la fusion a déjà commencé, l'appareil ne démarre pas et devient inutilisable.

Ajoutez les modifications suivantes à votre arborescence source. Notez que la demande de changement 1664859 est facultative.

  • CL 1439792 (condition préalable à la CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: annuler les tâches en attente lors de la destruction)
  • CL 1663460 (correction de l'erreur potentielle de pointeur sauvage lorsque markSlotSuccessful arrive en retard)
  • CL 1664859 (facultatif : ajoutez unittest pour CleanupPreviousUpdateAction)

Vérifier la configuration correcte de dm-verity

Sous 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 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 de l'appareil, toute erreur de validation entraîne la corruption de la partition vbmeta et rend les appareils autres qu'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 validation 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 de vérification: Gérer les erreurs dm-verity.

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

Si vous créez des images système et des images de fournisseurs séparément, puis que vous utilisez merge_target_files pour les fusionner, les configurations A/B virtuelles peuvent être supprimées de manière incorrecte pendant le 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 des 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 passe à Android 13, il est possible que le ramdisk du fournisseur et le ramdisk générique contiennent une copie de snapuserd. Dans cette situation, Virtual A/B nécessite la copie système de snapuserd. Pour vous assurer que la copie correcte de snapuserd est en place, appliquez CL 2031243 (copiez snapuserd dans first_stage_ramdisk).