Najczęstsze pytania

Czy Google korzystał z OTA A/B na jakichkolwiek urządzeniach?

Tak. Nazwa marketingowa aktualizacji A/B to aktualizacje płynne . Telefony Pixel i Pixel XL z października 2016 r. były dostarczane w trybie A/B, a wszystkie Chromebooki korzystają z tej samej implementacji update_engine A/B. Niezbędna implementacja kodu platformy jest publiczna w systemie Android 7.1 i nowszych.

Dlaczego OTA A/B są lepsze?

Oferty A/B OTA zapewniają lepszą obsługę podczas pobierania aktualizacji. Pomiary przeprowadzane na podstawie comiesięcznych aktualizacji zabezpieczeń pokazują, że ta funkcja już okazała się skuteczna: od maja 2017 r. 95% właścicieli Pixeli instaluje najnowszą aktualizację zabezpieczeń po miesiącu w porównaniu z 87% użytkowników Nexusa, a użytkownicy Pixela aktualizują się wcześniej niż użytkownicy Nexusa. Niepowodzenie aktualizacji bloków podczas OTA nie powoduje już, że urządzenie nie uruchamia się; do czasu pomyślnego uruchomienia nowego obrazu systemu Android zachowuje możliwość powrotu do poprzedniego działającego obrazu systemu.

Jak A/B wpłynęło na rozmiary partycji Pixel 2016?

Poniższa tabela zawiera szczegółowe informacje na temat dostarczanej konfiguracji A/B w porównaniu z wewnętrznie testowaną konfiguracją inną niż A/B:

Aktualizacje A/B wymagają zwiększenia jedynie 320 MiB pamięci flash, co pozwala zaoszczędzić 32 MB w wyniku usunięcia partycji odzyskiwania i kolejnych 100 MB zachowanych w wyniku usunięcia partycji pamięci podręcznej. To równoważy koszt partycji B dla programu ładującego, partycji rozruchowej i partycji radiowej. Rozmiar partycji dostawcy podwoił się (zdecydowana większość wzrostu rozmiaru). Obraz systemu A/B Pixela jest o połowę mniejszy od oryginalnego obrazu systemu innego niż A/B.

W przypadku testowanych wewnętrznie wariantów Pixel A/B i innych niż A/B (dostarczono tylko A/B) wykorzystana przestrzeń różniła się tylko o 320 MB. Na urządzeniu 32GiB jest to nieco poniżej 1%. W przypadku urządzenia 16GiB będzie to mniej niż 2%, a w przypadku urządzenia 8GiB prawie 4% (zakładając, że wszystkie trzy urządzenia mają ten sam obraz systemu).

Dlaczego nie użyłeś SquashFS?

Eksperymentowaliśmy ze SquashFS, ale nie udało nam się osiągnąć wydajności wymaganej dla urządzenia z najwyższej półki. Nie używamy ani nie zalecamy SquashFS dla urządzeń przenośnych.

Mówiąc dokładniej, SquashFS zapewnił około 50% oszczędności rozmiaru partycji systemowej, ale przeważająca większość plików, które dobrze się skompresowały, to prekompilowane pliki .odex. Pliki te charakteryzowały się bardzo wysokimi współczynnikami kompresji (bliżącymi 80%), natomiast dla pozostałej części partycji systemowej stopień kompresji był znacznie niższy. Ponadto SquashFS w systemie Android 7.0 wzbudził następujące obawy dotyczące wydajności:

• Pixel ma bardzo szybką pamięć flash w porównaniu do wcześniejszych urządzeń, ale nie ma zbyt dużej liczby wolnych cykli procesora, więc odczytywanie mniejszej liczby bajtów z pamięci flash, ale wymaganie większej ilości procesora na potrzeby operacji we/wy, stanowiło potencjalne wąskie gardło.
• Zmiany we/wy, które dobrze sprawdzają się w sztucznym teście porównawczym na nieobciążonym systemie, czasami nie sprawdzają się dobrze w rzeczywistych przypadkach użycia pod rzeczywistym obciążeniem (takich jak kryptowaluty na Nexusie 6).
• Benchmarking wykazał w niektórych miejscach 85% regresji.

W miarę dojrzewania SquashFS i dodawania funkcji zmniejszających wpływ procesora (takich jak biała lista często używanych plików, które nie powinny być kompresowane), będziemy nadal go oceniać i oferować zalecenia producentom urządzeń.

