Wirtualne przeglądy A/B

Wirtualna aktualizacja A/B to główny mechanizm aktualizacji Androida. Wirtualne wersje A/B są oparte na starszych aktualizacjach A/B (patrz Aktualizacje systemu A/B) i wersjach niebędących A/B, które zostały wycofane w wersji 15, aby zmniejszyć ilość zajmowanego miejsca przez aktualizacje.

Testy A/B w wersji wirtualnej nie mają dodatkowego slotu na partycje dynamiczne (patrz partycje dynamiczne). Zamiast tego delta jest zapisywana w zrzucie, a następnie scalana z partycją podstawową po potwierdzeniu udanego rozruchu. Testy A/B w wersji wirtualnej używają formatu migawki na Androida. Zapoznaj się z formatem COW dla skompresowanych migawek, który umożliwia kompresowanie migawek i minimalizowanie wykorzystania miejsca na dysku. W przypadku pełnego OTA rozmiar zrzutu ekranu zmniejsza się o około 45% dzięki kompresji, a w przypadku przyrostowego OTA – o około 55%.

Android 12 oferuje opcję kompresji wirtualnej A/B do kompresji partycji ze zrzutami. Testy A/B w wersji wirtualnej zapewniają:

  • Wirtualne aktualizacje A/B są płynne (aktualizacja odbywa się całkowicie w tle, gdy urządzenie jest w stanie gotowości) tak jak aktualizacje A/B. Wirtualne aktualizacje A/B minimalizują czas, w którym urządzenie jest offline i nie nadaje się do użytku.
  • Aktualizacje testów A/B w wersji testowej można cofnąć. Jeśli nowy system operacyjny nie uruchomi się, urządzenia automatycznie wrócą do poprzedniej wersji.
  • Wirtualne aktualizacje A/B zajmują minimalną ilość dodatkowego miejsca, ponieważ dublują tylko partycje używane przez bootloader. Pozostałe partycje, które można aktualizować, są zabezpieczone za pomocą migawki.

Wprowadzenie i terminologia

W tej sekcji znajdziesz definicje terminów i opis technologii, która obsługuje testy A/B w sieci. Podczas instalacji OTA nowe dane systemu operacyjnego są zapisywane w nowym miejscu na fizyczne partycje lub na urządzeniu z Androidem w ramach funkcji COW. Po ponownym uruchomieniu urządzenia dane dynamicznej partycji są scalane z urządzeniem podstawowym za pomocą demona dm-user i snapuserd. Ten proces odbywa się całkowicie w przestrzeni użytkownika.

Device-mapper

Device-mapper to wirtualna warstwa bloków Linuksa, która jest często używana w Androidzie. W przypadku dynamicznych partycji partycje takie jak /system to zestaw urządzeń ułożonych warstwowo:

  • Na dole stosu znajduje się fizyczna superpartycja (na przykład /dev/block/by-name/super).
  • Pośrodku znajduje się urządzenie dm-linear, które określa, które bloki w superpartycji tworzą daną partycję dynamiczną. Na urządzeniu z testami A/B jest to /dev/block/mapper/system_[a|b], a na urządzeniu bez testów A/B – /dev/block/mapper/system.
  • U góry znajduje się urządzenie dm-verity utworzone dla zweryfikowanych partycji. To urządzenie sprawdza, czy bloki na urządzeniu dm-linear są prawidłowo podpisane. Wyświetla się jako /dev/block/mapper/system-verity i jest źródłem punktu montowania /system.

Rysunek 1 przedstawia zespół elementów pod punktem mocowania /system.

Umieszczanie partycji pod systemem

Rysunek 1. stos pod punktem podłączenia /system;

skompresowane zrzuty,

W Androidzie 12 i nowszych ze względu na to, że wymagania dotyczące miejsca na partycji /data mogą być wysokie, możesz włączyć skompresowane migawki w wersji kompilacji, aby zaspokoić większe wymagania dotyczące miejsca na partycji /data.

Wirtualne migawki z kompresją A/B są tworzone na podstawie tych komponentów dostępnych w Androidzie 12 i nowszych:

  • dm-user, moduł jądra podobny do FUSE, który umożliwia implementację blokowania urządzeń w przestrzeni użytkownika.
  • snapuserd, demon w przestrzeni użytkownika do implementacji nowego formatu zrzutu.

Te komponenty umożliwiają kompresję. Inne zmiany niezbędne do wdrożenia funkcji skompresowanych zrzutów zostały opisane w następnych sekcjach: format COW dla skompresowanych zrzutów, dm-user i snapuserd.

