Wirtualne przeglądy A/B

Android ma 2 mechanizmy aktualizacji: aktualizacje A/B (bezproblemowe) i aktualizacje inne niż A/B. Aby uprościć kod i usprawnić proces aktualizacji, w Androidzie 11 2 mechanizmy na potrzeby wirtualnych testów A/B zapewniają płynną aktualizację wszystkich przy jak najniższym koszcie pamięci. Android 12 oferuje opcję wirtualnej kompresji A/B do kompresowania partycji zrzutów. W Androidzie 11 i 12 poniższe elementy zastosuj:

• Wirtualne aktualizacje typu A/B są łatwe, tak jak aktualizacje typu A/B. Wirtualne aktualizacje A/B do zminimalizowania czasu, gdy urządzenie jest offline i bezużyteczne.
• Wirtualne aktualizacje A/B można wycofać. Jeśli nie uda się uruchomić nowego systemu operacyjnego, urządzenia automatycznie przywrócą poprzednią wersję systemu.
• Wirtualne aktualizacje typu A/B wykorzystują minimalną ilość dodatkowego miejsca, ponieważ duplikują tylko na partycjach używanych przez program rozruchowy. Inne partycje, które można zaktualizować, to zapisane.

Informacje ogólne i terminologia

W tej sekcji definiuje się terminologię i opis technologii, która obsługuje wirtualne A/B.

Mapowanie urządzeń

Device-mapper to wirtualna warstwa blokowa w systemie Linux, używana często na Androidzie. Na partycje dynamiczne, takie jak /system to stos urządzeń wielowarstwowych:

• U dołu stosu znajduje się fizyczna partycja super (na przykład /dev/block/by-name/super).
• Pośrodku znajduje się urządzenie dm-linear określające, które bloki w parametrze Super danej partycji. Wygląda to tak /dev/block/mapper/system_[a|b] na urządzeniu A/B lub /dev/block/mapper/system na urządzeniu innym niż A/B.
• U góry znajduje się urządzenie z dm-verity utworzone na potrzeby zweryfikowanych partycji. To urządzenie sprawdza, czy blokady na urządzeniu dm-linear są podpisane . Wygląda on jako /dev/block/mapper/system-verity i jest źródłem punktu podłączania przez /system.

Na ilustracji 1 widać stos pod punktem podłączania /system.

Rysunek 1. Stos w punkcie podłączania /system

migracja-dm

Wirtualne A/B wykorzystuje moduł dm-snapshot, czyli moduł mapowania urządzeń do tworzenia zrzutów stanu urządzenia pamięci masowej. Kiedy używasz funkcji dm-snapshot, w: odtwarzanie:

• Urządzenie podstawowe to urządzenie, którego kopia została utworzona. Podstawowy element na tej stronie urządzenie jest zawsze partycją dynamiczną, np. systemową lub dostawcą.
• Urządzenie copy-on-zapis (COW) służące do rejestrowania zmian na urządzeniu podstawowym. it może mieć dowolny rozmiar, ale musi być na tyle duży, aby zmieścić wszystkie zmiany urządzenia podstawowego.
• Urządzenie zrzut jest tworzone z użyciem celu snapshot. Zapisze w urządzenia z migawkami są zapisywane w urządzeniu COW. Odczyty ze zrzutu z urządzenia podstawowego lub urządzenia COW, w zależności od czy informacje, do których dostęp uzyskał, zostały zmienione przez zrzut.
• Urządzenie origin jest tworzone za pomocą środowiska docelowego snapshot-origin. Czyta w urządzenie źródłowe odczytuje dane bezpośrednio z urządzenia podstawowego. Zapisuje w punkcie początkowym urządzenia zapisują dane bezpośrednio na urządzeniu podstawowym, ale tworzona jest kopia zapasowa oryginalnych danych. do urządzenia COW.

Rysunek 2. Mapowanie urządzeń na potrzeby zrzutu Dm

Skompresowane zrzuty

W Androidzie 12 i nowszych, ponieważ wymagania dotyczące miejsca partycja /data może być wysoka, możesz włączyć skompresowane zrzuty w kompilować, aby spełnić wymagania dotyczące większej ilości miejsca na partycji /data.

Wirtualne skompresowane zrzuty A/B są tworzone na podstawie następujących komponentów na Androida 12 lub nowszego:

• dm-user – moduł jądra podobny do FUSE, który umożliwia korzystanie z przestrzeni użytkownika; w celu implementacji urządzeń blokowych.
• snapuserd – demon przestrzeni użytkownika implementujący nowy zrzut .

Te komponenty umożliwiają kompresję. Inne niezbędne zmiany wprowadzone w zastosowania funkcji skompresowanych zrzutów ekranu znajdziesz w kolejnych sekcjach: format COW dla skompresowanych zrzutów dysku, dm-user i Snapuserd.