Jak zmniejszyłeś o połowę rozmiar partycji systemowej bez SquashFS?

Aplikacje przechowywane są w plikach .apk, które w rzeczywistości są archiwami ZIP. Każdy plik .apk zawiera jeden lub więcej plików .dex zawierających przenośny kod bajtowy Dalvik. Plik .odex (zoptymalizowany .dex) istnieje oddzielnie od pliku .apk i może zawierać kod maszynowy specyficzny dla urządzenia. Jeśli dostępny jest plik .odex, system Android może uruchamiać aplikacje z wcześniej skompilowaną szybkością, bez konieczności czekania na kompilację kodu przy każdym uruchomieniu aplikacji. Plik .odex nie jest bezwzględnie konieczny: Android może w rzeczywistości uruchomić kod .dex bezpośrednio poprzez interpretację lub kompilację Just-In-Time (JIT), ale plik .odex zapewnia najlepszą kombinację szybkości uruchamiania i szybkości działania, jeśli jest dostępna przestrzeń.

Przykład: w przypadku pliku install-files.txt z Nexusa 6P z systemem Android 7.1 i całkowitego rozmiaru obrazu systemu wynoszącego 2628 MB (2755792836 bajtów) zestawienie największych czynników wpływających na ogólny rozmiar obrazu systemu według typu pliku jest następujące:

Liczby te są podobne również w przypadku innych urządzeń, więc na urządzeniach Nexus/Pixel pliki .odex zajmują około połowy partycji systemowej. Oznaczało to, że mogliśmy nadal używać ext4, ale zapisz pliki .odex na partycji B w fabryce, a następnie skopiuj je do /data przy pierwszym uruchomieniu. Rzeczywista pamięć używana z ext4 A/B jest identyczna z SquashFS A/B, ponieważ gdybyśmy używali SquashFS, wysłalibyśmy wstępnie wybrane pliki .odex na system_a zamiast system_b.

Czy kopiowanie plików .odex do /data nie oznacza, że ​​miejsce zapisane w /system zostanie utracone w /data?

Nie dokładnie. Na Pixelu większość miejsca zajmowanego przez pliki .odex jest przeznaczona na aplikacje, które zazwyczaj znajdują się w katalogu /data . Te aplikacje pobierają aktualizacje Google Play, więc pliki .apk i .odex w obrazie systemu są nieużywane przez większość czasu życia urządzenia. Takie pliki można całkowicie wykluczyć i zastąpić małymi plikami .odex opartymi na profilach, gdy użytkownik faktycznie korzysta z każdej aplikacji (w ten sposób nie wymaga miejsca na aplikacje, z których użytkownik nie korzysta). Szczegółowe informacje można znaleźć w przemówieniu Google I/O 2016 The Evolution of Art .

Porównanie jest trudne z kilku kluczowych powodów:

• Aplikacje aktualizowane przez Google Play zawsze miały swoje pliki .odex w /data zaraz po otrzymaniu pierwszej aktualizacji.
• Aplikacje, których użytkownik nie uruchamia, w ogóle nie potrzebują pliku .odex.
• Kompilacja oparta na profilach generuje mniejsze pliki .odex niż kompilacja z wyprzedzeniem (ponieważ ta pierwsza optymalizuje tylko kod krytyczny dla wydajności).

Aby uzyskać szczegółowe informacje na temat opcji dostrajania dostępnych dla producentów OEM, zobacz Konfigurowanie ART .

Czy w katalogu /data nie znajdują się dwie kopie plików .odex?

To trochę bardziej skomplikowane... Po zapisaniu nowego obrazu systemu, nowa wersja dex2oat jest uruchamiana z nowymi plikami .dex w celu wygenerowania nowych plików .odex. Dzieje się tak, gdy stary system nadal działa, więc stary i nowy plik .odex znajdują się jednocześnie w katalogu /data .

Kod w OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) wywołuje funkcję getAvailableSpace przed optymalizacją każdego pakietu, aby uniknąć przepełnienia /data . Należy zauważyć, że opcja dostępna w tym miejscu jest nadal konserwatywna: jest to ilość miejsca pozostałego przed osiągnięciem zwykłego systemowego progu małej ilości miejsca (mierzona zarówno jako wartość procentowa, jak i liczba bajtów). Więc jeśli /data jest pełny, nie będą dwie kopie każdego pliku .odex. Ten sam kod ma również BULK_DELETE_THRESHOLD: Jeśli urządzenie zbliży się do zapełnienia dostępnej przestrzeni (jak właśnie opisano), pliki .odex należące do nieużywanych aplikacji zostaną usunięte. To kolejny przypadek, w którym nie ma dwóch kopii każdego pliku .odex.

