Внедрение виртуальных 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 (слияние идентичных пар ключ/значение в динамической информации о разделах).

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

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