W systemie Android 10 wprowadzono punkt kontroli danych użytkownika (UDC), który umożliwia przywrócenie poprzedniego stanu systemu Android w przypadku niepowodzenia aktualizacji systemu Android przez sieć bezprzewodową (OTA). Dzięki UDC, jeśli aktualizacja Androida OTA nie powiedzie się, urządzenie może bezpiecznie przywrócić poprzedni stan. Chociaż aktualizacje A/B rozwiązują ten problem w przypadku wczesnego rozruchu, wycofywanie zmian nie jest obsługiwane w przypadku modyfikacji partycji danych użytkownika (zamontowanej na /data ).
UDC umożliwia urządzeniu przywrócenie partycji danych użytkownika nawet po modyfikacji. Funkcja UDC osiąga to dzięki możliwościom punktów kontrolnych w systemie plików, alternatywnej implementacji, gdy system plików nie obsługuje punktów kontrolnych, integracji z mechanizmem A/B programu ładującego przy jednoczesnej obsłudze aktualizacji innych niż A/B oraz obsłudze powiązania wersji klucza i zapobieganie przywróceniu klucza.
Wpływ użytkownika
Funkcja UDC poprawia jakość aktualizacji OTA dla użytkowników, ponieważ mniej użytkowników traci swoje dane w przypadku niepowodzenia aktualizacji OTA. Może to zmniejszyć liczbę zgłoszeń do pomocy technicznej od użytkowników, którzy napotkali problemy podczas procesu aktualizacji. Jeśli jednak aktualizacja OTA nie powiedzie się, użytkownicy mogą zauważyć wielokrotne ponowne uruchomienie urządzenia.
Jak to działa
Funkcjonalność punktu kontrolnego w różnych systemach plików
W przypadku systemu plików F2FS UDC dodaje funkcję punktu kontrolnego do jądra Linuksa starszego wersji 4.20 i przenosi ją do wszystkich popularnych jąder obsługiwanych przez urządzenia z systemem Android 10.
W przypadku innych systemów plików UDC używa wirtualnego urządzenia mapującego urządzenia o nazwie dm_bow w celu zapewnienia funkcjonalności punktu kontrolnego. dm_bow znajduje się pomiędzy urządzeniem a systemem plików. Kiedy partycja jest zamontowana, wydawane jest polecenie przycięcia, które powoduje, że system plików wydaje polecenia przycięcia dla wszystkich wolnych bloków. dm_bow przechwytuje te wykończenia i używa ich do skonfigurowania listy wolnych bloków. Odczyty i zapisy są następnie wysyłane do urządzenia w stanie niezmodyfikowanym, ale przed zezwoleniem na zapis dane potrzebne do przywrócenia są zapisywane w wolnym bloku.
Proces punktu kontrolnego
Po zamontowaniu partycji z flagą checkpoint=fs/block system Android wywołuje na dysku restoreCheckpoint , aby umożliwić urządzeniu przywrócenie dowolnego bieżącego punktu kontrolnego. init następnie wywołuje funkcję needsCheckpoint , aby sprawdzić, czy urządzenie znajduje się w stanie A/B programu ładującego lub czy ma ustawioną liczbę ponownych prób aktualizacji. Jeśli jedno z nich jest prawdą, Android wywołuje createCheckpoint w celu dodania flag montowania lub zbudowania urządzenia dm_bow .
Po zamontowaniu partycji wywoływany jest kod punktu kontrolnego w celu wydania przycięć. Proces rozruchu będzie następnie kontynuowany normalnie. W LOCKED_BOOT_COMPLETE Android wywołuje commitCheckpoint , aby zatwierdzić bieżący punkt kontrolny, a aktualizacja jest kontynuowana normalnie.
Zarządzaj kluczami głównymi kluczami
Klucze Keymaster służą do szyfrowania urządzenia lub do innych celów. Aby zarządzać tymi kluczami, Android opóźnia wywołania usuwania kluczy do momentu zatwierdzenia punktu kontrolnego.
Monitoruj zdrowie
Demon kondycji sprawdza, czy jest wystarczająca ilość miejsca na dysku, aby utworzyć punkt kontrolny. Demon kondycji znajduje się w cp_healthDaemon w Checkpoint.cpp .
Demon kondycji ma następujące zachowania, które można skonfigurować:
-
ro.sys.cp_msleeptime: Kontroluje częstotliwość sprawdzania użycia dysku przez urządzenie. -
ro.sys.cp_min_free_bytes: Kontroluje minimalną wartość, której szuka demon kondycji. -
ro.sys.cp_commit_on_full: kontroluje, czy demon kondycji ponownie uruchamia urządzenie, czy zatwierdza punkt kontrolny i kontynuuje, gdy dysk jest pełny.
Interfejsy API punktów kontrolnych
Interfejsy API punktu kontrolnego są używane przez funkcję UDC. Informacje na temat innych interfejsów API używanych przez UDC można znaleźć w pliku IVold.aidl .
nieważny punkt kontrolny startu (ponowna próba)
Tworzy punkt kontrolny.
Struktura wywołuje tę metodę, gdy jest gotowa do rozpoczęcia aktualizacji. Punkt kontrolny jest tworzony przed zamontowaniem systemów plików objętych punktami kontrolnymi, takich jak dane użytkownika, odczyt/zapis po ponownym uruchomieniu. Jeśli liczba ponownych prób jest dodatnia, interfejs API obsługuje ponowne próby śledzenia, a aktualizator wywołuje needsRollback w celu sprawdzenia, czy wymagane jest wycofanie aktualizacji. Jeśli liczba ponownych prób wynosi -1 , interfejs API odracza ocenę programu ładującego A/B.
Ta metoda nie jest wywoływana podczas normalnej aktualizacji A/B.
unieważnij zatwierdzenie zmian()
Zatwierdza zmiany.
Struktura wywołuje tę metodę po ponownym uruchomieniu, gdy zmiany są gotowe do zatwierdzenia. Jest to wywoływane przed zapisaniem danych (takich jak zdjęcia, wideo, SMS, potwierdzenie odbioru z serwera) w danych użytkownika i przed BootComplete .
Jeśli nie istnieje żadna aktywna aktualizacja z punktem kontrolnym, ta metoda nie ma żadnego efektu.
przerwać zmiany()
Wymusza ponowne uruchomienie i powrót do punktu kontrolnego. Porzuca wszystkie modyfikacje danych użytkownika od pierwszego ponownego uruchomienia.
Struktura wywołuje tę metodę po ponownym uruchomieniu, ale przed commitChanges . retry_counter jest zmniejszany po wywołaniu tej metody. Generowane są wpisy dziennika.
bool potrzebuje wycofania()
Określa, czy wymagane jest wycofanie zmian.
Na urządzeniach innych niż punkty kontrolne zwraca false . Na urządzeniach z punktem kontrolnym zwraca wartość true podczas rozruchu bez punktu kontrolnego.
Wdrażaj UDC
Implementacja referencyjna
Przykład implementacji UDC można znaleźć w dm-bow.c . Dodatkową dokumentację dotyczącą tej funkcji można znaleźć w pliku dm-bow.txt .
Organizować coś
W pliku on fs w pliku init.hardware.rc upewnij się, że masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
W on late-fs w pliku init.hardware.rc upewnij się, że masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Upewnij się, że w pliku fstab.hardware /data jest oznaczony jako 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
Dodaj partycję metadanych
UDC wymaga partycji metadanych do przechowywania liczby ponownych prób i kluczy programu innego niż bootloader. Skonfiguruj partycję metadanych i wcześnie zamontuj ją w /metadata .
Upewnij się, że w pliku fstab.hardware /metadata jest oznaczony jako earlymount lub first_stage_mount .
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Zainicjuj partycję wszystkimi zerami.
Dodaj następujące wiersze do BoardConfig.mk :
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Aktualizuj systemy
Systemy F2FS
W przypadku systemów używających F2FS do formatowania danych upewnij się, że Twoja wersja F2FS obsługuje punkty kontrolne. Aby uzyskać więcej informacji, zobacz Funkcjonalność punktu kontrolnego w różnych systemach plików .
Dodaj flagę checkpoint=fs do sekcji <fs_mgr_flags> fstab dla urządzenia zamontowanego w /data .
Systemy inne niż F2FS
W przypadku systemów innych niż F2FS, dm-bow musi być włączony w konfiguracji jądra.
Dodaj flagę checkpoint=block do sekcji <fs_mgr_flags> fstab dla urządzenia zamontowanego w /data .
Sprawdź logi
Wpisy dziennika są generowane podczas wywoływania interfejsów API Checkpoint.
Walidacja
Aby przetestować implementację UDC, uruchom zestaw testów VTS VtsKernelCheckpointTest .