W najgorszym przypadku, gdy /data jest całkowicie zapełniony, aktualizacja czeka, aż urządzenie uruchomi się ponownie w nowym systemie i nie będzie już potrzebować plików .odex starego systemu. Menedżer pakietów obsługuje to: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Po pomyślnym uruchomieniu nowego systemu polecenie installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) może usunąć pliki .odex używane przez stary system, przywracając urządzenie do stanu stabilnego gdzie jest tylko jeden egzemplarz.

Tak więc, choć możliwe jest, że /data zawiera dwie kopie wszystkich plików .odex, (a) jest to tymczasowe i (b) występuje tylko wtedy, gdy i tak masz dużo wolnego miejsca w /data . Z wyjątkiem aktualizacji, jest tylko jedna kopia. Jako część ogólnych funkcji zapewniających niezawodność ART, i tak nigdy nie wypełni /data plikami .odex (ponieważ byłby to problem również w systemie innym niż A/B).

Czy całe to pisanie/kopiowanie nie zwiększa zużycia lampy błyskowej?

Przepisano tylko niewielką część flasha: pełna aktualizacja systemu Pixel zapisuje około 2,3GiB. (Aplikacje są również rekompilowane, ale dotyczy to również aplikacji innych niż A/B.) Tradycyjnie, pełne OTA oparte na blokach zapisywały podobną ilość danych, więc tempo zużycia pamięci flash powinno być podobne.

Czy flashowanie dwóch partycji systemowych wydłuża fabryczny czas flashowania?

Nie. Pixel nie zwiększył rozmiaru obrazu systemu (po prostu podzielił przestrzeń na dwie partycje).

Czy przechowywanie plików .odex na dysku B nie spowalnia ponownego uruchamiania po przywróceniu danych fabrycznych?

Tak. Jeśli rzeczywiście korzystałeś z urządzenia, skorzystałeś z OTA i zresetowałeś dane fabryczne, pierwsze ponowne uruchomienie będzie wolniejsze niż byłoby w innym przypadku (1 min 40 s w porównaniu z 40 s na Pixel XL), ponieważ pliki .odex zostaną utracone B po pierwszym OTA i dlatego nie można go skopiować do /data . To jest kompromis.

Przywracanie danych fabrycznych powinno być rzadką operacją w porównaniu do zwykłego rozruchu, więc czas potrzebny jest mniej ważny. (Nie dotyczy to użytkowników ani recenzentów, którzy otrzymują swoje urządzenie z fabryki, ponieważ w takim przypadku dostępna jest partycja B.) Korzystanie z kompilatora JIT oznacza, że ​​nie musimy wszystkiego rekompilować, więc nie jest tak źle, jak ty może pomyśleć. Można również oznaczyć aplikacje jako wymagające kompilacji z wyprzedzeniem, używając coreApp="true" w manifeście: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). Jest to obecnie używane przez system_server , ponieważ nie wolno mu wykonywać JIT ze względów bezpieczeństwa.

Czy przechowywanie plików .odex w /data zamiast w /system nie spowalnia ponownego uruchamiania po OTA?

Nie. Jak wyjaśniono powyżej, nowy dex2oat jest uruchamiany podczas działania starego obrazu systemu, aby wygenerować pliki potrzebne nowemu systemowi. Aktualizacja nie jest uważana za dostępną, dopóki te prace nie zostaną wykonane.

Czy możemy (powinniśmy) wysłać urządzenie A/B 32GiB? 16 GB? 8GiB?

32GiB działa dobrze, co zostało sprawdzone na Pixelu, a 320MiB z 16GiB oznacza redukcję o 2%. Podobnie 320MiB z 8GiB to redukcja o 4%. Oczywiście tryb A/B nie byłby zalecanym wyborem na urządzeniach z 4GiB, ponieważ obciążenie 320MiB stanowi prawie 10% całkowitej dostępnej przestrzeni.

Czy AVB2.0 wymaga OTA A/B?

Nie. Android Verified Boot zawsze wymagał aktualizacji opartych na blokach, ale niekoniecznie aktualizacji A/B.

Czy OTA A/B wymagają AVB2.0?

NIE.

Czy OTA A/B łamią ochronę przed wycofywaniem AVB2.0?

