Android 10 wprowadza punkt kontrolny danych użytkownika (UDC), który umożliwia Androidowi przywrócenie poprzedniego stanu, gdy aktualizacja Androida przez Wi-Fi (OTA) zakończy się niepowodzeniem. Dzięki UDC, jeśli aktualizacja OTA Androida nie powiedzie się, urządzenie może
bezpieczne przywrócenie do poprzedniego stanu. Chociaż aktualizacje A/B rozwiązują ten problem w przypadku wczesnego uruchamiania, wycofanie nie jest obsługiwane, gdy modyfikowana jest partycja danych użytkownika (zamontowana na /data).
UDC umożliwia urządzeniu przywrócenie partycji danych użytkownika nawet po jej zmodyfikowaniu. Służy do tego funkcja UDC dzięki funkcjom punktów kontrolnych systemu plików, czyli alternatywną implementację, gdy system plików nie obsługuje punktów kontrolnych, integrację z mechanizmem programu rozruchowego A/B oraz aktualizacje inne niż A/B oraz obsługa wiązania wersji klucza i przywracania klucza; profilaktyki.
Wpływ na użytkowników
Funkcja UDC ułatwia aktualizację OTA, ponieważ mniejsza liczba użytkowników ich dane w przypadku niepowodzenia aktualizacji OTA. Może to zmniejszyć liczbę połączeń z zespołem pomocy od użytkowników, którzy napotkali problemy podczas aktualizacji. Gdy jednak funkcja OTA aktualizacja się nie powiedzie, użytkownicy mogą zauważyć, że urządzenie kilka razy uruchamia się ponownie.
Jak to działa
Funkcja punktu kontrolnego w różnych systemach plików
W przypadku systemu plików F2FS UDC dodaje funkcję punktu kontrolnego do nadrzędnego jądro Linuksa 4.20 i przenosi je do wszystkich popularnych jąder obsługiwanych przez urządzenia; z Androidem 10.
W przypadku innych systemów plików UDC używa urządzenia wirtualnego mapowania urządzeń o nazwie dm_bow do obsługi funkcji punktów kontrolnych. dm_bow znajduje się między urządzeniem a systemem plików. Gdy partycja jest zamontowana, jest wydawane polecenie przycinania, które powoduje wydanie poleceń przycinania przez system plików we wszystkich wolnych blokach. dm_bow przechwytuje te zmiany i zastosowania
skonfigurować bezpłatną listę zablokowanych adresów. Zapisy i zapisy są następnie wysyłane na urządzenie
niezmodyfikowane, ale przed zezwoleniem na zapis zapisywane są dane potrzebne do przywrócenia;
do swobodnego bloku.
Proces punktu kontrolnego
Gdy partycja z flagą checkpoint=fs/block jest zamontowana, Android wywołuje restoreCheckpoint na dysku, aby umożliwić urządzeniu przywrócenie bieżącego punktu kontrolnego. init wywołuje następnie funkcję needsCheckpoint, aby określić, czy
urządzenie jest w stanie programu rozruchowego A/B lub ustawiło ponowną próbę aktualizacji
. Jeśli jedno z tych ustawień ma wartość Prawda, Android wywołuje createCheckpoint, aby dodać flagi montowania lub skompilować urządzenie dm_bow.
Po podłączeniu partycji wywoływany jest kod punktu kontrolnego, który służy do przycinania.
Następnie proces uruchamiania trwa normalnie. W miejscu LOCKED_BOOT_COMPLETE Android wywołuje funkcję commitCheckpoint, aby zatwierdzić bieżący punkt kontrolny, a aktualizacja będzie kontynuowana w normalny sposób.
Zarządzanie kluczami Keymaster
Klucze Keymaster służą do szyfrowania urządzenia i do innych celów. Aby zarządzać tymi kluczami, Android opóźnia wywołania usuwania kluczy do momentu zatwierdzenia punktu kontrolnego.
Monitorowanie stanu
Demon zdrowia sprawdza, czy jest wystarczająco dużo miejsca na dysku na utworzenie punktu kontrolnego. demon zdrowia znajduje się w:
cp_healthDaemon
w aplikacji Checkpoint.cpp.
Demon diagnostyki ma następujące zachowania, które można skonfigurować:
ro.sys.cp_msleeptime: określa, jak często urządzenie ma sprawdzać wykorzystanie dysku.ro.sys.cp_min_free_bytes: Kontroluje minimalną wartość, której oczekuje demon.ro.sys.cp_commit_on_full: określa, czy demon zdrowia ma ponownie uruchomić urządzenie, czy zatwierdzić punkt kontrolny i kontynuować, gdy dysk jest pełny.
Interfejsy API punktów kontrolnych
Funkcja UDC używa interfejsów API punktów kontrolnych. Inne interfejsy API używane przez UDC znajdziesz w IVold.aidl.
void startCheckpoint(ponowna próba inicjowania)
tworzy punkt kontrolny.
Platforma wywołuje tę metodę, gdy jest gotowa do rozpoczęcia aktualizacji. Punkt kontrolny jest tworzony przed zamontowaniem w trybie R/W po restarcie takich zweryfikowanych systemów plików, jak userdata. Jeśli liczba ponownych prób jest dodatnia, interfejs API obsługuje
ponownych prób śledzenia, a aktualizator wywołuje metodę needsRollback, aby sprawdzić, czy funkcja została przywrócona
jest wymagana. Jeśli liczba ponownych prób wynosi -1, interfejs API przekierowuje do wersji A/B
z oceną programu rozruchowego.
Ta metoda nie jest wywoływana podczas zwykłej aktualizacji A/B.
void commitChanges()
zatwierdza zmiany.
Framework wywołuje tę metodę po ponownym uruchomieniu, gdy zmiany są gotowe do zatwierdzenia. Jest on wywoływany przed zapisaniem danych (takich jak zdjęcia, filmy, SMS-y, potwierdzenie odbioru serwera) w plikach danych użytkownika i przed wywołaniem funkcji BootComplete.
Jeśli nie ma żadnej aktywnej aktualizacji punktów kontrolnych, ta metoda nie powoduje żadnych skutków.
abortChanges()
Wymusza ponowne uruchomienie i powrót do punktu kontrolnego. Odrzuca wszystkie zmiany danych użytkownika od pierwszego ponownego uruchomienia.
Platforma wywołuje tę metodę po ponownym uruchomieniu, ale przed commitChanges.
Wartość retry_counter maleje, gdy wywoływana jest ta metoda. Wpisy logu są
.
bool needsRollback()
Określa, czy wymagane jest wycofanie.
Na urządzeniach bez punktów kontrolnych zwraca false. Na urządzeniach punktów kontrolnych zwraca true
podczas uruchamiania bez punktu kontrolnego.
Wdrażanie UDC
Implementacja referencyjna
Oto przykład wdrożenia UDC: dm-bow.c. Dodatkową dokumentację dotyczącą tej funkcji znajdziesz w sekcji dm-bow.txt
Konfiguracja
W pliku on fs w pliku init.hardware.rc sprawdź, czy masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
W pliku on late-fs w pliku init.hardware.rc sprawdź, czy masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
W pliku fstab.hardware sprawdź, czy /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 systemu innego niż rozruchowy oraz
klawiszy. Skonfiguruj partycję metadanych i zamontuj ją wcześnie w /metadata.
W pliku fstab.hardware sprawdź, czy /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
Inicjalizowanie partycji przez wypełnienie jej zerami.
Dodaj do pliku BoardConfig.mk te wiersze:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Aktualizowanie systemów
Systemy F2FS
W przypadku systemów, które używają F2FS do formatowania danych, upewnij się, że Twoja wersja F2FS obsługuje punkty kontrolne. Więcej informacji znajdziesz w artykule Funkcja punktu kontrolnego w różnych systemach plików.
Dodaj flagę checkpoint=fs do sekcji <fs_mgr_flags> we fstab dla parametru
urządzenie podłączone w tym miejscu: /data.
Systemy inne niż F2FS
W systemach innych niż F2FS w konfiguracji jądra musi być włączona zasada dm-bow.
Dodaj flagę checkpoint=block do sekcji <fs_mgr_flags> we fstab dla parametru
urządzenie podłączone w tym miejscu: /data.
Sprawdzanie dzienników
Wpisy logu są generowane przy wywoływaniu interfejsów Checkpoint API.
Weryfikacja
Aby przetestować implementację UDC, uruchom zestaw VtsKernelCheckpointTest testów VTS.