Dynamiczne aktualizacje systemu w Androidzie Pytanie: Jak Project Treble ulepszy przyszłe wersje Androida

Wraz z wydaniem Androida 8.0 Oreo, Google zaprezentowało Projekt Treble: zasadnicza zmiana architektury w sposobie komunikacji platformy systemu operacyjnego Android z warstwami HAL dostawcy i jądrem Linuksa. Treble to główna inicjatywa mająca na celu zmniejszenie wersji platformy Android i fragmentacja poprawek bezpieczeństwa, a wszystkie urządzenia z marką Android, na których uruchamiany jest system Android Pie, muszą obsługiwać Project Treble. Producenci OEM i dostawcy testują kompatybilność Treble, uruchamiając Generic System Image (GSI) – czystą wersję Androida z AOSP – i przekazując Zestaw testów dostawcy (VTS) i obraz systemu z zestawu testów zgodności na ogólnym obrazie systemu (CTS-on-GSI). GSI okazał się przydatny nie tylko umożliwiając inżynierom oprogramowania pracującym dla producentów OEM testowanie kompatybilności tonów wysokich, ale także otworzył drzwi do

duża społeczność niestandardowych ROMów na XDA. W przypadku wersji Androida Q Google chce, aby GSI były przydatne dla innej grupy: twórców aplikacji.

Zwykle pojawia się od czasu wydania pierwszej stabilnej wersji i usunięcia kodu źródłowego dowolnej wersji platformy Android w sierpniu, programiści, którzy chcą przetestować kolejną wersję Androida na prawdziwym urządzeniu, zazwyczaj potrzebują dostępu do smartfona Google, jeśli nie chcą czekać, aż aktualizacja dotrze na ich własny sprzęt. Jednak Google współpracował z producentami OEM, aby wprowadzić Beta Androida P do kilku urządzeń w zeszłym roku, a w tym roku kontynuowali tę kwestię Beta Androida Q. Oprócz oficjalnej wersji beta systemu Android Q, firma Google udostępniła w tym roku także wersję beta oficjalna wersja Q beta GSI dzięki czemu każdy programista posiadający urządzenie kompatybilne z Project Treble może zainstalować najnowszą wersję Q bez konieczności czekania miesiącami, aż kompilacja dotrze do ich urządzeń. Ten nowy sposób testowania kolejnej wersji Androida daje programistom więcej możliwości, a tym samym więcej czasu na testowanie swoich aplikacji duże zmiany w Androidzie.

Niestety, obecna metoda instalowanie GSI może być trudne. Wymaga odblokowania bootloadera – co oznacza wyczyszczenie wszystkich danych użytkownika i/lub unieważnienie gwarancji – i flashowanie obrazu poprzez protokół fastboot. Nie jest to szybki i prosty proces, który twórca aplikacji może wykonać na swoim urządzeniu pozwala nawet na odblokowanie bootloadera. Dlatego dla ostatnich kilku miesięcy, Google pracowało nad nowym sposobem uruchamiania GSI. Wprowadź nową funkcję o nazwie Dynamic System Update (DSU).

(Ta funkcja była wcześniej rozwijana pod nazwami „Live Image”, „Dynamic Android” i „Android on Tap”, więc nie zdziw się, jeśli za kilka tygodni lub miesięcy Google nazwie ją inaczej).

Dynamiczne aktualizacje systemu w Androidzie Q

Celem funkcji DSU jest umożliwienie programiście uruchomienia GSI bez zakłócania bieżącej instalacji. Oznacza to, że nie trzeba odblokowywać programu ładującego i nie trzeba czyścić danych użytkownika. Proces instalacji jest również znacznie uproszczony, ponieważ Google udostępniło interfejs wiersza poleceń za pośrednictwem ADB i aplikację, którą można kontrolować za pomocą intencji. Oto jak wygląda uruchomienie GSI przy użyciu DSU:

W tym filmie* Google Pixel 3 XL z systemem Android Q beta 3 uruchamia się ponownie i uruchamia GSI. W tym środowisku twórca aplikacji może zainstalować i przetestować swoją aplikację pod kątem zgodności Q API. Po zakończeniu testów mogą po prostu ponownie uruchomić urządzenie i uruchomić normalne oprogramowanie Q beta 3. Zasadniczo uruchamiasz GSI podwójnie, więc możesz bezpiecznie przetestować swoją aplikację!

*Nagraliśmy ten film podczas Google I/O 2019, kiedy DSU nie był jeszcze publicznie dostępny, więc wersja Q beta 3 na nakręconym Pixelu 3 XL została nieco zmodyfikowana przez Google, aby uwzględnić obsługę DSU. Urządzenia z systemem Q beta 4 lub nowszym kwalifikują się do obsługi DSU, jeśli spełniają poniższe wymagania.