Nie. Jest tu pewne zamieszanie, ponieważ jeśli system A/B nie uruchomi się z nowym obrazem systemu, to (po określonej przez program ładujący liczbie prób) automatycznie powróci do „poprzedniego” obrazu systemu. Kluczową kwestią jest jednak to, że „poprzedni” w sensie A/B jest w rzeczywistości nadal „bieżącym” obrazem systemu. Gdy tylko urządzenie pomyślnie uruchomi nowy obraz, włącza się ochrona przed wycofaniem i uniemożliwia powrót. Ale dopóki nie pomyślnie uruchomisz nowy obraz, ochrona przed wycofaniem nie uzna go za bieżący obraz systemu.

Jeśli instalujesz aktualizację, gdy system jest uruchomiony, czy nie jest to powolne?

Celem aktualizacji innych niż A/B jest możliwie najszybsze zainstalowanie aktualizacji, ponieważ użytkownik czeka i nie może korzystać ze swojego urządzenia w czasie stosowania aktualizacji. W przypadku aktualizacji A/B jest odwrotnie; ponieważ użytkownik nadal korzysta ze swojego urządzenia, celem jest jak najmniejszy wpływ, więc aktualizacja jest celowo powolna. Za pomocą logiki klienta aktualizacji systemu Java (którym dla Google jest GmsCore, podstawowy pakiet dostarczany przez GMS), Android próbuje również wybrać czas, kiedy użytkownicy w ogóle nie korzystają ze swoich urządzeń. Platforma obsługuje wstrzymywanie/wznawianie aktualizacji, a klient może to wykorzystać do wstrzymania aktualizacji, jeśli użytkownik zacznie korzystać z urządzenia i wznowienia jej, gdy urządzenie będzie ponownie bezczynne.

Podczas korzystania z OTA występują dwie fazy, wyraźnie pokazane w interfejsie użytkownika jako krok 1 z 2 i krok 2 z 2 pod paskiem postępu. Krok 1 odpowiada zapisowi bloków danych, natomiast krok 2 polega na wstępnej kompilacji plików .dex. Te dwie fazy różnią się znacznie pod względem wpływu na wydajność. Pierwsza faza to proste wejścia/wyjścia. Wymaga to niewielkich zasobów (RAM, CPU, I/O), ponieważ po prostu powoli kopiuje bloki.

W drugiej fazie uruchamiany jest program dex2oat w celu prekompilacji nowego obrazu systemu. To oczywiście ma mniej jasne granice wymagań, ponieważ kompiluje rzeczywiste aplikacje. Oczywiście kompilacja dużej i złożonej aplikacji wymaga znacznie więcej pracy niż kompilacja małej i prostej aplikacji; podczas gdy w fazie 1 nie ma bloków dyskowych większych lub bardziej złożonych niż inne.

Proces jest podobny do sytuacji, gdy Google Play instaluje aktualizację aplikacji w tle przed wyświetleniem powiadomienia o aktualizacji 5 aplikacji , co ma miejsce od lat.

A co jeśli użytkownik faktycznie czeka na aktualizację?

Obecna implementacja w GmsCore nie rozróżnia aktualizacji w tle od aktualizacji inicjowanych przez użytkownika, ale może to zrobić w przyszłości. W przypadku, gdy użytkownik wyraźnie poprosił o zainstalowanie aktualizacji lub obserwuje ekran postępu aktualizacji, nadamy priorytet pracom nad aktualizacją, zakładając, że aktywnie czekają na jej zakończenie.

Co się stanie, jeśli nie uda się zastosować aktualizacji?

W przypadku aktualizacji innych niż A/B, jeśli aktualizacja nie została zastosowana, użytkownik zwykle pozostawał z urządzeniem, które nie nadawało się do użytku. Jedynym wyjątkiem była sytuacja, gdy awaria wystąpiła przed uruchomieniem aplikacji (na przykład z powodu niepowodzenia weryfikacji pakietu). W przypadku aktualizacji A/B niezastosowanie aktualizacji nie ma wpływu na aktualnie działający system. Aktualizację można po prostu ponowić później.

Które systemy na chipie (SoC) obsługują A/B?

Na dzień 2017-03-15 mamy następujące informacje:

Aby uzyskać szczegółowe informacje na temat harmonogramów, skontaktuj się z kontaktami SoC. W przypadku układów SoC niewymienionych powyżej skontaktuj się bezpośrednio ze swoim SoC.