Format COW dla skompresowanych zrzutów

W Androidzie 12 i nowszych skompresowane migawki używają formatu COW specyficznego dla Androida. Format COW zawiera metadane dotyczące OTA oraz oddzielne bufory z operacjami COW i nowymi danymi systemu operacyjnego. W odróżnieniu od formatu zrzutu jądra, który umożliwiał tylko operacje zastępowania (zastępowanie bloku X w obrazie bazowym zawartością bloku Y w zrzucie), skompresowany format COW w Androidzie jest bardziej rozbudowany i obsługuje te operacje:

  • Copy: Block X in the base device should be replaced with block Y in the base device.
  • Zastąp: blok X na urządzeniu bazowym należy zastąpić zawartością bloku Y na zrzucie ekranu. Każdy z tych bloków jest skompresowany w formacie gz.
  • Zero: blok X na urządzeniu bazowym powinien zostać zastąpiony przez wszystkie zera.
  • XOR: urządzenie COW przechowuje bajty skompresowane za pomocą XOR między blokiem X a blokiem Y. (dostępne w Androidzie 13 i nowszych).

Pełne aktualizacje OTA składają się tylko z operacji zastępowania i zera. Incremental OTA updates can additionally have copy operations.

Pełny układ zrzutu na dysku wygląda tak:

format krowy

Rysunek 2. Formatowanie COW Androida na Dysku

dm-user

Moduł jądra dm-user umożliwia userspace implementowanie urządzeń blokowych device-mapper. Wpis w tabeli dm-user tworzy urządzenie różne w sekcji /dev/dm-user/<control-name>. Proces userspace może przeprowadzać sondowanie urządzenia w celu otrzymywania żądań odczytu i zapisu z jądra. Każde żądanie ma powiązany bufor dla przestrzeni użytkownika, który służy do wypełniania (w przypadku odczytu) lub propagowania (w przypadku zapisu) danych.

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

snapuserd

Komponent snapuserd w przestrzeni użytkownika w komponencie dm-user wdraża kompresję A/B. Snapuserd to demon w przestrzeni użytkownika odpowiedzialny za zapisywanie i odczytywanie urządzeń COW Androida. Wszystkie operacje wejścia/wyjścia dotyczące migawki muszą być wykonywane za pomocą tej usługi. Podczas instalacji OTA nowe dane systemu operacyjnego są zapisywane w migawcu przez snapuserd (z kompresją). Tutaj odbywa się też parsowanie metadanych i rozpakowywanie nowych danych bloku.

Kompresja XOR

W przypadku urządzeń uruchamianych z Androidem 13 lub nowszym funkcja kompresji XOR, która jest domyślnie włączona, umożliwia przechowywanie bajtów skompresowanych XOR w migawkach w przestrzeni użytkownika między starymi blokami a nowymi blokami. Gdy w ramach aktualizacji Virtual A/B zmienia się tylko kilka bajtów w bloku, schemat kompresji XOR zajmuje mniej miejsca niż domyślny schemat przechowywania, ponieważ migawki nie przechowują pełnych bajtów 4K. Zmniejszenie rozmiaru zrzutu ekranu jest możliwe, ponieważ dane XOR zawierają wiele zer i są łatwiejsze do skompresowania niż dane bloku w formacie RAW. Na urządzeniach Pixel kompresja XOR zmniejsza rozmiar zrzutu ekranu o 25–40%.

W przypadku urządzeń aktualizowanych do Androida 13 lub nowszego kompresja XOR musi być włączona. Więcej informacji znajdziesz w artykule Kompresja XOR.

Scalanie zrzutów

W przypadku urządzeń z Androidem 13 lub nowszym procesy tworzenia kopii zapasowej i łączenia kopii zapasowych w ramach kompresji wirtualnej metody A/B są wykonywane przez komponent snapuserd w przestrzeni użytkownika. W przypadku urządzeń, które są aktualizowane do Androida 13 lub nowszego, ta funkcja musi być włączona. Więcej informacji znajdziesz w artykule Połączenie przestrzeni użytkownika.

Poniżej opisujemy proces kompresji w ramach testu A/B:

  1. Platforma montuje partycję /system z urządzenia dm-verity, które jest umieszczone na urządzeniu dm-user. Oznacza to, że wszystkie operacje wejścia/wyjścia z katalogu głównego systemu plików są kierowane do dm-user.
  2. dm-user kieruje operacje wejścia/wyjścia do demona snapuserd w przestrzeni użytkownika, który obsługuje żądanie wejścia/wyjścia.
  3. Po zakończeniu operacji scalania framework łączy dm-verity z poziomu dm-linear (system_base) i usuwa dm-user.

