Implémenter un test A/B virtuel : correctifs

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 indépendant d'un package OTA complet sur un appareil virtuel A/B doté d'un super une partition dont la taille est inférieure à *2 * sum(taille des groupes de mise à jour)* peut échouer. par le code 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 l'application d'une mise à jour OTA, lors du processus de fusion VAB, un appel à update_engine_client --cancel provoque le plantage de CleanupPreviousUpdateAction. A une erreur potentielle de pointeur sauvage existe également lorsque markSlotSuccessful est 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. Elle maintient 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(). Le processus de fusion démarre. Toutefois, l'appareil redémarre sur l'ancien emplacement. Comme la fusion a déjà commencé, l'appareil ne parvient pas à démarre et devient inutilisable.

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

  • CL 1439792 (un condition préalable à la CL 1439372).
  • CL 1439372 (CleanupPreviousUpdateAction: annuler les tâches en attente lors de la destruction)
  • CL 1663460 (corrigez le erreur potentielle de pointeur sauvage lorsque markSlotSuccessful arrive en retard)
  • CL 1664859 (facultatif : ajouter 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 (par exemple, 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 suppression sont corrompus et rendent les appareils non A/B inopérants. De même, si une fusion a commencé, les appareils A/B peuvent également devenir inutilisables. Utilisez uniquement les 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 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 tests A/B virtuels sont correctes dans le fichier cible fusionné, appliquez les éléments suivants correctifs: CL 2084183 (fusionner des paires clé/val identiques dans les informations de partition dynamique)

Mettre à jour les composants nécessaires

À partir d'Android 13, snapuserd est passé de ramdisk du fournisseur à une version générique "ramdisk". Si votre appareil passe à Android 13, il est possible que les deux Le fournisseur ramdisk et le disque générique ramdisk contiennent une copie de snapuserd. Dans ce cas, 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).