Czy kiedykolwiek chciałeś wypróbować aktualizację bez aktualizacji? DSU w Androidzie 10 jest do tego przeznaczone, ale obecnie jest ograniczone. To może się wkrótce zmienić.
Fragmentacja systemu operacyjnego Android i poziomu bezpieczeństwa to ogromny problem, z którym Google wkłada wiele wysiłku inżynieryjnego, aby go rozwiązać. W ciągu ostatnich dwóch lat Google ogłosił dwie główne inicjatywy mające na celu przyspieszenie wdrażania aktualizacji: Projekt Treble I Główna linia projektu. Ten ostatni został ogłoszony dopiero w maju tego roku We/Wy Google 2019i jest obsługiwana tylko na urządzeniach z systemem Android 10. Jednak ten pierwszy jest już obecny We/Wy Google 2017, więc widzieliśmy, jak duży wpływ ma to na aktualizacje Androida z Androidem 9 Pie I Androida 10.
Oprócz ograniczenia fragmentacji Google chce także, aby Project Treble był przydatny dla twórców aplikacji. Dlatego ujawnili Dynamiczne aktualizacje systemu (DSU) w systemie Android 10, aby umożliwić programistom wypróbowanie podstawowej wersji nowej aktualizacji systemu operacyjnego bez odblokowywania programu ładującego lub czyszczenia danych. Widząc potencjał DSU, Google nie poprzestaje na tym — rozszerza jego użyteczność, umożliwiając instalowanie aktualizacji OTA od producentów OEM w taki sam sposób, w jaki instalowane są GSI.
To dużo żargonu, ale wyobraź sobie, że stanie się to w przyszłości: producent OEM wypuszcza telefon z Androidem 10 i rozpoczyna program beta dla Androida 11. Chcesz wypróbować tę wersję beta, aby zobaczyć nowe funkcje, ale nie chcesz ryzykować stabilności swojego obecnego codziennego sterownika. Zamiast flashować aktualizację beta i mieć nadzieję, że będzie całkowicie stabilna, dlaczego nie zainstalować jej tymczasowo poprzez przepływ DSU? Jeśli Ci się to nie podoba, po prostu uruchom ponownie komputer, a konfiguracja wróci do normy. Jeśli Ci się spodoba, możesz „zatwierdzić” aktualizację.
Nie wiem jak Wy, ale byłaby to mile widziana zmiana w Androidzie, która sprawi, że testowanie wersji beta stanie się przyjemniejsze. Nie będziesz już musiał angażować się w aktualizację wersji beta, aby samemu przekonać się, jak to jest. Jestem pewien, że wielu z Was nie może się doczekać wersji beta Androida 10 na swoje urządzenie, ale instalacja go od razu może nie być komfortowa. Po zmianach wprowadzonych w DSU nie byłoby to już problemem.
Dynamiczne aktualizacje systemu w Androidzie 10+ – co się zmienia
Luca Stefani, przyjaciel portalu XDA i Uznany programista, poinformował nas o nowe zatwierdzenie połączone w AOSP pod tytułem „zamontuj wiele partycji DSU, jeśli są obecne”. Zatwierdzenie wprowadza zmiany w tabeli systemu plików (fstab) i pliku init, aby podczas rozruchu można było zamontować partycje DSU inne niż systemowe, na razie obejmujące produkt i dostawcę proces.
Obecnie DSU umożliwia jedynie uruchamianie Generic System Image (GSI), czyli obrazu systemu typu barebone skompilowanego z AOSP, dzięki czemu można testować nowe interfejsy API i inne zmiany wprowadzone w najnowszej aktualizacji Androida. Jednak wraz z tą zmianą DSU będzie akceptować także zdjęcia produktów i dostawców. Pierwsza zawiera aplikacje, biblioteki i inne pliki specyficzne dla urządzenia, natomiast druga zawiera pliki binarne specyficzne dla urządzenia. Projekt Treble umożliwił uruchomienie urządzenia przy użyciu obrazu systemu bez plików specyficznych dla urządzenia, zatem zezwolenie na ładowanie produktu i dostawcy nie wydaje się mieć większego sensu.
Jednak inżynier Google wyraźnie mówi, że ta zmiana ma „umożliwić producentom OEM [instalowanie] pakietów OTA na /data, a następnie używanie przepływu „DSU” do montowania pliku produktu.img, system.img, [i] sprzedawca.img z /data.” Oznacza to, że zamiast nadpisywać bieżącą instalację nowym pakietem OTA, można tymczasowo załadować OTA za pośrednictwem DSU. Po wypróbowaniu aktualizacji OTA „użytkownik może zdecydować, czy chce„ przekazać ”te obrazy do /super, czy nie”. Ta ostatnia część o „zatwierdzanie” zmian jest nadal w toku, jak zauważa jeden z inżynierów Google, że „obecnie nie mamy planu tworzenia partycji DSU na stałe w kontekście DSU.” Następnie stwierdza, w jaki sposób można to wdrożyć, ale że wdrożenie to „poza zakresem” niniejszego dokumentu aktualna łatka.
Istnieje kilka terminów i koncepcji, które musimy tutaj wyjaśnić, ponieważ Google lubi zmieniać schemat partycji w każdej wersji Androida. Na początek polecam przeczytać mój poprzedni artykuł nt Dynamiczne aktualizacje systemu aby uzyskać ogólny przegląd tego, jak to działa, ale w skrócie wykorzystuje koncepcję „partycji dynamicznej”, jednej prawdziwej partycji pamięci (zwanej „super” partycja), która jest podzielona na partycje logiczne o zmiennym rozmiarze (w tym systemowe, dostawcy, produktu i system_ext), aby tymczasowo zainstalować GSI. Podczas instalowania GSI DSU tworzy miejsce na nowy system i obrazy danych użytkownika, zmieniając rozmiar istniejącej partycji danych użytkownika. Elementy składowe obsługi DSU (partycje dynamiczne, ramdysk i punkty kontrolne dla kopii zapasowych danych) to wymagania uruchomieniowe dla Androida 10, więc każde urządzenie uruchamiane z nową wersją systemu operacyjnego Android powinno obsługiwać DSU. DSU nie jest rozwiązaniem podwójnego rozruchu dla niestandardowych ROM-ów, którego niektórzy z Was szukają, ponieważ można zainstalować tylko obrazy pasujące do kluczy Android Verified Boot (AVB). Jednak dzięki tej nowej zmianie może okazać się znacznie bardziej przydatna w przyszłości.
Oprócz partycji dynamicznych Google wprowadził w Androidzie 10 także koncepcję „wirtualnego A/B”. Jest to w zasadzie implementacja dwie partycje A/B z wcześniej, ale zamiast tego z partycjami logicznymi. Partycje A/B obejmują kopie ważnych partycji, aby umożliwić płynne i bezpieczne aktualizacje. Korzystanie z „wirtualnego A/B” to sposób, w jaki jeden z inżynierów Google wyobraża sobie „zatwierdzanie” partycji DSU na partycjach z bieżącej instalacji; podobnie jak w przypadku bieżącego procesu aktualizacji A/B OTA, być może zmiany z nowych obrazów zostaną wprowadzone na nieaktywną partycję.
Zmiany te są wciąż w fazie rozwoju i może minąć trochę czasu, zanim zostaną wykorzystane przez Google lub producentów OEM. My prawdopodobnie nie zobaczymy żadnych implementacji tego rozwiązania, dopóki nie zostanie wydany Android 11 R rok. Mimo to nie ma gwarancji, że producenci OEM w ogóle zastosują tę funkcję w aktualizacjach OTA. Biorąc jednak pod uwagę, jak przydatne wydaje się to w przypadku testów beta, wyobrażam sobie, że Google już współpracuje z zainteresowanymi producentami OEM, aby włączyć tę funkcję w przyszłych aktualizacjach. Osobiście jestem podekscytowany perspektywą wypróbowania nowych aktualizacji Androida przed zakupem, ale co z Tobą?