В 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 для фиксации текущей контрольной точки, и обновление продолжается в обычном режиме.
Управление мастер-ключами
Ключи Keymaster используются для шифрования устройства или других целей. Чтобы управлять этими ключами, 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, см. в IVold.aidl .
void startCheckpoint (интервал повтора)
Создает контрольную точку.
Платформа вызывает этот метод, когда готова начать обновление. Контрольная точка создается до того, как файловые системы с контрольной точкой, такие как пользовательские данные, монтируются для чтения и записи после перезагрузки. Если количество повторов положительное, API обрабатывает повторные попытки отслеживания, а средство обновления вызывает needsRollback чтобы проверить, требуется ли откат обновления. Если количество повторов равно -1 , API подчиняется решению загрузчика A/B.
Этот метод не вызывается при обычном обновлении A/B.
недействительный коммитChanges()
Фиксирует изменения.
Платформа вызывает этот метод после перезагрузки, когда изменения готовы к фиксации. Это вызывается перед записью данных (таких как изображения, видео, SMS, получение сервером) в пользовательские данные и перед BootComplete .
Если активного обновления контрольной точки не существует, этот метод не имеет эффекта.
прерывание изменений()
Принудительная перезагрузка и возврат к контрольной точке. Отменяет все изменения пользовательских данных с момента первой перезагрузки.
Платформа вызывает этот метод после перезагрузки, но до commitChanges . retry_counter уменьшается при вызове этого метода. Создаются записи журнала.
bool требует отката()
Определяет, требуется ли откат.
На устройствах без контрольной точки возвращает false . На устройствах с контрольной точкой возвращает true во время загрузки без контрольной точки.
Внедрить УДК
Эталонная реализация
Пример реализации UDC см. в dm-bow.c . Дополнительную документацию по этой функции см. в dm-bow.txt .
Настраивать
В файле init.hardware.rc on fs убедитесь, что у вас есть:
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, запустите набор тестов VTS VtsKernelCheckpointTest .