Wirtualny proces kompresji A/B

Rysunek 3. Proces wirtualnej kompresji A/B

Proces łączenia zrzutów może zostać przerwany. Jeśli podczas procesu łączenia urządzenie zostanie ponownie uruchomione, proces ten zostanie wznowiony po ponownym uruchomieniu.

Przejścia początkowe

Podczas uruchamiania z skompresowanymi migającymi obrazami musi zostać uruchomiony pierwszy etap inicjalizacji snapuserd, aby zamontować partycje. To powoduje problem: gdy sepolicy zostanie załadowany i wdrożony, snapuserd zostanie umieszczony w niewłaściwym kontekście, a jego żądania odczytu będą się nieudać z powodu odmów ze strony selinux.

Aby to rozwiązać, snapuserd przechodzi w tryb synchroniczny z init w taki sposób:

  1. Pierwszy etap init uruchamia snapuserd z dysku RAM i zapisuje do niego otwarty deskryptor pliku w zmiennej środowiskowej.
  2. Pierwszy etap init przełącza system plików /root na partycję systemową, a następnie uruchamia kopię systemową init.
  3. Kopie systemu init odczytują połączoną politykę bezpieczeństwa jako ciąg znaków.
  4. Init wywołuje mlock() na wszystkich stronach opartych na ext4. Następnie dezaktywuje wszystkie tabele mapowania urządzeń dla urządzeń z zrzutem stanu i zatrzymuje snapuserd. Po tym nie można odczytywać danych z partycji, ponieważ powoduje to blokadę.
  5. Za pomocą opisu otwartego do kopii pliku ramdisk snapuserd program init ponownie uruchamia demona z poprawnym kontekstem selinux. Tabele mapowania urządzeń dla urządzeń z migawką są ponownie aktywowane.
  6. Init wywołuje munlockall() – można ponownie bezpiecznie wykonywać operacje wejścia/wyjścia.

Wykorzystanie miejsca

W tabeli poniżej porównano wykorzystanie miejsca na potrzeby różnych mechanizmów OTA, korzystając z rozmiarów systemu operacyjnego i OTA w Pixelu.

Wpływ na rozmiar nie A/B A/B Wirtualny A/B Wirtualny test A/B (skompresowany)
Oryginalny obraz fabryczny 4,5 GB super (3,8 GB obraz + 700 M zarezerwowane)1 9 GB super (3, 8 GB + 700 M MB zarezerwowane na 2 miejsca) 4,5 GB super (obraz 3,8 GB + 700 M zarezerwowane) 4,5 GB super (3,8 GB obraz + 700 MB zarezerwowane)
Inne partycje statyczne /cache Brak Brak Brak
Dodatkowe miejsce podczas aktualizacji OTA (miejsce zwrócone po zastosowaniu aktualizacji OTA) 1,4 GB na /data 0 3,8 GB2 na /data 2,1 GB2 na /data
Łączna ilość miejsca na dane wymagana do zastosowania aktualizacji OTA 5,9 GB3 (super i dane) 9 GB (super) 8,3 GB3 (super i dane) 6,6 GB3 (superczat i dane)

1 Wskazuje przypuszczalny układ na podstawie mapowania Pixela.

2Zakłada się, że nowy obraz systemu ma taki sam rozmiar co oryginalny.

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

Android 11 Virtual A/B

W Androidzie 11 funkcja Virtual A/B zapisała dane do partycji dynamicznej w formacie COW jądra. Zostało to ostatecznie wycofane, ponieważ format COW jądra nie obsługuje kompresji.

Android 12 Virtual A/B

W Androidzie 12 kompresja jest obsługiwana w postaci formatu COW specyficznego dla Androida. Ta wersja testów A/B w trybie wirtualnym wymagała przetłumaczenia pliku COW na potrzeby Androida na plik COW w formacie jądra. Ostatecznie w Androidzie 13 został on zastąpiony, co pozwoliło pozbyć się zależności od formatu Kernel COW i z funkcji dm-snapshot.

Aby wdrożyć testy A/B wirtualnej lub korzystać z możliwości skompresowanych zrzutów, przeczytaj artykuł Wdrażanie testów A/B wirtualnej.