Ta strona została przetłumaczona przez Cloud Translation API.

Wdrażaj wirtualne poprawki A/B

Wybierz następujące poprawki, aby rozwiązać następujące znane problemy.

Sprawdź prawidłowo przydzielaną przestrzeń podczas ładowania bocznego

Ładowanie boczne pełnego pakietu OTA na wirtualne urządzenie A/B, które ma super partycję o rozmiarze mniejszym niż *2 * suma(rozmiar grup aktualizacji)* może zakończyć się niepowodzeniem z następującymi komunikatami w dzienniku odzyskiwania /tmp/recovery.log :

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

Oto przykład logu:

[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 , odbuduj i sflashuj partycję rozruchową lub partycję odzyskiwania, jeśli urządzenie nie korzysta z odzyskiwania podczas rozruchu.

Napraw błąd segmentacji podczas scalania

Po zastosowaniu aktualizacji OTA, podczas procesu scalania VAB, wywołanie update_engine_client --cancel powoduje awarię CleanupPreviousUpdateAction . Potencjalny błąd dzikiego wskaźnika występuje również, gdy markSlotSuccessful pojawia się późno.

Problem został rozwiązany poprzez dodanie funkcji StopActionInternal . CleanupPreviousUpdateAction anuluje oczekujące zadania po zniszczeniu. Utrzymuje zmienną, która śledzi identyfikator zadania oczekującego w pętli komunikatów. Po zniszczeniu oczekujące zadanie zostaje anulowane, aby uniknąć błędu segfault.

Upewnij się, że w drzewie źródeł Androida 11 znajdują się następujące zmiany, aby naprawić awarie SIGSEGV w update_engine podczas scalania:

CL 1439792 (warunek wstępny dla CL 1439372)
CL 1439372 ( CleanupPreviousUpdateAction : anuluj oczekujące zadania po zniszczeniu)
CL 1663460 (napraw potencjalny błąd dzikiego wskaźnika, gdy markSlotSuccessful pojawia się późno)

Napraw nieprawidłowe przełączanie slotów VAB, po aktualizacji OTA

W systemie Android 11 i nowszych wersjach brak synchronizacji przełącznika gniazda w urządzeniu po aktualizacji OTA może spowodować, że urządzenie stanie się niezdatne do użytku. Jeśli implementacja przełączania szczelin IBootControl HAL wykonuje zapisy, należy natychmiast opróżnić te zapisy. Jeśli zapisy nie zostaną opróżnione, a urządzenie zostanie ponownie uruchomione po rozpoczęciu łączenia, ale zanim sprzęt będzie w stanie opróżnić zapis za pomocą przełącznika gniazda, urządzenie może powrócić do poprzedniego gniazda i nie uruchomić się.

Aby zapoznać się z przykładowym rozwiązaniem kodu, zobacz ten CL: CL 1535570 .

Zapobiegaj przedwczesnemu scalaniu update_engine

Po uruchomieniu urządzenia (Android 11 i nowszy) i zakończeniu rozruchu update_engine wywołuje funkcje ScheduleWaitMarkBootSuccessful() i WaitForMergeOrSchedule() . To rozpoczyna proces scalania. Jednak urządzenie uruchamia się ponownie w starym gnieździe. Ponieważ scalanie już się rozpoczęło, urządzenie nie uruchamia się i przestaje działać.

Dodaj następujące zmiany do drzewa źródłowego. Należy pamiętać, że CL 1664859 jest opcjonalny.

CL 1439792 (warunek wstępny dla CL 1439372)
CL 1439372 ( CleanupPreviousUpdateAction : anuluj oczekujące zadania po zniszczeniu)
CL 1663460 (napraw potencjalny błąd dzikiego wskaźnika, gdy markSlotSuccessful pojawia się późno)
CL 1664859 (opcjonalnie — dodaj unittest dla CleanupPreviousUpdateAction )

Zapobiegaj utracie lub uszkodzeniu danych w wyniku pominięcia metadanych

W systemie Android 11 i nowszych wersjach, jeśli urządzenie pamięci masowej ma ulotną pamięć podręczną z zapisem zwrotnym, w pewnych warunkach metadane zakończonego scalania są pomijane, co powoduje utratę lub uszkodzenie danych.

Warunki:

Po zakończeniu operacji scalania jednego zestawu wyjątków wywołano funkcję merge_callback() .
Metadane zostały zaktualizowane w urządzeniu COW, które śledzi zakończenie scalania. (Ta aktualizacja urządzenia COW jest czysto przepłukiwana.)

Wynik: system uległ awarii, ponieważ pamięć podręczna urządzenia pamięci masowej z ostatniego scalania nie została opróżniona.

Aby wdrożyć uchwałę, zapoznaj się z poniższymi informacjami:

Opróżnij scalone dane przed zatwierdzeniem metadanych

Upewnij się, że konfiguracja dm-verity jest poprawna

W systemie Android 11 i nowszych urządzeniach można przypadkowo skonfigurować następujące opcje dm-verity:

CONFIG_DM_VERITY_AVB=y w jądrze
Program ładujący skonfigurowany do używania dowolnego trybu wiarygodności (takiego jak 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 prawdziwości powoduje uszkodzenie partycji vbmeta i sprawia, że urządzenia inne niż A/B przestają działać. Podobnie, jeśli rozpoczęło się łączenie, urządzenia A/B również mogą przestać działać. Używaj tylko trybu wiarygodności AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Ustaw CONFIG_DM_VERITY_AVB=n w jądrze
Skonfiguruj urządzenia tak, aby zamiast tego korzystały z trybu AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

Aby uzyskać więcej informacji i ze względów praktycznych, zapoznaj się z dokumentacją dotyczącą prawdy: Obsługa błędów dm-verity .

Pomiń prace sprawdzające w odpowiedzi na błąd we/wy podczas awaryjnego zamykania systemu

W systemie Android 11 i nowszych wersjach, jeśli zostanie wywołane awaryjne zamknięcie systemu (jak w przypadku wyłączenia termicznego), urządzenie dm może działać, podczas gdy urządzenie blokowe nie może już przetwarzać żądań we/wy. W tym stanie błędy we/wy obsługiwane przez nowe żądania we/wy dm lub te już realizowane mogą prowadzić do stanu uszkodzenia rzeczywistości, co jest błędną oceną.

Aby pominąć pracę sprawdzającą w odpowiedzi na błąd we/wy podczas zamykania systemu, użyj następujących poleceń:

CL 1847875 (Pomija pracę sprawdzającą w odpowiedzi na błąd we/wy podczas wyłączania)

Upewnij się, że DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED jest wyłączony

Urządzenia z Androidem Go z jądrem 4.19 lub starszym mogą mieć w konfiguracji jądra DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y . To ustawienie nie jest kompatybilne z wirtualnym A/B i wiadomo, że powoduje rzadkie problemy z uszkodzeniem strony, gdy oba są włączone razem.

W przypadku jąder 4.19 i wcześniejszych wyłącz je, ustawiając CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n w konfiguracji jądra.

W przypadku jąder 5.4 i nowszych kod został usunięty, a opcja konfiguracji nie jest dostępna.

Upewnij się, że scalony plik jest poprawnie skonfigurowany

Jeśli tworzysz oddzielnie obrazy systemów i obrazów dostawców, a następnie używasz merge_target_files do ich połączenia, wirtualne konfiguracje A/B mogą zostać niepoprawnie usunięte podczas procesu scalania. Aby sprawdzić, czy wirtualne konfiguracje A/B są poprawne w scalonym pliku docelowym, zastosuj następujące poprawki: CL 2084183 (scal identyczne pary klucz/wartość w informacjach o partycji dynamicznej)

Zaktualizuj niezbędne komponenty

Począwszy od Androida 13, snapuserd został przeniesiony z RAMdysku dostawcy na ogólny RAMdysk. Jeśli Twoje urządzenie aktualizuje się do systemu Android 13, możliwe, że zarówno ramdysk dostawcy, jak i ogólny ramdysk zawierają kopię pliku snapuserd . W tej sytuacji Virtual A/B wymaga kopii systemowej snapuserd . Aby mieć pewność, że zainstalowana jest poprawna kopia snapuserd , zastosuj CL 2031243 (skopiuj snapuserd do First_stage_ramdisk).