update_verifier Проверка целостность разделов после OTA-обновления Тип файла: команда
Комментарии update_verifier вызывается init и будет выполнять проверку только в том случае, если это первая загрузка после OTA-обновления A/B (https://source.android.com/devices/tech/ota/ab/#after_reboot). update_verifier полагается на device-mapper-verity (dm-verity) для обнаружения любых повреждений на проверяемые разделы (https://source.android.com/security/verifiedboot). Проверка будет пропущена, если на устройстве не включена функция dm-verity. При обнаружении сбоев проверки устройство будет перезагружено, хотя триггер перезагрузка зависит от режима dm-verity: enforcing mode: dm-verity перезагружает устройство eio mode: dm-verity не читает, а update_verifier перезагружает устройство other mode: не поддерживается и update_verifier перезагружает устройство Все эти перезагрузки предотвращают загрузку устройства в известном поврежденном состоянии. Если устройство постоянно не загружается в новый слот, загрузчик должен пометить слот как незагружаемый и вызвать откат к старому слоту. Текущий слот будет помечен как успешно загруженный, если верификатор дойдет до конца после проверки. --------------------------------------- https://source.android.com/devices/tech/ota/ab После установки Для каждого раздела, для которого определен шаг после установки, update_engine монтирует новый раздел в определенное место и выполняет программу, указанную в OTA, относительно смонтированного раздела. Например, если постустановочная программа определена как usr/bin/postinstall в системном разделе, этот раздел из неиспользуемого слота будет смонтирован в фиксированном месте (например, /postinstall_mount ), а /postinstall_mount/usr/bin/postinstallвыполняется /postinstall_mount/usr/bin/postinstall команда. Чтобы постустановка прошла успешно, старое ядро ??должно уметь: Смонтировать новый формат файловой системы. Тип файловой системы не может измениться, если в старом ядре его не поддерживает, включая такие детали, как алгоритм сжатия, используемый при использовании сжатой файловой системы (например, SquashFS). Разобраться с форматом программы после установки нового раздела. Если используется исполняемый и компонуемый формат (ELF), он должен быть совместим со старым ядром (например, 64-битная новая программа, работающая на старом 32-битном ядре, если архитектура переключилась с 32-битной на 64-битную сборку). Если загрузчику ( ld ) не будет дано указание использовать другие пути или создать статический двоичный файл, библиотеки будут загружаться из старого образа системы, а не из нового. Например, вы можете использовать сценарий оболочки в качестве постустановочной программы, интерпретируемой двоичным файлом оболочки старой системы с символом #! вверху), затем настроить пути к библиотекам из новой среды для выполнения более сложной двоичной программы после установки. В качестве альтернативы вы можете запустить этап после установки из выделенного раздела меньшего размера, чтобы разрешить обновление формата файловой системы в основном системном разделе без проблем обратной совместимости или промежуточных обновлений. Это позволит пользователям обновляться до последней версии непосредственно из заводского образа. Новая постустановочная программа ограничена политиками SELinux, определенными в старой системе. Таким образом, этап после установки подходит для выполнения задач, предусмотренных конструкцией на данном устройстве, или других задач с максимальной эффективностью. Ннапример, обновление прошивки или загрузчика с поддержкой A/B, подготовка копий баз данных для новой версии и т.д. Этап после установки не подходит для разовых исправлений ошибок перед перезагрузкой, требующих непредвиденных разрешений. Выбранная постустановочная программа запускается в postinstall контексте SELinux. Все файлы в новом смонтированном разделе будут помечены postinstall_file независимо от их атрибутов после перезагрузки в эту новую систему. Изменения атрибутов SELinux в новой системе не повлияют на этап после установки. Если постустановочной программе требуются дополнительные разрешения, их необходимо добавить в постустановочный контекст. После перезагрузки После перезагрузки update_verifier запускает проверку целостности с помощью dm-verity. Эта проверка начинается до zygote, чтобы службы Java не вносили какие-либо необратимые изменения, которые могли бы помешать безопасному откату. Во время этого процесса загрузчик и ядро также могут вызвать перезагрузку, если проверенная загрузка или dm-verity обнаружат какое-либо повреждение. После завершения проверки update_verifier помечает загрузку как успешную. update_verifier будет читать только блоки, перечисленные в /data/ota_package/care_map.txt , который включен в пакет A/B OTA при использовании кода AOSP. Клиент обновления системы Java, такой как GmsCore, извлекает care_map.txt , устанавливает разрешение на доступ перед перезагрузкой устройства и удаляет извлеченный файл после того, как система успешно загрузится в новую версию. |
 |