В Android 10 представлена контрольная точка пользовательских данных (UDC), которая позволяет Android вернуться к предыдущему состоянию в случае сбоя обновления Android по беспроводной сети (OTA). При использовании UDC в случае сбоя OTA-обновления Android устройство может безопасно вернуться в предыдущее состояние. Хотя обновления A/B решают эту проблему для ранней загрузки, откат не поддерживается, когда изменяется раздел пользовательских данных (подключенный к /data ).
UDC позволяет устройству восстановить раздел пользовательских данных даже после изменения. Функция UDC достигает этого с помощью возможностей контрольных точек для файловой системы, альтернативной реализации, когда файловая система не поддерживает контрольные точки, интеграции с механизмом загрузчика A/B, а также поддержки обновлений, отличных от A/B, и поддержки привязки версии ключа. и предотвращение отката ключей.
Влияние пользователя
Функция UDC улучшает процесс обновления OTA для пользователей, поскольку меньше пользователей теряют свои данные при сбое обновления OTA. Это может уменьшить количество обращений в службу поддержки от пользователей, которые сталкиваются с проблемами в процессе обновления. Однако при сбое обновления OTA пользователи могут заметить, что устройство несколько раз перезагружается.
Как это работает
Функциональность контрольных точек в разных файловых системах
Для файловой системы F2FS UDC добавляет функциональность контрольной точки в вышестоящее ядро Linux 4.20 и поддерживает ее для всех распространенных ядер, поддерживаемых устройствами под управлением Android 10.
Для других файловых систем UDC использует виртуальное устройство сопоставления устройств с именем dm_bow для функциональности контрольной точки. dm_bow находится между устройством и файловой системой. Когда раздел монтируется, выполняется обрезка, заставляющая файловую систему выполнять команды обрезки для всех свободных блоков. dm_bow перехватывает эти обрезки и использует их для создания списка свободных блоков. Затем операции чтения и записи отправляются на устройство без изменений, но до того, как будет разрешена запись, данные, необходимые для восстановления, резервируются в свободный блок.
Процесс проверки
Когда монтируется раздел с флагом checkpoint=fs/block , Android вызывает restoreCheckpoint на диске, чтобы позволить устройству восстановить любую текущую контрольную точку. Затем init вызывает функцию needsCheckpoint , чтобы определить, находится ли устройство в состоянии загрузчика A/B или установлено количество повторных попыток обновления. Если одно из них верно, Android вызывает createCheckpoint либо для добавления флагов монтирования, либо для создания устройства dm_bow .
После монтирования раздела вызывается код контрольной точки для выдачи триммеров. Затем процесс загрузки продолжается в обычном режиме. В LOCKED_BOOT_COMPLETE Android вызывает commitCheckpoint , чтобы зафиксировать текущую контрольную точку, и обновление продолжится в обычном режиме.
Управление мастер-ключами
Мастер-ключи используются для шифрования устройства или других целей. Чтобы управлять этими ключами, Android откладывает вызовы на удаление ключей до тех пор, пока контрольная точка не будет зафиксирована.
Мониторинг здоровья
Демон работоспособности проверяет, достаточно ли места на диске для создания контрольной точки. Демон работоспособности находится в cp_healthDaemon в Checkpoint.cpp .
Демон работоспособности имеет следующие варианты поведения, которые можно настроить:
-
ro.sys.cp_msleeptime: определяет, как часто устройство проверяет использование диска. -
ro.sys.cp_min_free_bytes: контролирует минимальное значение, которое ищет демон работоспособности. -
ro.sys.cp_commit_on_full: контролирует, перезагружает ли демон работоспособности устройство или фиксирует контрольную точку и продолжает работу, когда диск заполнен.
API-интерфейсы контрольных точек
API-интерфейсы контрольных точек используются функцией UDC. Чтобы узнать о других API, используемых UDC, см. IVoid.aidl .
void startCheckpoint (int retry)
Создает контрольную точку.
Платформа вызывает этот метод, когда готова начать обновление. Контрольная точка создается до того, как файловые системы с контрольными точками, такие как пользовательские данные, монтируются для чтения и записи после перезагрузки. Если количество повторных попыток положительное, API обрабатывает повторные попытки отслеживания, а средство обновления вызывает needsRollback , чтобы проверить, требуется ли откат обновления. Если количество повторных попыток равно -1 , API зависит от решения загрузчика A/B.
Этот метод не вызывается при обычном обновлении A/B.
недействительными commitChanges ()
Фиксирует изменения.
Платформа вызывает этот метод после перезагрузки, когда изменения готовы к фиксации. Это вызывается перед записью данных (таких как изображения, видео, SMS, получение сервером) в пользовательские данные и перед BootComplete .
Если активного обновления с контрольными точками не существует, этот метод не действует.
прервать изменения ()
Принудительно перезагружается и возвращается к контрольной точке. Отменяет все изменения пользовательских данных с момента первой перезагрузки.
Фреймворк вызывает этот метод после перезагрузки, но до commitChanges . retry_counter уменьшается при вызове этого метода. Создаются записи журнала.
bool нуждается в откате ()
Определяет, требуется ли откат.
На устройствах без контрольных точек возвращает false . На устройствах с контрольными точками возвращает true во время загрузки без контрольных точек.
Внедрение УДК
Эталонная реализация
Пример того, как можно реализовать UDC, см. в dm-bow.c . Дополнительную документацию по этой функции см. в dm-bow.txt .
Настраивать
В on fs в вашем файле init.hardware.rc убедитесь, что у вас есть:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
В on late-fs файла init.hardware.rc убедитесь, что у вас есть:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
В вашем файле fstab.hardware убедитесь, что /data помечен как latemount .
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
Добавление раздела метаданных
Для UDC требуется раздел метаданных для хранения счетчика повторных попыток без загрузчика и ключей. Настройте раздел метаданных и предварительно смонтируйте его в /metadata .
В вашем файле fstab.hardware убедитесь, что /metadata помечен как earlymount или first_stage_mount .
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Инициализируйте раздел всеми нулями.
Добавьте следующие строки в BoardConfig.mk :
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Обновление систем
F2FS-системы
Для систем, использующих F2FS для форматирования данных, убедитесь, что ваша версия F2FS поддерживает контрольные точки. Дополнительные сведения см. в разделе Функциональность контрольных точек в разных файловых системах .
Добавьте флаг checkpoint=fs в раздел <fs_mgr_flags> fstab для устройства, смонтированного в /data .
Системы без F2FS
Для систем, отличных от F2FS, dm-bow должен быть включен в конфигурации ядра.
Добавьте флаг checkpoint=block в раздел <fs_mgr_flags> fstab для устройства, смонтированного в /data .
Проверка журналов
Записи журнала генерируются при вызове API-интерфейсов Checkpoint.
Проверка
Чтобы протестировать реализацию UDC, запустите набор тестов VtsKernelCheckpointTest VTS.