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

Wczytywanie pełnego pakietu OTA na urządzeniu z wirtualnym systemem 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ż, 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 oczekującego zadania w pętli wiadomości. Podczas niszczenia oczekujące zadanie jest anulowane, aby uniknąć błędu segmentacji.

Aby naprawić błędy SIGSEGV w update_engine podczas scalania, upewnij się, że w drzewie źródłowym Androida 11 są wprowadzone te zmiany:

  • CL 1439792 (wymagany do CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (naprawienie 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łuje funkcje ScheduleWaitMarkBootSuccessful() i WaitForMergeOrSchedule().update_engine Spowoduje to rozpoczęcie procesu scalania. Urządzenie jednak ponownie uruchomi się w starym slocie. Ponieważ scalanie zostało już rozpoczęte, 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 (naprawienie 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 są prawidłowe w scalonym pliku docelowym, zastosuj te poprawki: CL 2084183 (merge identical key/val pairs in dynamic partition info)

Aktualizowanie niezbędnych komponentów

W Androidzie 13 snapuserd został przeniesiony z ramdysku dostawcy na ramdysk ogólny. 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 prawidłowa kopia snapuserd jest na miejscu, zastosuj CL 2031243 (skopiuj snapuserd do first_stage_ramdisk).