Ogólny obraz jądra Google to kolejny krok w kierunku rozwiązania problemu fragmentacji Androida

Google od lat pracuje nad ograniczeniem fragmentacji Androida, choć częściowo jest to przyczyną nieodłącznej natury Androida oraz obosiecznego miecza wyboru i wolności. Na rynku działa niezliczona liczba producentów OEM i wszyscy chcą wprowadzać własne modyfikacje do swoich urządzeń. Problem w tym, że wygląda na to, że aktualizacje systemu operacyjnego Android są wprowadzane powoli, ale Google nie może wiele zrobić, aby zmusić producentów OEM do aktualizacji swoich urządzeń. W związku z tym następną najlepszą rzeczą, jaką Google może zrobić, jest uczynienie procesu aktualizacji tak prostym i bezproblemowym, jak to tylko możliwe.

Łagodzenie bólu związanego z aktualizacją Androida

Pierwszą dużą inicjatywą w długoterminowym projekcie Google mającą na celu zmniejszenie obciążeń programistycznych było Projekt Trebel. Ogłoszony wraz z Androidem 8.0 Oreo w 2017 roku projekt Treble zmodularyzował Androida, oddzielając strukturę systemu operacyjnego od implementacji dostawcy (HAL i rozwidlenie jądra Linuksa specyficzne dla urządzenia). Ułatwiło to producentom OEM Androida ponowne oparcie swoich systemów operacyjnych na najnowszym frameworku AOSP, ponieważ mogli uruchomić najnowszą wersję bez konieczności aktualizowania kodu od dostawców. W rezultacie producenci OEM mogą szybciej niż dotychczas przygotowywać niestandardowe forki systemu Android, a co za tym idzie, szybciej wdrażać główne aktualizacje systemu operacyjnego.

Kolejnym krokiem w planach Google’a było usprawnienie dostarczania aktualizacji kluczowych komponentów Androida. Google nazwał tę inicjatywę Główna linia projektu kiedy wprowadził go wraz z Androidem 10 w 2019 roku. Google zasadniczo przejął kontrolę nad kluczowymi komponentami systemu operacyjnego i zakazał producentom OEM ich modyfikowania. Następnie skonfigurowali mechanizm dostarczania za pośrednictwem Google Play, aby móc zdalnie wdrażać aktualizacje tych kluczowych komponentów bez konieczności czekania, aż producenci OEM sami zastosują poprawki. Mainline znacznie poprawiło szybkość, z jaką urządzenia otrzymują zaktualizowane wersje ważnych komponentów systemu operacyjnego, co z kolei poprawia bezpieczeństwo całego ekosystemu Androida.

Jednak jeśli chodzi o Treble, jądro Linuksa nie powinno być wrzucane do jednego worka z kodem dostawcy o zamkniętym kodzie źródłowym. Todda Kjosa w tegoroczna konferencja hydraulików systemu Linux wyjaśnił w przeszłości trudności napotykane w przypadku fragmentacji systemu Android, a obecnie wiele z nich koncentruje się wokół jądra Linuksa, które producenci OEM dostarczają ze swoimi urządzeniami. Dla kontekstu Google rozwidla każde główne jądro Linuksa w „Wspólne jądro Androida” (ACK), która ściśle śledzi wydanie główne, ale dodaje kilka poprawek specyficznych dla Androida. Następnie dostawcy SoC, tacy jak Qualcomm, MediaTek i Samsung, rozwidlają się To jądro dla każdego wykonanego przez siebie SoC. Producenci OEM następnie biorą jądro specyficzne dla SoC i dodają dodatkowe poprawki, aby zaimplementować obsługę konkretnego sprzętu, który chcą dostarczać.