Format COW dla skompresowanych zrzutów

W Androidzie 12 i nowszych skompresowane zrzuty dysku korzystają z Format COW. Format podobny do wbudowanego jądra używanego do nieskompresowania zrzutów, format COW skompresowanych zrzutów ma naprzemienne sekcje metadanych i danych. Metadane oryginalnego formatu są dozwolone tylko na potrzeby zastąpienia. operacje: zastąp blok X w obrazie podstawowym zawartością bloku Y widoczne na zrzucie ekranu. Format skompresowanych zrzutów COW jest bardziej ekspresyjny, obsługuje następujące operacje:

• Kopiowanie: blok X na urządzeniu podstawowym należy zastąpić blokiem Y w urządzenia podstawowego.
• Zastąp: blokada X na urządzeniu podstawowym powinna zostać zastąpiona zawartością. bloku Y na zrzucie ekranu. Każdy z tych bloków jest skompresowany w GZ.
• Zero: blokada X na urządzeniu podstawowym powinna być zastąpiona zerami.
• XOR: urządzenie COW przechowuje skompresowane bajty XOR między blokami X i zablokuj Y. Ta funkcja jest dostępna w Androidzie 13 i nowszych.

Pełne aktualizacje OTA obejmują tylko operacje replace i zero. Przyrostowy Aktualizacje OTA mogą dodatkowo zawierać operacje kopiowania.

użytkownik MDM na Androidzie 12

Moduł jądra systemu zarządzania tożsamością użytkownika umożliwia usłudze userspace wdrożenie bloku mapowania urządzenia urządzenia. Wpis w tabeli DM-user tworzy inne urządzenie /dev/dm-user/<control-name> Proces userspace może odpytywać urządzenie które odbierają od jądra żądania odczytu i zapisu. Z każdą prośbą jest powiązane bufor dla przestrzeni użytkownika, która ma zostać zapełniona (w przypadku odczytu) lub propagowana (w przypadku zapisu).

Moduł jądra dm-user zapewnia nowy, widoczny dla użytkownika interfejs jądra. który nie jest częścią bazy kodu kernel.org nadrzędnego. Do tego momentu Google zastrzega sobie prawo do modyfikowania interfejsu dm-user w Androidzie.

Snapuserd

Komponent przestrzeni użytkownika snapuserd do dm-user implementuje wirtualne A/B kompresję.

w nieskompresowanej wersji wirtualnego A/B (na Androidzie 11 lub starszym lub w Androidzie 12 bez opcji skompresowanego zrzutu), a urządzenie COW to plik nieprzetworzony. Po włączeniu kompresji funkcja COW zamiast jako urządzenia dm-user, które jest połączone z instancją demon snapuserd.

Jądro nie używa nowego formatu COW. Zatem komponent snapuserd tłumaczy żądania między formatem COW Androida a wbudowanym jądrem format:

Rysunek 3. Schemat blokowy mechanizmu Snapuserd jako translatora między Androidem a jądrem Formaty COW

To tłumaczenie i dekompresja nigdy nie występują na dysku. snapuserd przechwytuje odczyty i zapisy COW występujące w jądrze; implementuje je za pomocą formatu COW na Androida.

Kompresja XOR

W przypadku urządzeń z Androidem 13 lub nowszym parametr Funkcja kompresji XOR, która jest domyślnie włączona, umożliwia korzystanie z przestrzeni użytkownika zrzutów do przechowywania skompresowanych bajtów XOR między starymi a nowymi blokami. Kiedy tylko kilka bajtów w bloku zmienia się w aktualizacji wirtualnej A/B, XOR schemat pamięci masowej kompresji wykorzystuje mniej miejsca niż domyślny schemat pamięci masowej ponieważ zrzuty nie przechowują pełnych danych o rozmiarze 4000 bajtów. Zmniejszenie rozmiaru zrzutu wynosi możliwe, ponieważ dane XOR zawierają wiele zer i są łatwiejsze do skompresowania niż nieprzetworzone blokad danych. Na urządzeniach Pixel kompresja XOR zmniejsza rozmiar zrzutu o 25% i o 40%.

Na urządzeniach z Androidem 13 lub nowszym XOR musi być włączona kompresja. Aby dowiedzieć się więcej, zobacz XOR .

Wirtualne procesy kompresji A/B

Ta sekcja zawiera szczegółowe informacje na temat procesu wirtualnej kompresji A/B używanego w Android 13 i Android 12.

Odczytywanie metadanych (Android 12)

Metadane są tworzone przez demona snapuserd. Metadane to przede wszystkim mapowania 2 identyfikatorów (po 8 bajtów każdy), które reprezentują sektory do scalania. W języku: dm-snapshot nazwa: disk_exception.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Wyjątek dysku jest używany, gdy stary fragment danych został zastąpiony nowym.

