Android 10 wprowadza punkt kontroli danych użytkownika (UDC), który
pozwala Androidowi na przywrócenie poprzedniego stanu, gdy urządzenie z Androidem bezprzewodowo
Błąd aktualizacji (OTA). 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 wcześniejszego uruchomienia i przywrócenia zmian
nie jest obsługiwana, gdy partycja danych użytkownika (zainstalowana w /data
) jest zmodyfikowana.
UDC umożliwia urządzeniu przywrócenie partycji danych użytkownika nawet po tym, zmodyfikowane. 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
Działanie punktów kontrolnych 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 innych systemach plików UDC używa urządzenia wirtualnego z programem mapowania urządzeń o nazwie dm_bow
dla funkcji punktu kontrolnego. Element dm_bow
znajduje się między urządzeniem a plikiem.
systemu. Podłączenie partycji powoduje przycięcie, przez co system plików
wykonaj polecenia przycinania wszystkich wolnych bloków. 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
Po podłączeniu partycji z flagą checkpoint=fs/block
Android wywołuje
restoreCheckpoint
na dysku, aby umożliwić urządzeniu przywrócenie bieżących
i 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 któraś z tych wartości jest prawda, Android wywołuje metodę createCheckpoint
, aby dodać punkt montowania
lub utwórz urządzenie z systemem dm_bow
.
Po podłączeniu partycji wywoływany jest kod punktu kontrolnego, który służy do przycinania.
Proces uruchamiania będzie wtedy kontynuowany w zwykły sposób. Android: LOCKED_BOOT_COMPLETE
Wywołuje metodę commitCheckpoint
, aby zatwierdzić bieżący punkt kontrolny i aktualizację
będzie przebiegał bez zakłóceń.
Zarządzanie kluczami Keymaster
Klucze Keymaster służą do szyfrowania urządzenia i do innych celów. Aby nimi zarządzać Android odkłada usuwanie kluczowych połączeń do momentu zatwierdzenia punktu kontrolnego.
Monitorowanie stanu
Demon stanu sprawdza, czy na dysku jest wystarczająca ilość miejsca do utworzenia
i punktu kontrolnego. demon zdrowia znajduje się w:
cp_healthDaemon
w aplikacji Checkpoint.cpp
.
Demon stanu ma te zachowania, które można skonfigurować:
ro.sys.cp_msleeptime
: Określa, jak często urządzenie sprawdza użycie dysku.ro.sys.cp_min_free_bytes
: Kontroluje minimalną wartość, której oczekuje demon.ro.sys.cp_commit_on_full
: Określa, czy demon stanu ma ponownie uruchomić urządzenie czy zatwierdzić i kontynuować, gdy dysk jest zapełniony.
Interfejsy API punktu kontrolnego
Funkcja UDC używa interfejsów API punktów kontrolnych. Inne interfejsy API używane przez UDC znajdziesz tutaj
IVold.aidl
void startCheckpoint(ponowna próba inicjowania)
Tworzy punkt kontrolny.
Platforma wywołuje tę metodę, gdy jest gotowa do rozpoczęcia aktualizacji.
jest tworzony przed skutkami złamania
podłączonych (R/W) po ponownym uruchomieniu. 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
wymagana jest aktualizacja. 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 wykonywania zwykłej aktualizacji typu A/B.
void CommitChanges()
Zatwierdź zmiany.
Platforma wywołuje tę metodę po ponownym uruchomieniu, gdy zmiany są gotowe do wprowadzenia
zaangażował się. Jest ono wywoływane przed danymi (takimi jak zdjęcia, filmy, SMS-y, serwer)
odbioru) jest zapisywany w danych użytkownika i przed BootComplete
.
Jeśli nie ma żadnej aktywnej aktualizacji punktów kontrolnych, ta metoda nie powoduje żadnych skutków.
abortChanges()
Wymusza ponowne uruchomienie i powraca do punktu kontrolnego. Porzuca wszystkie modyfikacje danych użytkownika od pierwszego restartu.
Platforma wywołuje tę metodę po ponownym uruchomieniu, ale przed commitChanges
.
Wartość retry_counter
jest zmniejszana po wywołaniu tej metody. Wpisy logu są
.
wartość logiczna needRollback()
Określa, czy wymagane jest wycofanie.
Na urządzeniach niebędących punktami kontrolnymi 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
Sprawdź, czy w pliku on fs
w pliku init.hardware.rc
masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Sprawdź, czy w pliku on late-fs
w pliku init.hardware.rc
masz:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
W pliku fstab.hardware
sprawdź, czy /data
jest oznaczony tagiem 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 podłącz ją wcześniej na /metadata
.
W pliku fstab.hardware
sprawdź, czy /metadata
jest oznaczony tagiem earlymount
lub first_stage_mount
.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Zainicjuj partycję do zera.
Dodaj do pliku BoardConfig.mk
te wiersze:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Aktualizowanie systemów
Systemy F2FS
Jeśli używasz systemu Windows do formatowania danych, sprawdź, czy masz tę wersję obsługuje punkty kontrolne. Aby uzyskać więcej informacji, zapoznaj się z sekcją Funkcja Checkpoint w 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
.
Sprawdź dzienniki
Wpisy logu są generowane przy wywoływaniu interfejsów Checkpoint API.
Weryfikacja
Aby przetestować implementację UDC, uruchom zbiór VTS VtsKernelCheckpointTest
testów.