Wdrożenie testu A/B – łaty.

Aby rozwiązać te znane problemy, wybierz odpowiednie łaty.

Sprawdzanie dostępnego miejsca podczas sideloadowania

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 CL 1399393, ponownie utwórz i sflashuj partycję rozruchową lub partycję odzyskiwania, jeśli urządzenie nie używa partycji odzyskiwania jako partycji rozruchowej.

Naprawianie błędu segmentacji podczas scalania

Po zastosowaniu aktualizacji OTA podczas procesu scalania VAB wywołanie update_engine_client --cancel powoduje awarię CleanupPreviousUpdateAction. Możliwy błąd nieprawidłowego wskaźnika występuje też wtedy, gdy markSlotSuccessful jest opóźniony.

Problem został rozwiązany przez dodanie funkcji StopActionInternal. CleanupPreviousUpdateAction anuluje oczekujące zadania podczas usuwania. Utrzymuje zmienną, która śledzi identyfikator oczekującego zadania w pętli wiadomości. W przypadku metody destroy oczekujące zadanie jest anulowane, aby uniknąć błędu segmentacji.

Aby naprawić SIGSEGVawarie w update_engine podczas scalania, sprawdź, czy w drzewie źródłowym Androida 11 znajdują się te zmiany:

  • CL 1439792 (warunek wstępny dla CL 1439372)
  • CL 1439372(CleanupPreviousUpdateAction: anulowanie oczekujących zadań podczas usuwania)
  • CL 1663460 (poprawić potencjalny błąd wskaźnika względna, gdy markSlotSuccessful jest opóźniony)

Zapobieganie przedwczesnemu scalaniu update_engine

Gdy urządzenie się uruchamia (Android 11 lub nowszy) i zakończy uruchamianie, update_engine wywołuje ScheduleWaitMarkBootSuccessful(), a następnie WaitForMergeOrSchedule(). Spowoduje to rozpoczęcie procesu łączenia. Urządzenie uruchamia się jednak w starym gnieździe. Ponieważ proces scalania już się rozpoczął, urządzenie nie może się uruchomić i staje się nieużyteczne.

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

  • CL 1439792 (warunek wstępny dla CL 1439372)
  • CL 1439372(CleanupPreviousUpdateAction: anulowanie oczekujących zadań podczas usuwania)
  • CL 1663460 (poprawić potencjalny błąd wskaźnika względna, gdy markSlotSuccessful jest opóźniony)
  • CL 1664859 (opcjonalnie – dodaj unittest za CleanupPreviousUpdateAction)

Upewnij się, że konfiguracja dm-verity jest prawidłowa

W Androidzie 11 i nowszych urządzenia mogą zostać przypadkowo skonfigurowane z tymi opcjami 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 weryfikacji powoduje uszkodzenie partycji vbmeta i uniemożliwia działanie urządzeń innych niż A/B. Podobnie, jeśli rozpoczęło się scalanie, urządzenia A/B mogą przestać działać. Używaj tylko trybu AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Ustaw CONFIG_DM_VERITY_AVB=n w rdzeniu.
  2. Skonfiguruj urządzenia tak, aby używały trybu AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Więcej informacji znajdziesz w dokumentacji Verity: Praca z błędami dm-verity.

Sprawdź, czy scalony plik jest prawidłowo skonfigurowany

Jeśli tworzysz obrazy systemu i obrazy dostawcy osobno, a następnie używasz do ich scalania funkcji merge_target_files, konfiguracje A/B mogą zostać nieprawidłowo usunięte podczas procesu scalania. Aby sprawdzić, czy konfiguracje Virtual A/B są prawidłowe w scalonym pliku docelowym, zastosuj te poprawki: CL 2084183 (scalanie identycznych par klucz-wartość w informacjach o partycji dynamicznej)

Aktualizacja niezbędnych komponentów

W Androidzie 13 snapuserd zostało przeniesione z ramdysk dostawcy do ogólnego ramdysk. Jeśli Twoje urządzenie przechodzi na Androida 13, możliwe, że zarówno pamięć RAM dostawcy, jak i uniwersalna pamięć RAM zawierają kopię snapuserd. W tej sytuacji Virtual A/B wymaga kopii systemu snapuserd. Aby mieć pewność, że snapuserd jest prawidłową kopią, zastosuj CL 2031243 (kopia snapuserd do first_stage_ramdisk).