Wdrożenie testu A/B – łaty.

Wybierz te poprawki, aby rozwiązać znane problemy.

Prawidłowe sprawdzanie miejsca, które można przydzielić podczas wczytywania z boku

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

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 skompiluj i wgraj partycję rozruchową lub partycję przywracania, jeśli urządzenie nie używa przywracania jako rozruchu.

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. Potencjalny błąd nieprawidłowego wskaźnika występuje również wtedy, gdy markSlotSuccessful pojawia się późno.

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

Aby naprawić błędy SIGSEGVw update_engine podczas scalania, wprowadź w drzewie źródłowym Androida 11 te zmiany:

  • CL 1439792 (wymagany do CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (poprawienie potencjalnego błędu wskaźnika nieokreślonego, gdy markSlotSuccessful pojawia się z opóźnieniem)

Zapobieganie przedwczesnemu scalaniu update_engine

Gdy urządzenie uruchamia się (Android 11 lub nowszy) i proces uruchamiania dobiega końca, wywoływane są funkcje update_engine, ScheduleWaitMarkBootSuccessful() i WaitForMergeOrSchedule(). Rozpocznie to proces scalania. Urządzenie jednak ponownie uruchomi się w starym slocie. Ponieważ proces scalania już się rozpoczął, urządzenie nie może się uruchomić i staje się bezużyteczne.

Wprowadź w drzewie źródłowym te zmiany. Pamiętaj, że CL 1664859 jest opcjonalny.

  • CL 1439792 (wymagany do CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (poprawienie potencjalnego błędu wskaźnika nieokreślonego, gdy markSlotSuccessful pojawia się z opóźnieniem)
  • CL 1664859 (opcjonalnie – dodaj unittest za CleanupPreviousUpdateAction)

Sprawdź, czy konfiguracja dm-verity jest prawidłowa.

Na urządzeniach z Androidem 11 lub nowszym można przypadkowo skonfigurować te opcje dm-verity:

  • CONFIG_DM_VERITY_AVB=y w jądrze
  • Program rozruchowy skonfigurowany do używania dowolnego trybu weryfikacji (np. AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) bez AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

W tej konfiguracji urządzenia każdy błąd weryfikacji powoduje uszkodzenie partycji vbmeta i uniemożliwia korzystanie z urządzeń innych niż A/B. Podobnie jeśli rozpoczęto scalanie, urządzenia A/B mogą przestać działać. Używaj tylko trybu weryfikacji AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Ustaw wartość CONFIG_DM_VERITY_AVB=n w jądrze.
  2. Skonfiguruj urządzenia tak, aby korzystały z trybu AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Więcej informacji znajdziesz w dokumentacji dotyczącej weryfikacji: Obsługa błędów dm-verity.

Sprawdź, czy scalony plik jest prawidłowo skonfigurowany.

Jeśli obrazy systemu i obrazy dostawcy są tworzone oddzielnie, a następnie łączone za pomocą polecenia merge_target_files, konfiguracje wirtualnego A/B mogą zostać nieprawidłowo usunięte podczas procesu łączenia. Aby sprawdzić, czy konfiguracje wirtualnego testu A/B w scalonym pliku docelowym są prawidłowe, zastosuj te poprawki: CL 2084183 (scal identyczne pary klucz/wartość w informacjach o partycji dynamicznej)

Aktualizowanie niezbędnych komponentów

W Androidzie 13 snapuserd został przeniesiony z vendor ramdisk do generic ramdisk. Jeśli urządzenie jest aktualizowane do Androida 13, może się zdarzyć, że zarówno dysk RAM dostawcy, jak i dysk RAM ogólny zawierają kopię snapuserd. W takiej sytuacji wirtualne testy A/B wymagają kopii systemowej snapuserd. Aby mieć pewność, że jest używana prawidłowa kopia snapuserd, zastosuj CL 2031243 (skopiuj snapuserd do first_stage_ramdisk).