Wdrażanie testów A/B wirtualnych

Aby wdrożyć wirtualne testy A/B na nowym urządzeniu lub doposażyć urządzenie, które jest już dostępne na rynku, musisz wprowadzić zmiany w kodzie specyficznym dla urządzenia.

Flagi kompilacji

Urządzenia, które korzystają z wirtualnych testów A/B, muszą być skonfigurowane jako urządzenie A/B i muszą być uruchamiane z partycjami dynamicznymi.

W przypadku urządzeń, które są uruchamiane z wirtualnymi testami A/B, ustaw je tak, aby dziedziczyły podstawową konfigurację urządzenia z wirtualnymi testami A/B:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

Urządzenia uruchamiane z wirtualnymi testami A/B potrzebują tylko połowy rozmiaru płyty dla BOARD_SUPER_PARTITION_SIZE, ponieważ sloty B nie znajdują się już w super. Oznacza to, że BOARD_SUPER_PARTITION_SIZE musi być większy lub równy sum(rozmiar grup aktualizacji) + narzut, który z kolei musi być większy lub równy sum(rozmiar partycji) + narzut.

Aby włączyć skompresowane zrzuty z wirtualnymi testami A/B w Androidzie 13 i nowszym, odziedzicz tę podstawową konfigurację:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/vabc_features.mk)

Umożliwia to tworzenie zrzutów w przestrzeni użytkownika za pomocą wirtualnych testów A/B przy użyciu metody kompresji no-op. Następnie możesz skonfigurować metodę kompresji na jedną z obsługiwanych metod: zstd i lz4. W Androidzie 15 kompresję można dodatkowo dostosować do potrzeb urządzenia. Więcej informacji znajdziesz w artykule Dostrajanie kompresji.

PRODUCT_VIRTUAL_AB_COMPRESSION_METHOD := lz4
PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 65536

Aby włączyć skompresowane zrzuty z wirtualnymi testami A/B w Androidzie 12, odziedzicz tę podstawową konfigurację:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)

Kompresja XOR

W przypadku urządzeń, które są aktualizowane do Androida 13 lub nowszego, funkcja kompresji XOR nie jest domyślnie włączona. Aby włączyć kompresję XOR, dodaj te informacje do pliku .mk urządzenia.

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.compression.xor.enabled=true

Kompresja XOR jest domyślnie włączona w przypadku urządzeń, które dziedziczą z android_t_baseline.mk.

Scalanie w przestrzeni użytkownika

W nowoczesnej wersji wirtualnych testów A/B (Android T i nowsze) proces scalania zrzutów odbywa się w całości w przestrzeni użytkownika. Ta zmiana jest możliwa dzięki snapuserd i dm-user. Urządzenia uruchamiane z Androidem 13 lub nowszym mają domyślnie włączone scalanie w przestrzeni użytkownika, a w przypadku starszych urządzeń, które są aktualizowane, tę właściwość można ustawić za pomocą tego polecenia:

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.userspace.snapshots.enabled=true

Warstwa HAL sterowania rozruchem

Warstwa HAL sterowania rozruchem udostępnia interfejs, za pomocą którego klienci OTA mogą sterować slotami rozruchowymi. Wirtualne testy A/B wymagają aktualizacji do nowszej wersji warstwy HAL sterowania rozruchem, ponieważ potrzebne są dodatkowe interfejsy API, aby zapewnić ochronę programu rozruchowego podczas flashowania lub przywracania ustawień fabrycznych. Najnowszą wersję definicji warstwy HAL znajdziesz w plikach IBootControl.hal i types.hal.

// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
    NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };

// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
    setSnapshotMergeStatus(MergeStatus status)
        generates (bool success);
    getSnapshotMergeStatus()
        generates (MergeStatus status);
}

// Recommended implementation

Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
    // Write value to persistent storage
    // e.g. misc partition (using libbootloader_message)
    // bootloader rejects wipe when status is SNAPSHOTTED
    // or MERGING
}

Zmiany w fstab

Integralność partycji metadanych jest niezbędna do procesu rozruchu, zwłaszcza bezpośrednio po zastosowaniu aktualizacji OTA. Dlatego partycja metadanych musi zostać sprawdzona, zanim zostanie zamontowana przez first_stage_init. Aby to zapewnić, dodaj flagę check fs_mgr do wpisu /metadata. Oto przykład:

/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check

Wymagania dotyczące jądra systemu

Aby włączyć tworzenie zrzutów, ustaw CONFIG_DM_SNAPSHOT na true.

W przypadku urządzeń korzystających z F2FS dodaj do użytkownika poprawki jądra flagę f2fs: export FS_NOCOW_FL, aby naprawić przypinanie plików. Dodaj też poprawkę jądra f2fs: support aligned pinned file.