Powyższy diagram pokazuje, jak jądro urządzenia przechodzi przez kilka warstw zmian, które odbiegają od jądra Linux LTS. Aby to uprościć, zaczynamy od jądra Linuksa, które z kilkoma zmianami zostaje połączone ze wspólnym jądrem Androida. Stamtąd wspólne jądro Androida zostaje połączone z jądrem dostawcy (Qualcomm, MediaTek itp.) z własnymi modyfikacjami i zmianami. Na koniec jądro dostawcy jest łączone z jądrem specyficznym dla urządzenia OEM. Na tym etapie jądro dowolnego urządzenia jest bardzo odległe od jądra Linux LTS, od którego zaczęło się.

W wyniku tych wszystkich forków aż 50% kodu działającego na urządzeniu z Androidem to kod spoza drzewa, co oznacza, że ​​nie pochodzi on z wcześniejszych jąder Linuksa lub AOSP. To sprawia, że ​​łączenie wcześniejszych zmian jest niezwykle trudne (nie wspominając o czasochłonności i kosztach). Producenci OEM nie mają do tego żadnej zachęty, ale taka praktyka może być szkodliwa dla bezpieczeństwa urządzeń. Z tego też powodu wiele urządzeń z Androidem korzysta ze starszych wersji jądra LTS, czego skutkiem ubocznym jest utrata przez urządzenia dostępu do nowych funkcji jądra Linuksa.

Android jest pofragmentowany i Google o tym wie

Google doskonale wie, że jest to problem, i ma nawet sekcję zatytułowaną „Koszty fragmentacji" w dokumentacji programisty Androida. Google tak twierdzi „większość flagowych urządzeń jest dostarczana z wersją jądra mającą już co najmniej 18 miesięcy”. Co gorsza, Google również tak twierdzi „Android 10 obsługuje jądra 3.18, 4.4, 4.9, 4.14 i 4.19, które w niektórych przypadkach nie zostały wzbogacone o nowe funkcje od czasu Androida 8 z 2017 roku”. Utrudnia to dodawanie funkcji wymagających nowych wersji jądra Linuksa. Jądro Linuksa 3.18 zostało wypuszczone w grudniu 2014 roku, kiedy najnowszą wersją Androida był Android 5.0 Lollipop. Jest to wyraźnie problem, który może zatrzymać platformę.

Na przykład Code Aurora Forum, w skrócie CAF, udostępnia kod źródłowy różnych układów SoC Qualcomm Snapdragon. Qualcomm jako SoC dostawca, dystrybuuje rozwidloną wersję jądra Linuksa wśród producentów OEM/ODM, a firmy te następnie dodają zmiany specyficzne dla urządzenia w wysyłce urządzenia. To właśnie dodaje kilka warstw fragmentacji. Ponadto Qualcomm wprowadza zmiany w frameworku AOSP, aby zoptymalizować Androida dla każdej z platform mobilnych Snapdragon firmy. Qualcomm prywatnie dystrybuuje zmodyfikowane jądro Linuksa, platformę AOSP i inne narzędzia programowe swoim partnerom w ramach pakietu wsparcia płyty (BSP). CAF to miejsce, w którym Qualcomm publicznie publikuje zmiany w jądrze Linuksa i zmiany w strukturze AOSP.

Ta wersja CAF może być przydatna dla programistów niestandardowych pamięci ROM, którzy chcą używać jej jako punktu wyjścia, a nie czystego AOSP, dlatego czasami widzisz ROMy „oparte na CAF” na naszych forach. Pamiętacie Snapdragona 625, który przez lata zdawał się zasilać tak wiele smartfonów ze średniej półki? Zostało to uruchomione wraz z jądrem Linux 3.18 i dopiero pod koniec 2018 roku (dwa lata po premierze chipsetu) Qualcomm zaktualizował źródła jądra i opublikował je na CAF dla msm8953 (nazwa chipsetu Snapdragon 625) zapewniającego obsługę jądra Linux 4.9. Problem w tym, że większość producentów OEM nie zaktualizuje telefonów do nowej wersji jądra Linuksa, zwłaszcza telefonów średniej klasy dwa lata po wprowadzeniu chipa wydany. Trzeba przyznać, że bardzo rzadko zdarza się, aby taka większa aktualizacja jądra w ogóle miała miejsce, ale chodzi o to, że ma się wydarzyło, więc nie jest to tylko scenariusz niemożliwy.

