Wdrożenie testu A/B – łaty.

Wybierz poniższe poprawki, aby rozwiązać wymienione poniżej znane problemy.

Prawidłowo sprawdzaj ilość dostępnego miejsca podczas instalowania z nieoficjalnych źródeł

Przenoszenie pełnego pakietu OTA na urządzenie z testami A/B, które ma superpartycję o rozmiarze mniejszym niż *2 * suma(rozmiar grup aktualizacji)*, może się nie udać. W dzienniku odzyskiwania /tmp/recovery.log pojawi się wtedy ten komunikat:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Oto przykład dziennika:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Jeśli napotkasz ten problem, wybierz wiśnię CL 1399393, odbudowywanie i flashowanie partycji rozruchowej lub przywracania, jeśli urządzenie nie korzysta z opcji odzyskiwania. uruchamianie.

Naprawianie błędu podziału na segmenty podczas scalania

Po zastosowaniu aktualizacji OTA podczas procesu scalania VAB wywołanie funkcji update_engine_client --cancel powoduje awarię funkcji CleanupPreviousUpdateAction. O potencjalny błąd symbolu wieloznacznego występuje też, gdy markSlotSuccessful się spóźni.

Problem został rozwiązany przez dodanie funkcji StopActionInternal. CleanupPreviousUpdateAction anuluje oczekujące zadania podczas usuwania. Zapewnia ona która śledzi identyfikator oczekującego zadania w pętli wiadomości. Wł. zniszczenie, oczekujące zadanie zostanie anulowane w celu uniknięcia wystąpienia błędu segfault.

Aby naprawić błąd SIGSEGV, upewnij się, że w drzewie źródłowym Androida 11 znajdują się poniższe zmiany awarie podczas scalania w update_engine:

  • CL 1439792 (warunek wstępny dla CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: anuluj oczekujące zadania w przypadku zniszczenia)
  • CL 1663460 (rozwiąż potencjalny błąd symbolu wieloznacznego, gdy markSlotSuccessful się spóźnia)

Zapobieganie przedwczesnemu scalaniu update_engine

Po uruchomieniu urządzenia (z Androidem 11 lub nowszym) i uruchomieniu urządzenia update_engine dzwoni do: ScheduleWaitMarkBootSuccessful() i WaitForMergeOrSchedule() Rozpocznie się proces łączenia. Urządzenie uruchamia się jednak w starym gnieździe. Ponieważ scalanie już się rozpoczęło, urządzenie nie może uruchamia się i przestaje działać.

Wdroż w drzewie źródłowym te zmiany. Uwaga: CL 1664859 jest opcjonalny.

  • CL 1439792 (a Warunki wstępne wymagane do przestrzegania ustawy CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: anuluj oczekujące zadania w przypadku zniszczenia)
  • CL 1663460 (poprawić potencjalny błąd wskaźnika względna, gdy markSlotSuccessful jest opóźniony)
  • CL 1664859 (opcjonalnie - dodaj unittest dla CleanupPreviousUpdateAction)

Zadbaj o prawidłową konfigurację dm-verity

Na Androidzie 11 i nowszych urządzeniach można przypadkowo skonfigurować te opcje dm-verity:

  • CONFIG_DM_VERITY_AVB=y w jądrze
  • Bootloader skonfigurowany do korzystania z dowolnego trybu weryfikacji (np. AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) bez AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

W przypadku tej konfiguracji urządzenia każdy błąd wersji powoduje, że partycja vbmeta jest mogą ulec uszkodzeniu i sprawiać, że urządzenia inne niż A/B przestaną działać. Analogicznie, urządzenia A/B również mogą przestać działać. Korzystaj tylko z AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO tryb poprawności.

  1. Ustaw CONFIG_DM_VERITY_AVB=n w rdzeniu.
  2. Skonfiguruj urządzenia do korzystania z Tryb AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Więcej informacji znajdziesz w dokumentacji dotyczącej poprawności: Obsługa standardu dm-verity Błędy.

Sprawdź, czy scalony plik jest poprawnie skonfigurowany

Jeśli tworzysz obrazy systemu i obrazu dostawcy osobno, a następnie używasz do ich scalania polecenia merge_target_files, konfiguracje A/B mogą zostać nieprawidłowo usunięte podczas procesu scalania. Aby potwierdzić, że wirtualne A/B w scalonym pliku docelowym są prawidłowe konfiguracje, zastosuj następujące poprawki: CL 2084183 (scal identyczne pary klucz-wartość w dynamicznych informacjach o partycji)

Zaktualizuj niezbędne komponenty

W Androidzie 13 pakiet snapuserd został przeniesiony z dysku pamięci RAM dostawcy do ogólnej i „ramdisk”. Jeśli Twoje urządzenie aktualizuje się do Androida 13, możliwe, że oba te problemy pliki Ramdisk dostawcy i ogólny ramdisk zawierają kopię pliku snapuserd. W tym w przypadku wirtualnego A/B wymagana jest kopia systemowa pliku snapuserd. Aby mieć pewność, że snapuserd jest prawidłową kopią, zastosuj CL 2031243 (kopia snapuserd do first_stage_ramdisk).