Внедрение виртуальных A/B-патчей

Выберите следующие исправления, чтобы устранить следующие известные проблемы.

Правильно проверяйте выделяемое пространство при боковой загрузке

Загрузка полного пакета OTA на виртуальное устройство A/B, имеющее суперраздел размером меньше *2 * сумма(размер групп обновлений)*, может завершиться ошибкой со следующим сообщением в журнале восстановления /tmp/recovery.log :

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

Вот пример журнала:

[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.

Если вы столкнулись с этой проблемой, выберите версию CL 1399393 , пересоберите и прошейте загрузочный раздел или раздел восстановления, если устройство не использует восстановление в качестве загрузки.

Исправление ошибки сегментации во время слияния

После применения обновления OTA, во время процесса слияния VAB, вызов update_engine_client --cancel приводит к сбою CleanupPreviousUpdateAction . Потенциальная ошибка wild pointer также существует, когда markSlotSuccessful приходит с опозданием.

Это было решено путем добавления функции StopActionInternal . CleanupPreviousUpdateAction отменяет ожидающие задачи при уничтожении. Он поддерживает переменную, которая отслеживает идентификатор ожидающей задачи в цикле сообщений. При уничтожении ожидающая задача отменяется, чтобы избежать segfault.

Убедитесь, что в исходном дереве Android 11 внесены следующие изменения, чтобы исправить сбои SIGSEGV в update_engine во время слияния:

  • CL 1439792 (необходимое условие для CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : отмена ожидающих задач при уничтожении)
  • CL 1663460 (исправлена ​​потенциальная ошибка указателя wild, когда markSlotSuccessful приходит с опозданием)

Предотвращение преждевременного слияния update_engine

Когда устройство загружается (Android 11 и выше) и загрузка завершается, update_engine вызывает ScheduleWaitMarkBootSuccessful() и WaitForMergeOrSchedule() . Это запускает процесс слияния. Однако устройство перезагружается в старый слот. Поскольку слияние уже началось, устройство не загружается и становится неработоспособным.

Добавьте следующие изменения в исходное дерево. Обратите внимание, что CL 1664859 является необязательным.

  • CL 1439792 (необходимое условие для CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : отмена ожидающих задач при уничтожении)
  • CL 1663460 (исправлена ​​потенциальная ошибка указателя wild, когда markSlotSuccessful приходит с опозданием)
  • CL 1664859 (необязательно — добавьте unittest для CleanupPreviousUpdateAction )

Убедитесь в правильности конфигурации dm-verity

В Android 11 и более поздних версиях устройства могут быть непреднамеренно настроены с использованием следующих параметров dm-verity:

  • CONFIG_DM_VERITY_AVB=y в ядре
  • Загрузчик настроен на использование любого режима проверки (например, AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ), без AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

При такой конфигурации устройства любая ошибка проверки приводит к повреждению раздела vbmeta и делает неработоспособными устройства, отличные от A/B. Аналогично, если началось слияние, устройства A/B также могут стать неработоспособными. Используйте только режим проверки AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Установите CONFIG_DM_VERITY_AVB=n в ядре.
  2. Настройте устройства для использования вместо этого режима AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Для получения дополнительной информации обратитесь к документации Verity: Обработка ошибок dm-verity .

Убедитесь, что объединенный файл правильно настроен.

Если вы создаете системные образы и образы поставщиков отдельно, то при использовании merge_target_files для их слияния конфигурации Virtual A/B могут быть неправильно удалены во время процесса слияния. Чтобы проверить правильность конфигураций Virtual A/B в объединенном целевом файле, примените следующие исправления: CL 2084183 (слияние идентичных пар key/val в динамической информации о разделе)

Обновите необходимые компоненты

Начиная с Android 13, snapuserd был перемещен из ramdisk поставщика в generic ramdisk. Если ваше устройство обновляется до Android 13, возможно, что и ramdisk поставщика, и generic ramdisk содержат копию snapuserd . В этой ситуации Virtual A/B требует системную копию snapuserd . Чтобы убедиться, что правильная копия snapuserd находится на месте, примените CL 2031243 (скопируйте snapuserd в first_stage_ramdisk).