Wymagania dotyczące dynamicznych aktualizacji systemu

Uruchomienie i uruchomienie czegoś, co zasadniczo polega na podwójnym uruchomieniu, nie było łatwym zadaniem dla Google. Konieczne było wprowadzenie poważnych zmian w sposobie zarządzania partycjami na Pixelu 3, stanowisku testowym Google dla DSU. Zatem pierwszym głównym wymaganiem dotyczącym obsługi DSU jest to, czy urządzenie obsługuje partycje dynamiczne. Partycje dynamiczne obejmują jedną rzeczywistą partycję pamięci, która jest podzielona na partycje logiczne o zmiennym rozmiarze, takie jak system, dostawca, ODM, OEM, produkt itp. Podczas instalacji GSI miejsce jest rezerwowane dla nowych partycji systemowych i danych użytkownika poprzez pobranie niewykorzystanych bloków z istniejącej partycji danych użytkownika. Ponieważ te nowe partycje mogą mieć rozmiar kilku gigabajtów, obsługa DSU ma sens tylko w przypadku logicznych partycje, w przeciwnym razie urządzenie musiałoby na stałe zarezerwować kilka gigabajtów przestrzeni dyskowej dla GSI instalacje.

Inne wymagania obejmują dysk ramdysk, który decyduje o tym, czy uruchomić system z odzyskiwania, partycję logiczną czy partycję logiczną, oraz partycję metadanych do przechowywania metadanych GSI. Ogólnie rzecz biorąc, podstawą obsługi DSU są wymagania dotyczące uruchamiania Androida Q, według lidera Project Treble, Iliyana Malcheva. Nie jesteśmy pewni, czy wszystko to, co jest potrzebne do obsługi DSU, jest wymogiem uruchomienia Androida Q, ale możemy założyć, że większość, jeśli nie wszystkie urządzenia uruchamiają się z Androidem Q Móc wspierać DSU, nawet jeśli Google obecnie tego nie wymaga. Jak dotąd tylko Pixel 3, Pixel 3 XL, Pixel 3a i Pixel 3a XL mają partycje dynamiczne i z tych urządzeń tylko Pixel 3 i Pixel 3 XL obsługują DSU w Androidzie Q beta 4. Chociaż obsługa DSU nie jest wymagana, Google ma nadzieję, że producenci OEM i tak włączą tę funkcję, ponieważ upraszcza to bezpieczne testowanie kompatybilności Treble. Na przykład inżynier oprogramowania OEM może umieścić GSI na karcie SD dzięki czemu mogą szybko uruchamiać się na wielu urządzeniach i testować kompatybilność Treble.

Bezpieczeństwo dynamicznych aktualizacji systemu

Ponieważ DSU wprowadza do zestawu zasadniczo drugi system operacyjny, Google musi się upewnić, że przy tej nowej instalacji nie będzie można manipulować, aby naruszyć integralność urządzenia. Więc te same podstawowe zabezpieczenia co w przypadku oryginalnej instalacji obowiązują w przypadku instalacji GSI: Zasady dotyczące zweryfikowanego rozruchu systemu Android i SELinux. Co więcej, tylko aplikacje z podpisem INSTALL_DYNAMIC_SYSTEM|uprzywilejowanym uprawnieniem mogą inicjować GSI instalacji, podczas gdy aplikacje z uprawnieniami do podpisu MANAGE_DYNAMIC_SYSTEM mogą włączać/wyłączać lub czyścić GSI instalacja. Oznacza to, że tylko zaufane aplikacje na poziomie systemu mogą współpracować z DSU.

Aby zapewnić ochronę oryginalnych danych użytkownika, Google dodał dodatkowy mechanizm ochronny w Androidzie Q. Zwany "Punkt kontrolny”, funkcja chroni przed zniszczeniem danych użytkownika poprzez przywrócenie partycji kontrolnych do ich pierwotnego stanu. Punkty kontrolne są jednak przydatne nie tylko dla DSU. Są również używane do ochrony przed nieudanymi działaniami Główna linia projektu Moduł APEX i A/B Aktualizacje OTA. (Urządzenia z partycjami A/B mają już ochronę przed wycofywaniem zmian, ale te wycofywania wymagają resetowania danych fabrycznych, podczas gdy punkty kontrolne danych użytkownika nie.)

Instalacja GSI

Jeśli Twoje urządzenie obsługuje DSU, np. serię Pixel 3, zainstalowanie GSI jest łatwe. Najpierw musisz upewnić się, że flaga funkcji System dynamiczny jest włączona na jeden z dwóch sposobów:

1. Jeśli korzystasz z kompilacji debugowania użytkownika, włącz flagę settings_dynamic_android w Ustawieniach > System > Opcje programisty > Flagi funkcji.
2. Jeśli korzystasz z kompilacji użytkownika, uruchom następującą komendę powłoki adb:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Następnie pobierz najnowszą wersję Androida Q beta GSI z Google lub OEM Twojego urządzenia. (DSU pozwala tylko na instalowanie GSI podpisanych przez Google lub OEM.) Po pobraniu użyj simg2img aby przekonwertować rzadki obraz na surowy obraz. Użyj gzip, aby spakować surowy obraz, a następnie skopiuj powstałe archiwum do lokalizacji na swoim urządzeniu pamięć zewnętrzna (np. /data/media/0/Download) lub rzeczywisty zewnętrzny nośnik pamięci (taki jak fizyczna karta SD karta). Na koniec uruchom aplikację DynamicSystemInstallationService z właściwym zamiarem rozpoczęcia instalacji:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Po kliknięciu przycisku Uruchom ponownie nastąpi uruchomienie GSI. Użyteczność urządzenia w GSI zależy od tego, jak dobrze producent OEM Twojego urządzenia zaimplementował wysokie tony (lub raczej, w jakim stopniu naruszył tony wysokie kompatybilność.) Niektóre urządzenia będą działać lepiej z GSI niż inne, ale ogólnie rzecz biorąc, nie spodziewaj się, że będziesz używać tej instalacji na co dzień kierowca. Masz przetestować aplikację, a następnie zakończyć ją, uruchamiając ponownie. Jeśli chcesz pozostać w instalacji GSI do dalszych testów, możesz skorzystać z gsi_tool polecenie powłoki.

Pełną instrukcję instalacji GSI dla DSU można znaleźć Tutaj. Błędy można zgłaszać na stronie narzędzie do śledzenia problemów Google,Reddit, Lub Przepełnienie stosu.

Powód dynamicznych aktualizacji systemu

Kiedy rozmawiałem z Iliyanem Malchevem podczas Google I/O, powtórzył to, co Hung-ying Tyan z zespołu Treble powiedział o wczesnym dostępie do GSI o godz. Listopadowy szczyt deweloperów Androida. Google stworzyło DSU uzyskać informacje zwrotne od jak najszerszego grona odbiorców. Celem jest poprawa jakości GSI, co z kolei poprawia jakość przyszłej wersji Androida ponieważ GSI jest najczystszą formą Androida. Google jest obecnie jedyną firmą, która testuje zgodność kolejnej wersji GSI (na przykład, jak dobrze obraz systemu Android Q działa na Androidzie P implementacja dostawcy), ale w miarę jak coraz więcej osób będzie flashować GSI i przekazywać opinie, producenci OEM będą mogli naprawić naruszenia kompatybilności Treble, dzięki czemu GSI będą działać jeszcze lepiej w przyszły. Iliyan twierdzi, że producenci OEM i dostawcy tacy jak Qualcomm wykazują duże zainteresowanie ponownym wykorzystaniem obrazów dostawców z poprzedniej wersji Androida w obrazie systemu następnej wersji. Inicjatywy takie jak DSU pomagają Google i producentom OEM wypełnić lukę w zasięgu automatycznych testów, takich jak VTS i CTS-on-GSI. W ten sposób Google pozyskuje więcej beta testerów, którzy przekazują opinie na temat kolejnej wersji Androida, a jednocześnie dowiadują się o naruszeniach kompatybilności Treble, dzięki czemu producenci OEM mogą ulepszyć swoją pracę.

Dodanie dynamicznych aktualizacji systemu do Androida Q jest mile widziane, ale nie będzie to rozwiązanie z podwójnym uruchamianiem, na które niektórzy z Was liczą. Jak wspomniano wcześniej, można instalować tylko obrazy systemu podpisane przez Google lub producentów OEM. Kiedy zapytałem Iliyana o możliwość rozszerzenia DSU o obsługę ekosystemu alternatywnego Androida stwierdził, że jest to technicznie możliwe, ponieważ DSU to po prostu kanał dostarczania systemu obrazy. Każdy OEM może z niego korzystać, jak chce pod warunkiem, że wynik końcowy będzie zgodny z systemem Android. Google nie stworzył tutaj alternatywy dla systemu OTA, a DSU nie jest przeznaczone do stosowania w przypadku prawdziwego podwójnego rozruchu. Niezależnie od tego, praca, którą Google wykonał nad Treble, sprawiła, że ​​Android stał się bardziej modułowy, więc nie zdziwiłbym się, gdyby natywne podwójne uruchamianie stało się w przyszłości rzeczywistością.