Podsumowując, obecna fragmentacja Androida to, delikatnie mówiąc, bałagan. Najnowsze próby Google mające na celu naprawienie tej fragmentacji mają formę ogólnego obrazu jądra, w skrócie GKI.

Przedstawiamy ogólny obraz jądra

Aby zaradzić tej fragmentacji, Google pracował nad ogólnym obrazem jądra Androida (GKI). Zasadniczo jest to jądro skompilowane bezpośrednio z gałęzi ACK. GKI izoluje dostosowania dostawców SoC i OEM do modułów wtyczek, eliminując kod spoza drzewa i umożliwiając Google przesyłanie aktualizacji jądra bezpośrednio do użytkownika końcowego. Google od ponad roku pracuje nad sposobem dostarczania aktualizacji GKI poprzez Sklep Play, poprzez zastosowanie modułu Mainline.

W rezultacie urządzenia uruchamiane z systemem Android 12 i jądrem Linux w wersji 5.10.43 lub nowszej muszą wykonać jedną z następujących czynności: według Mishaala Rahmana.

• Wdróż obraz rozruchowy podpisany przez Google

LUB

• Wdróż obraz rozruchowy z jądrem, które eksportuje KMI (interfejs modułu jądra), który jest podzbiorem KMI eksportowanym przez GKI, eksportuje interfejs API przestrzeni użytkownika, który jest nadzbiorem UAPI udostępnianym przez GKI i obsługuje wszystkie funkcje odpowiedniego GKI wersja

Dostawcy mogą tworzyć moduły podłączane do GKI, ale idea GKI jest taka, że ​​Google bierze na siebie ciężar odpowiedzialności za obsługę zmian w jądrze. Interfejs modułu jądra (lub KMI, więcej na ten temat w dalszej części artykułu) jest faktycznie miejscem, w którym oczekuje się, że kod będzie trafiał spoza drzewa.

Seria Google Pixel 6 została uruchomiona z systemem Android 12 od razu po wyjęciu z pudełka i dostarczana z jądrem Linux 5.10. Jest to pierwszy telefon dostarczany z GKI. Ponieważ Google mógłby potencjalnie zaktualizować jądro za pośrednictwem Sklepu Play, możemy nawet zauważyć częste aktualizacje jądra, ponieważ aktualizacje jądra LTS są zwykle wydawane co tydzień. Tak czy inaczej, jest to znacznie lepszy system niż obecnie uciążliwa metoda aktualizacji przez OTA, chociaż oznacza to, że jest on nieodłącznie powiązany ze strukturą GMS.

Google po prostu definiuje GKI w następujący sposób:

• Jest zbudowany ze źródeł ACK.
• Jest to plik binarny z jednym jądrem i powiązanymi z nim ładowalnymi modułami na architekturę, na wydanie LTS (obecnie tylko arm64 dla android11-5.4 I android12-5.4).
• Jest testowany ze wszystkimi wersjami platformy Android, które są obsługiwane dla powiązanego potwierdzenia ACK. Nie ma możliwości wycofania funkcji przez cały okres istnienia wersji jądra GKI
• Udostępnia kierowcom stabilny KMI w ramach danego LTS.
• Nie zawiera SoC ani kodu specyficznego dla płytki.

Google chce nawet osiągnąć do 2023 r. pozycję, w której będzie mógł przyjąć model rozwoju „najpierw na rynku wyższego szczebla”. Pomoże to Google zapewnić, że nowy kod wyląduje jako pierwszy w głównym jądrze Linuksa, redukując „dług techniczny” narosły w kodzie poza drzewem na urządzeniach z Androidem.

Interfejs modułu jądra (KMI)

