Внедрение виртуальных 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 . Также существует потенциальная ошибка «дикого указателя», когда markSlotSuccessful поступает с опозданием.

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

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

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

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

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

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

  • CL 1439792 (необходимое условие для CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : отмена отложенных задач при уничтожении)
  • CL 1663460 (исправлена ​​потенциальная ошибка дикого указателя, возникающая при запоздалом появлении 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 был перенесён из RAM-диска поставщика в RAM-диск общего назначения. Если ваше устройство обновляется до Android 13, возможно, что и RAM-диск поставщика, и RAM-диск общего назначения содержат копию snapuserd . В этом случае для Virtual A/B требуется системная копия snapuserd . Чтобы убедиться, что установлена ​​правильная копия snapuserd , примените CL 2031243 (скопируйте snapuserd в RAM-диск first_stage).