Demon snapuserd odczytuje wewnętrzny plik COW za pomocą biblioteki COW oraz tworzy metadane dla każdej operacji COW występujących w pliku COW.

Odczyty metadanych są inicjowane z poziomu dm-snapshot w jądrze po utworzeniu urządzenia dm- snapshot.

Na ilustracji poniżej znajdziesz schemat sekwencji ścieżki zamówienia reklamowego dla metadanych budowy.

Rysunek 4. Przepływ sekwencji w ścieżce zamówienia reklamowego w konstrukcji metadanych

Łączenie (Android 12)

Po zakończeniu procesu uruchamiania mechanizm aktualizacji oznaczy to gniazdo jako rozruchowe. i inicjuje scalanie, przełączając środowisko docelowe dm-snapshot na Wartość docelowa: dm-snapshot-merge.

dm-snapshot analizuje metadane i inicjuje zamówienie reklamowe scalania dla każdego dysku wyjątek. Poniżej znajdziesz ogólny przegląd ścieżki scalonego zamówienia reklamowego.

Rysunek 5. Omówienie ścieżki scalania zamówienia reklamowego

Jeśli podczas scalania urządzenie zostanie zrestartowane, scalanie zostanie wznowione po ponownym uruchomieniu i scalanie.

Tworzenie warstw za pomocą mapowania urządzeń

W przypadku urządzeń z Androidem 13 lub nowszym parametr w ramach kompresji wirtualnej A/B wykonywane są procedury scalania zrzutów oraz zrzutów przez komponent przestrzeni użytkownika snapuserd. Urządzenia przechodzące na Androida w wersji 13 lub nowszej, ta funkcja musi być włączona. Dla: Więcej informacji znajdziesz w sekcji Obszar użytkownika Scal.

Poniżej opisujemy proces wirtualnej kompresji A/B:

1. Platforma podłącza partycję /system na urządzeniu dm-verity, który znajduje się na urządzeniu z systemem dm-user. Oznacza to, że każde I/O z głównego systemu plików jest kierowana na adres dm-user.
2. dm-user kieruje wejścia/wyjścia do demona snapuserd przestrzeni użytkownika, który obsługuje żądania I/O.
3. Po zakończeniu operacji scalania platforma zwija dm-verity góra dm-linear (system_base) i usuwa dm-user.

Rysunek 6. Proces wirtualnej kompresji A/B

Proces scalania zrzutów można przerwać. Jeśli urządzenie zostanie zrestartowane podczas procesu scalania, zostanie on wznowiony po ponownym uruchomieniu.

Przejścia inicjowane

W przypadku uruchamiania ze skompresowanymi zrzutami musi rozpoczynać się pierwszy etap snapuserd, aby podłączyć partycje. Stwarza to problem: podczas wczytywania interfejsu sepolicy i wymuszane, snapuserd trafia w niewłaściwy kontekst, a jego żądania odczytu z odrzucaniem selinux.

Aby rozwiązać ten problem, interfejs snapuserd przechodzi w blokadzie z zastosowaniem init w następujący sposób:

1. Pierwszy etap init uruchamia plik snapuserd z dysku RAM i zapisuje otwartą deskryptora pliku w zmiennej środowiskowej.
2. Pierwszy etap init przełącza główny system plików na partycję systemową, następnie wykonuje kopię systemową skryptu init.
3. Kopia systemowa elementu init odczytuje połączoną z nim zasadę sepolicy w ciągu znaków.
4. Na wszystkich stronach obsługiwanych przez ext4 funkcja Init wywołuje metodę mlock(). Następnie dezaktywuje wszystkie w przypadku urządzeń z migawkami i zatrzymuje funkcję snapuserd. Po tym nie może odczytywać danych z partycji, ponieważ powoduje to ich zakleszczenie.
5. Używanie otwartego deskryptora do kopii pamięci RAM snapuserd, init ponownie uruchamia demona z prawidłowym kontekstem selinux. Tabele mapowania urządzeń w przypadku urządzeń z migawkami są ponownie aktywowane.
6. Init wywołuje metodę munlockall() – można bezpiecznie wykonać zamówienie reklamowe jeszcze raz.

Wykorzystanie miejsca

W tej tabeli znajdziesz porównanie wykorzystania miejsca przez różne aktualizacje OTA z zastosowaniem rozmiarów systemu operacyjnego i OTA telefonu Pixel.

¹ Wskazuje układ przypuszczalny na podstawie mapowania pikseli.

² Zakładamy, że nowy obraz systemu ma taki sam rozmiar jak oryginalny.

³ Wymagania dotyczące miejsca są tymczasowe do czasu ponownego uruchomienia.

Aby wdrożyć funkcję wirtualnego A/B lub skorzystać z funkcji skompresowanych zrzutów, zapoznaj się z artykułem Wdrożenie wirtualnej wersji A/B