Interfejs modułu jądra (KMI) jest częścią rozwiązania Google na trwającą fragmentację systemu Android. Zasadniczo obsługa SoC i płyty nie jest już zlokalizowana w jądrze rdzenia i zamiast tego została przeniesiona do ładowalnych modułów. Zarówno jądro, jak i moduły mogą być wówczas aktualizowane niezależnie, w miarę aktualizowania modułów /lib/modules. Sam GKI ma być tak przejrzysty i ogólny, jak to tylko możliwe, co jest możliwe dzięki przeniesieniu kodu spoza drzewa do oddzielnych modułów.

Jako Ted Kjos wyjaśniono o godz na tegorocznej konferencji Linux Plumbers Conference „wielkim, wieloletnim celem jest przeniesienie całego kodu specyficznego dla sprzętu z ogólnego jądra do modułów dostawców. Musimy mieć stabilny interfejs między modułami tych dostawców a ogólnym jądrem, aby mogły być dostarczane asynchronicznie.” GKI 1.0 jest zasadniczo „testem zgodności”.

W rzeczywistości kompatybilność z GKI oznacza, że ​​urządzenie przechodzi testy VTS i CTS-on-GSI+GKI z Generic System Image (GSI) i jądro GKI instalowane poprzez flashowanie obrazu rozruchowego GKI na partycję rozruchową i obraz systemu GSI w systemie przegroda. Vendor Test Suite, w skrócie VTS, to zautomatyzowany test, który muszą przejść wszystkie urządzenia, aby można je było uznać za zgodne z Project Treble. Aby uzyskać dostęp do pakietu aplikacji Google, wymagany jest pakiet Compatibility Test Suite (CTS).

Urządzenia mogą być dostarczane z innym jądrem produktu i mogą korzystać z ładowalnych modułów, których GKI nie zapewnia. Jednakże zarówno jądro produktu, jak i GKI muszą ładować moduły z tej samej partycji Vendor_boot i dostawcy. Dlatego wszystkie jądra produktów muszą mieć ten sam binarny interfejs modułu jądra (KMI).

Powyższy diagram pokazuje, co Google chce zrobić, i wyjaśnia, w jaki sposób zamierza to osiągnąć. Moduły jądra ogólnego i GKI będą częścią AOSP, a GKI może komunikować się ze strukturą Androida i warstwą abstrakcji sprzętu (HAL), którą może zaimplementować dostawca. Konkretny, zastrzeżony kod, którego dostawca chce umieścić w jądrze (na przykład sterowniki kamer), zostanie zamiast tego wepchnięty do modułu dostawcy, który stanie się rozszerzeniem GKI za pośrednictwem KMI.

Jak GKI może pomóc rozwiązać problem fragmentacji Androida

Google włożyło mnóstwo pracy w usprawnienie procesu rozwoju smartfonów. Każdy producent OEM chce mieć własną tożsamość marki i każdy producent OEM chce mieć możliwość posiadania swoich urządzeń na własność. W przeciwieństwie do programu Android One, smartfony z Androidem mogą mieć praktycznie wszystko, czego zapragną, pod warunkiem, że będą przestrzegać zestawu zasad określonych przez Google w celu uzyskania licencji GMS. Jednak w przeszłości Google nie zrobił zbyt wiele, aby królować w rozwoju urządzeń z Androidem zmiany, takie jak Project Treble, Mainline, a teraz GKI jest znacznie nowsze w Androidzie historia.

Ale czy to pomoże? Powinno wystarczyć, choć prawdopodobnie będzie to sprawa wieloletnia, która w przyszłości przyniesie widoczne owoce. Będzie to dotyczyć tylko urządzeń uruchamianych z systemem Android 12, co oznacza, że ​​przez wiele lat będziemy widzieć urządzenia, które nie będą miały GKI. Była to także krytyka Project Treble w momencie jego ogłoszenia, choć oczywiście wszystkie obecne na rynku urządzenia go obsługują. Takie rzeczy wymagają czasu, a w miarę jak Google powoli przejmuje władzę nad Androidem, proces programowania staje się łatwiejszy dla wszystkich producentów OEM w ekosystemu Androida, nawet jeśli niektórzy z nich woleliby zachować pełną kontrolę nad jądrem Linuksa używanym w Androidzie smartfony.