Wdróż wirtualne środowisko A/B – poprawki

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

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 funkcji update_engine_client --cancel powoduje awarię funkcji 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 zniszczenia oczekujące zadanie jest anulowane, aby uniknąć błędu segfault.

Aby naprawić SIGSEGVawarie w update_engine podczas scalania, upewnij się, że 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(). Rozpocznie się proces łą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.

Dodaj następujące zmiany do drzewa źródłowego. Uwaga: CL 1664859 jest opcjonalny.

  • CL 1439792 (warunek wstępny dla CL 1439372)
  • CL 1439372(CleanupPreviousUpdateAction: anulowanie oczekujących zadań podczas usuwania)
  • CL 1663460 (poprawianie potencjalnego błędu wskaźnika symbolu zastępczego, gdy markSlotSuccessful się spóźnia)
  • CL 1664859 (opcjonalnie – dodaj unittest dla 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 rdzeniu
  • 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, aby korzystały z 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 obrazy systemowe i obrazy dostawców tworzysz osobno, a potem scalasz je za pomocą merge_target_files, konfiguracje wirtualnych A/B mogą zostać nieprawidłowo pominięte podczas 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 jest aktualizowane do 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 jest prawidłowa kopia pliku snapuserd, zastosuj CL 2031243 (kopia snapuserd do first_stage_ramdisk).