Wirtualne testy A/B korzystają z funkcji dodanych w jądrze w wersji 4.3: bitu stanu overflow w elementach docelowych snapshot i snapshot-merge. Wszystkie urządzenia uruchamiane z Androidem 9 lub nowszym powinny mieć już jądro w wersji 4.4 lub nowszej.

Aby włączyć skompresowane zrzuty, minimalna obsługiwana wersja jądra to 4.19. Ustaw CONFIG_DM_USER=m lub CONFIG_DM_USER=y. Jeśli używasz pierwszej opcji (modułu), moduł musi być załadowany w ramdysku pierwszego etapu. Możesz to zrobić, dodając ten wiersz do pliku Makefile urządzenia:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Zmiany w narzędziach Fastboot

W Androidzie 11 wprowadzono te zmiany w protokole Fastboot:

• getvar snapshot-update-status – zwraca wartość, którą warstwa HAL sterowania rozruchem przekazała do programu rozruchowego:
  • Jeśli stan to MERGING, program rozruchowy musi zwrócić merging.
  • Jeśli stan to SNAPSHOTTED, program rozruchowy musi zwrócić snapshotted.
  • W przeciwnym razie program rozruchowy musi zwrócić none.
• snapshot-update merge – kończy operację scalania, w razie potrzeby uruchamiając tryb recovery lub fastbootd. To polecenie jest prawidłowe tylko wtedy, gdy snapshot-update-status ma wartość merging, i jest obsługiwane tylko w fastbootd.
• snapshot-update cancel – ustawia stan scalania warstwy HAL sterowania rozruchem na CANCELLED. To polecenie jest nieprawidłowe, gdy urządzenie jest zablokowane.
• erase lub wipe – polecenie erase lub wipe dotyczące metadata, userdata lub partycji zawierającej stan scalania warstwy HAL sterowania rozruchem powinno sprawdzić stan scalania zrzutu. Jeśli stan to MERGING lub SNAPSHOTTED, urządzenie powinno przerwać operację.
• set_active – polecenie set_active, które zmienia aktywny slot, powinno sprawdzić stan scalania zrzutu. Jeśli stan to MERGING, urządzenie powinno przerwać operację. Slot można bezpiecznie zmienić w stanie SNAPSHOTTED.

Te zmiany mają zapobiegać przypadkowemu uniemożliwieniu uruchomienia urządzenia, ale mogą zakłócać działanie zautomatyzowanych narzędzi. Gdy polecenia są używane jako komponent flashowania wszystkich partycji, np. podczas wykonywania polecenia fastboot flashall, zalecamy użycie tego procesu:

1. Wyślij zapytanie getvar snapshot-update-status.
2. Jeśli odpowiedź to merging lub snapshotted, wyślij polecenie snapshot-update cancel.
3. Wykonaj kroki flashowania.

Zmniejszanie wymagań dotyczących miejsca na dane

W przypadku urządzeń, które nie mają w super przydzielonego pełnego miejsca na dane A/B i które w razie potrzeby mają korzystać z /data, zdecydowanie zalecamy używanie narzędzia do mapowania bloków. Narzędzie do mapowania bloków zapewnia spójność przydziału bloków między kompilacjami, co zmniejsza liczbę niepotrzebnych zapisów w zrzucie. Jest to opisane w sekcji Zmniejszanie rozmiaru OTA.

Algorytmy kompresji OTA

Pakiety OTA można dostosować do różnych danych o skuteczności. Android udostępnia kilka obsługiwanych metod kompresji (lz4, zstd i none), które mają różne kompromisy między czasem instalacji, wykorzystaniem miejsca COW, czasem rozruchu i czasem scalania zrzutów. Domyślnie w przypadku wirtualnych testów A/B z kompresją włączona jest lz4 compression method.

Dostrajanie kompresji

Algorytmy kompresji można dodatkowo dostosować za pomocą 2 metod: (poziom kompresji) (stopień kompresji osiągnięty kosztem szybkości) i (współczynnik kompresji) (maksymalny rozmiar okna kompresji). Poziom kompresji jest dostępny w przypadku niektórych algorytmów, np. zstd, a zmiana poziomu wiąże się z kompromisem między szybkością a współczynnikiem kompresji. Współczynnik kompresji określa maksymalny rozmiar okna kompresji używany podczas instalacji OTA. Domyślna wartość to 64 kB, ale można ją zastąpić, dostosowując parametr kompilacji PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR. Obsługiwane współczynniki kompresji: 4 kB, 8 kB, 16 kB, 32 kB, 64 kB, 128 kB i 256 kB.

PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 65536

Przyrostowa aktualizacja OTA na Pixelu 8 Pro

Pełna aktualizacja OTA na Pixelu 8 Pro