Android 11 będzie dostarczany z modułem ładującym DSU w opcjach programisty, który umożliwia automatyczne pobieranie i instalowanie zgodnych GSI! Czytaj dalej, aby dowiedzieć się więcej!
Dobry ekosystem aplikacji jest jednym z najważniejszych filarów sukcesu systemu operacyjnego. Zarówno Google, jak i Apple uznają wartość dobrych aplikacji na swoich platformach, dlatego obie firmy starają się zrównoważyć potrzeby swoich użytkowników i twórców aplikacji. Użytkownicy naciskają na zmiany w systemach operacyjnych i chociaż większość ludzi generalnie docenia nowe funkcje, te zmiany nie zawsze są zabawne dla twórców aplikacji, ponieważ mogą zmienić wiele podstawowych funkcji i zachowanie. Dla programistów, którzy nieustannie pracują nad tym, aby ich aplikacje były aktualne, radzenie sobie z tymi zmianami dodaje się do ich rosnącej listy zadań. Nawet jeśli te zmiany nie wpłyną bezpośrednio na ich aplikacje, programiści nadal muszą upewnić się, że ich aplikacje będą działać w nowej aktualizacji systemu operacyjnego. Google wprowadziło wiele zmian na przestrzeni lat, aby ułatwić ten proces twórcom aplikacji na Androida, a teraz jest to nowość funkcja w Androidzie 11, zwana DSU Loader, jeszcze bardziej ułatwi twórcom aplikacji testowanie ich aplikacji na nowym Androidzie wersje.
Zaczyna się od Project Treble
Project Treble, wprowadzony w Androidzie 8.0, jest głównym przeprojektowanie systemu operacyjnego Android. Celem Project Treble było podzielenie systemu operacyjnego Android na dwie duże części: framework i implementację dostawcy („sprzedawca” odnosi się tutaj do producenta dowolnego zastrzeżonego komponentu sprzętowego znajdującego się w urządzeniu, zwykle odnosi się do krzem). Struktura systemu operacyjnego Android to sam system operacyjny, w tym wszystkie aplikacje systemowe, interfejs użytkownika i jego komponenty oraz interfejsy API współdzielone przez urządzenia z systemem Android. Implementacja dostawcy zawiera dostawcy HAL (Hardware Abstraction Layers) oraz jądro systemu Linux i moduły jądra systemu Linux.
Ponieważ producenci OEM dostarczają smartfony z wieloma różnymi komponentami sprzętowymi od wielu różnych dostawców, muszą wykonać dużo pracy, aby sprzęt działał i działał w jednej wersji systemu operacyjnego Android. Następnie z każdą nową aktualizacją systemu operacyjnego Android muszą wykonać jeszcze więcej pracy, aby upewnić się, że ich sprzęt działa z nową wersją. Ale dzięki Project Treble standaryzującym ABI (Application Binary Interface) między platformą systemu operacyjnego Android a warstwami HAL dla określonej wersji Androida, Producenci OEM Androida mogą rozpocząć testowanie aktualizacji swoich urządzeń bez konieczności czekania, aż producenci krzemu i inni producenci komponentów zaktualizują ich stronę kod. Ta zmiana wyraźnie przyspieszyła sposób obsługi aktualizacji Androida.
To sedno tego, co Project Treble zrobił dla aktualizacji Androida, ale co ważniejsze dla aplikacji programistów tutaj jest to, że Treble umożliwił korzystanie z Generic System Images (GSI) w celu zapewnienia kompatybilności testowanie.
Pojawienie się GSI
Aby producenci OEM mogli przetestować, czy prawidłowo wdrożyli Project Treble, Google wymaga, aby OEM był w stanie uruchomić czystą wersję Androida z AOSP na urządzeniu. Ta czysta wersja Androida nosi nazwę Generic System Image lub GSI. Jeśli GSI uruchamia się i większość podstawowych urządzeń działa prawidłowo, producent OEM wie, że jego urządzenie spełnia wymagania Project Treble. Początkowym celem GSI było zatem przetestowanie kompatybilności tonów wysokich, ale jak widzieliśmy w społeczności programistów tutaj w XDA-Developers, można ich używać do innych celów. Widzieliśmy, jak GSI może zasadniczo pozwolić urządzeniom z ciężkimi UX na Androida cieszyć się najnowszą wersją Androida z działającymi funkcjami w ciągu kilku dni od nowej wersji. Ale Google przewiduje inny cel stojący za GSI: umożliwienie twórcom aplikacji testowania ich aplikacji na nowej wersji Androida na fizycznym urządzeniu, które już posiadają.
W systemie Android 10 firma Google udostępniła programistom własne kompilacje GSI. Google ugruntował pomysł, że twórcy aplikacji powinni używać GSI do uruchamiania czystej wersji Androida na własnym sprzęcie, ułatwiając testowanie zachowania ich aplikacji w stosunku do standardowego Androida. W ten sposób ta metoda została dodana do istniejących opcji testowania zgodności aplikacji na standardowym systemie Android bez zmian w zachowaniu OEM, inne są używając smartfona Pixel, używając oficjalnego emulatora Androida w Android Studio lub wdrażając kompilacje aplikacji na instancję urządzenia w chmurze.
Pomimo całej wygody, jaką zapewniały GSI, ich instalacja była nadal uciążliwym procesem. Twórcy aplikacji mogą nie czuć się komfortowo z ręcznym flashowaniem obrazu systemu na urządzeniu z Androidem, ponieważ jest to coś, co zwykle znają tylko hobbyści lub programiści systemu operacyjnego Android. Zainstalowanie GSI wymagało flashowania obrazu systemu przez fastboot, co wymaga wyłączenia zweryfikowanego rozruchu systemu Android i odblokowania programu ładującego. Z kolei odblokowanie bootloadera wymaga całkowitego wyczyszczenia danych użytkownika. A jak wszyscy wiemy, nie ma dokładnie jednego procesu ani przewodnika do odblokowania programu ładującego na każdym urządzeniu z Androidem, więc nie można znaleźć spójności. Na przykład urządzenia Samsung nie mają szybkiego uruchamiania, podczas gdy urządzenia Xiaomi zmuszają do przeskoczenia kilku kółek, aby odblokować program ładujący. To wygodny bałagan, który może zostać rozplątany w coś prostszego.
W tym miejscu pojawiają się dynamiczne aktualizacje systemu.
Dynamiczne aktualizacje systemu po prostu instalują GSI
Google zdało sobie sprawę, że obecny sposób instalowania GSI nie jest idealnym rozwiązaniem, więc zaczął pracować nad lepszym rozwiązaniem. W Androidzie 10 Firma Google rozpoczęła testowanie dynamicznych aktualizacji systemulub DSU. DSU to nowy sposób tymczasowej instalacji GSI bez konieczności używania poleceń fastboot do flashowania obrazu systemu, nadpisując oryginalną instalację. Dzięki DSU możesz uruchomić system GSI, przetestować aplikację, a następnie w wygodny sposób ponownie uruchomić ją z powrotem do oryginalnej instalacji, która pozostała nietknięta.
Powodem, dla którego DSU może zainstalować GSI bez ingerencji w pierwotną instalację, jest to, że tworzy nowe obrazy systemu i partycji danych, które są tymczasowo przechowywane w /data/gsi. Obrazy te są następnie montowane podczas rozruchu zamiast oryginalnego systemu i partycji danych. Ponieważ telefon potrzebuje dodatkowego miejsca do przechowywania tych nowych, tymczasowych obrazów, telefon musi mieć na pokładzie „partycje logiczne”, których rozmiar można dynamicznie zmieniać. Partycje logiczne to nowy system partycjonowania przestrzeni użytkownika dla systemu Android, który jest obowiązkowy dla urządzeń uruchamianych z systemem Android 10. Jeśli Twoje urządzenie zostało uruchomione z systemem Android 10, powinno obsługiwać instalowanie GSI za pośrednictwem DSU.
W Androidzie 10 wszystko, co musisz zrobić, aby zainstaluj GSI przez DSU polega na zmianie właściwości systemu, a następnie uruchomieniu Usługa Dynamic SystemUpdatesInstallationService wysyłając intencję ze ścieżką do GSI jako dodatkową intencję.
Chociaż ten proces może wydawać się nieznany, jest o wiele łatwiejszy i mniej uciążliwy w porównaniu z używaniem polecenia fastboot i radzenie sobie ze wszystkim, łącznie z oryginalną instalacją wytarty. Potrzebujesz pewnej wiedzy na temat ADB i zamiarów korzystania z DSU, ale nie powinno to stanowić problemu dla większości twórców aplikacji. Mimo to nie ma powodu, dla którego proces ten nie mógłby być jeszcze prostszy. Ponadto faktem jest, że instalacja GSI za pośrednictwem DSU nadal wymaga odblokowania programu ładującego, usuwając przy tym wszystkie dane użytkownika. W tym celu firma Google wprowadziła zmiany poprawiające oba aspekty instalacji GSI. W systemie Android 11 wyeliminowali potrzebę używania wiersza poleceń w celu zainstalowania GSI. Oddzielnie umożliwiły również instalację GSI bez odblokowywania bootloadera.
Moduł ładujący DSU w systemie Android 11
DSU Loader to nowe narzędzie obecne w Opcjach programisty Androida 11, które pozwala pobierać I zainstalować najnowszy GSI od Google bez konieczności wprowadzania jakichkolwiek poleceń fastboot lub ADB. Po prostu dotknij opcji DSU Loader w Ustawieniach, a pojawi się okno dialogowe z listą obsługiwanych GSI bezpośrednio od Google. Te obsługiwane GSI będą oparte na bieżącym systemie operacyjnym i architekturze, więc możesz instalować tylko GSI, które są nowsze niż wersja twojego systemu operacyjnego i pasują do twojej architektury SoC. Po prostu wybierz GSI, który chcesz zainstalować, a zostanie on pobrany z serwerów Google i automatycznie zainstalowany w tle.
Dzięki DSU Loader programiści nigdy nie muszą dotykać wiersza poleceń, aby zainstalować GSI. Przynajmniej takie jest marzenie, bo do rozwiązania pozostał jeszcze jeden problem.
Droga naprzód
Obecnie, aby zainstalować GSI przez DSU Loader, potrzebujesz odblokowanego bootloadera. Chociaż może to zniweczyć cel całej próby, nie powinno tak być i powiedziano nam, że zostanie to naprawione. Google zaplanowało, aby użytkownicy mogli uruchamiać GSI podpisane przez Google przez DSU bez konieczności odblokowywania programu ładującego. W rzeczywistości Google to nakazuje wszystkie urządzenia uruchamiające Androida 10 zawierają klucze publiczne Android Verified Boot podpisanych przez Google GSI dla Androida 10, Androida 11 i Androida 12. Dołączenie publicznych kluczy AVB do ramdysku urządzenia zapewni, że AVB nie odrzuci GSI, który próbujesz uruchomić. Dlatego obecna metoda polega na odblokowaniu bootloadera - flashując pusty obraz vbmeta na partycję vbmeta, wyłączasz AVB, aby nie odrzucił GSI, który zamierzasz sflashować. Wyłączenie AVB stanowi jednak poważne zagrożenie bezpieczeństwa, ponieważ oznacza, że wszelkie zmodyfikowane partycję system/boot/product/vendor można załadować na urządzenie, dlatego Google chce to zrobić precz z tym wymaganiem.
Kiedy więc można spodziewać się uruchomienia GSI przez DSU bez konieczności odblokowywania programu ładującego lub korzystania z narzędzi wiersza poleceń? Miejmy nadzieję, że wkrótce, ponieważ Google wspomniało nam, że mieli kilka problemów do rozwiązania z początkowymi podglądami programistów Androida 11, zanim będą mogli sprawić, by wszystko działało poprawnie. Idąc dalej, można spodziewać się instalacji przyszłych GSI Developer Preview za pośrednictwem DSU bez konieczności odblokowywania programu ładującego. Być może po udostępnieniu podglądu programisty Androida 12 będzie można go nawet całkowicie uruchomić za pomocą DSU Loader w opcjach programisty Androida 11. Dla twórców aplikacji oznacza to, że będzie jeszcze jeden sposób testowania aplikacji na fizycznym sprzęcie z nową wersją Androida.