Generic Kernel Image společnosti Google je dalším krokem k vyřešení problému fragmentace Androidu

Google pracuje na snížení fragmentace na Androidu už roky, i když součástí příčiny je vlastní povaha Androidu a dvojsečný meč volby a svobody. Ve vesmíru je aktivní nespočet OEM výrobců a všichni chtějí provádět vlastní úpravy pro svá vlastní zařízení. Problém je pak v tom, že se zdá, že aktualizace operačního systému Android se pomalu rozšiřují, ale ve skutečnosti toho Google nemůže udělat mnoho, aby přinutil výrobce OEM aktualizovat svá zařízení. Další nejlepší věcí, kterou může Google udělat, je, aby byl proces aktualizace co nejjednodušší a nejplynulejší.

Zmírnění bolesti při aktualizaci Androidu

První velká iniciativa v dlouhodobém projektu společnosti Google zaměřená na snížení vývojové zátěže byla Projekt Treble. Projekt Treble, který byl ohlášen společně s Androidem 8.0 Oreo v roce 2017, modularizoval Android oddělením rámce OS od implementace dodavatele (HAL a vidlice jádra Linuxu specifická pro zařízení). To usnadnilo výrobcům Android OEM předělat své operační systémy na nejnovější framework AOSP, protože mohli zavést nejnovější verzi, aniž by potřebovali aktualizovaný kód od dodavatelů. V důsledku toho mohli výrobci OEM připravit své vlastní platformy pro Android rychleji než dříve a navíc rychleji zavádět hlavní aktualizace operačního systému.

Dalším krokem v plánech společnosti Google bylo zefektivnit doručování aktualizací klíčových komponent systému Android. Google tuto iniciativu nazval Hlavní linie projektu když jej v roce 2019 představila spolu s Androidem 10. Google v podstatě převzal kontrolu nad klíčovými komponentami OS a zakázal OEM je upravovat. Poté nastavili mechanismus doručení prostřednictvím Google Play, aby mohli na dálku zavádět aktualizace těchto klíčových komponent, aniž by museli čekat, až OEM sami aplikují opravy. Mainline výrazně zlepšil, jak rychle zařízení přijímají aktualizované verze důležitých komponent operačního systému, což zase zlepšilo zabezpečení ekosystému Android jako celku.

Pokud však jde o Treble, linuxové jádro by se realisticky nemělo hromadit s uzavřeným kódem dodavatele. Todd Kjos v letošní konference Linux Plumbers Conference v minulosti vysvětlil potíže, s nimiž se potýkáme, pokud jde o fragmentaci na Androidu, a mnoho z nich se nyní soustředí kolem linuxového jádra, které výrobci OEM dodávají se svými zařízeními. Pro kontext Google rozdělí každé jádro Linuxu hlavní řady na „Android Common Kernel” (ACK), která podrobně sleduje vydání hlavní řady, ale přidává několik záplat specifických pro Android. Prodejci SoC, jako jsou Qualcomm, MediaTek a Samsung, se poté rozvětvují že jádro pro každý SoC, který vyrobí. Výrobci OEM poté vezmou jádro specifické pro SoC a přidají další záplaty pro implementaci podpory pro konkrétní hardware, který chtějí dodávat.

Výše uvedený diagram ukazuje, jak jádro zařízení prochází několika vrstvami změn, které jej abstrahují daleko od jádra Linux LTS. Abychom to zjednodušili, začínáme linuxovým jádrem, které se s několika změnami sloučí do Android Common Kernel. Odtud se Android Common Kernel sloučí do jádra dodavatele (Qualcomm, MediaTek atd.) s vlastními úpravami a změnami. Nakonec je jádro dodavatele začleněno do jádra OEM specifického pro zařízení. V této fázi je jádro libovolného zařízení velmi vzdálené od jádra Linux LTS, se kterým začalo.

Výsledkem všech těchto forků je, že až 50 % kódu běžícího na zařízení Android je mimo stromový kód, což znamená, že nepochází z upstreamových linuxových nebo běžných jader AOSP. Díky tomu je neuvěřitelně obtížné (nemluvě o časově náročném a nákladném) slučování upstream změn. Pro výrobce OEM k tomu neexistuje žádná pobídka, ale tato praxe může být škodlivá pro zabezpečení zařízení. To je také důvod, proč je mnoho zařízení Android ponecháno na starších verzích jádra LTS, což má vedlejší účinek v tom, že zařízení ztrácejí přístup k novým funkcím jádra Linuxu.

Android je fragmentovaný a Google to ví

Google dobře ví, že se jedná o problém, a dokonce má sekci nazvanou „Náklady na fragmentaci“ v dokumentaci pro vývojáře systému Android. Google to říká "většina vlajkových zařízení se dodává s verzí jádra, která je již minimálně 18 měsíců stará". Ještě horší je, že to říká i Google "Android 10 podporuje jádra 3.18, 4.4, 4.9, 4.14 a 4.19, která v některých případech nebyla vylepšena o nové funkce od Androidu 8 v roce 2017." To ztěžuje přidávání funkcí, které vyžadují nové verze linuxového jádra. Linuxové jádro 3.18 bylo spuštěno v prosinci 2014, tedy v době, kdy Android 5.0 Lollipop byl nejnovější verzí Androidu. To je zjevně problém a může to brzdit platformu.

Například Code Aurora Forum nebo zkráceně CAF hostí zdrojový kód pro různé SoC Qualcomm Snapdragon. Qualcomm jako SoC prodejce distribuuje rozvětvenou verzi linuxového jádra výrobcům OEM/ODM a tyto společnosti pak při dodání přidávají změny specifické pro zařízení zařízení. To přidává několik vrstev fragmentace. Kromě toho Qualcomm provádí změny v rámci AOSP, aby optimalizoval Android pro každou z mobilních platforem Snapdragon společnosti. Qualcomm soukromě distribuuje své upravené linuxové jádro, framework AOSP a další softwarové nástroje svým partnerům jako součást balíčku podpory rady neboli BSP. CAF je místo, kde Qualcomm veřejně publikuje tyto změny linuxového jádra a změny rámce AOSP.

Tato verze CAF může být užitečná pro vlastní vývojáře ROM, kteří ji chtějí použít jako výchozí bod spíše než čisté AOSP, což je důvod, proč někdy vidíte ROM „založené na CAF“ na našich fórech. Pamatujete si na Snapdragon 625, který po léta poháněl tolik smartphonů střední třídy? To bylo zahájeno s linuxovým jádrem 3.18 a teprve koncem roku 2018 (dva roky po uvedení čipové sady) společnost Qualcomm aktualizovala zdrojové kódy jádra a zveřejnila je na CAF pro msm8953 (název čipové sady Snapdragon 625), který přináší podporu pro Linux Kernel 4.9. Problém je, že většina OEM nebude aktualizovat telefony na tuto novou verzi linuxového jádra, zvláště ne telefony střední třídy dva roky po tom, co byl čip propuštěn. Je pravda, že je velmi vzácné, aby k takové velké aktualizaci jádra vůbec došlo, ale jde o to, že má stalo, takže to není jen nemožný scénář.

Suma sumárum, současná roztříštěnost v Androidu je, mírně řečeno, průšvih. Nejnovější pokusy Google napravit tuto fragmentaci přicházejí ve formě Generic Kernel Image nebo GKI.

Představujeme Generic Kernel Image

Aby Google vyřešil tuto fragmentaci, pracoval na Android Generic Kernel Image (GKI). Toto je v podstatě jádro zkompilované přímo z větve ACK. GKI izoluje přizpůsobení výrobců SoC a OEM do modulů zásuvných modulů, čímž eliminuje kód mimo strom a umožňuje společnosti Google posílat aktualizace jádra přímo koncovému uživateli. Více než rok Google pracuje na způsobu, jak doručovat aktualizace GKI prostřednictvím Obchodu Play, pomocí modulu Mainline.

V důsledku toho musí zařízení se systémem Android 12 se systémem Linux kernel 5.10.43 nebo vyšším provést jednu z následujících akcí: podle Mishaala Rahmana.

• Nasaďte spouštěcí obraz podepsaný společností Google

NEBO

• Nasaďte spouštěcí obraz s jádrem, které exportuje KMI (Kernel Module Interface), které je podmnožinou KMI exportovaného GKI, exportuje uživatelské rozhraní API, které je nadmnožinou UAPI vystaveného GKI, a podporuje všechny funkce odpovídajícího GKI verze

Prodejci mohou vytvářet moduly, které se zapojují do GKI, ale myšlenka GKI spočívá v tom, že Google přebírá břemeno odpovědnosti za zpracování změn jádra. Rozhraní modulu jádra (neboli KMI, více v dalších částech článku) je v podstatě tam, kde se očekává, že kód mimo strom půjde.

Řada Google Pixel 6 byla uvedena na trh se systémem Android 12 po vybalení a je dodávána s linuxovým jádrem 5.10 a je to první telefon dodávaný s GKI. Protože Google může potenciálně aktualizovat jádro prostřednictvím Obchodu Play, můžeme dokonce zaznamenat časté aktualizace jádra, protože aktualizace jádra LTS jsou obvykle vydávány týdně. Ať tak či onak, je to mnohem lepší systém než v současnosti těžkopádný způsob aktualizace přes OTA, i když to znamená, že je neodmyslitelně svázán s rámcem GMS.

Google jednoduše definuje GKI takto:

• Je postaven ze zdrojů ACK.
• Jedná se o binární soubor s jedním jádrem plus přidružené zaváděcí moduly na architekturu a vydání LTS (v současnosti pouze arm64 pro android11-5.4 a android12-5.4).
• Je testován se všemi verzemi platformy Android, které jsou podporovány pro související ACK. Po celou dobu životnosti verze jádra GKI není žádná podpora funkcí
• Vystavuje stabilní KMI řidičům v rámci daného LTS.
• Neobsahuje SoC ani kód specifický pro desku.

Google dokonce chce být do roku 2023 v pozici, kdy bude moci zaujmout vývojový model „první upstream“. To Googlu pomůže zajistit, aby nový kód přistál jako první v hlavním linuxovém jádře, čímž se sníží „technický dluh“ nahromaděný mimo stromový kód na zařízeních Android.

Rozhraní modulu jádra (KMI)

Kernel Module Interface neboli KMI je součástí řešení Google pro pokračující fragmentaci v Androidu. V podstatě SoC a podpora desky již nejsou umístěny v jádru jádra a místo toho jsou přesunuty do zaváděcích modulů. Jak jádro, tak moduly lze poté aktualizovat nezávisle, protože moduly jsou aktualizovány v /lib/modules. Samotné GKI má být co nejčistší a nejobecnější, což je umožněno přemístěním kódu, který je nyní mimo strom, do samostatných modulů.

Jako Ted Kjos vysvětleno na na letošní konferenci Linux Plumbers Conference „velkým mnohaletým tlakem je dostat veškerý hardwarově specifický kód z generického jádra do modulů dodavatelů. Musíme mít stabilní rozhraní mezi těmito moduly dodavatelů a generickým jádrem, aby mohly být dodávány asynchronně." GKI 1.0 je v podstatě "test shody".

Kompatibilita GKI ve skutečnosti znamená, že zařízení projde testy VTS a CTS-on-GSI+GKI s Generic System Image (GSI). a jádro GKI nainstalované flashováním spouštěcího obrazu GKI do zaváděcího oddílu a obrazu systému GSI v systému rozdělit. Vendor Test Suite neboli VTS je automatický test, kterým musí projít všechna zařízení, aby byla považována za kompatibilní s Project Treble. Pro přístup k sadě aplikací Google je vyžadována sada testů kompatibility nebo CTS.

Zařízení mohou být dodávána s jiným jádrem produktu a mohou používat zaváděcí moduly, které GKI neposkytuje. Jádra produktu i GKI však musí načíst moduly ze stejných oddílů vendor_boot a vendor. Proto se vyžaduje, aby všechna jádra produktu měla stejné rozhraní binárního modulu jádra (KMI).

Výše uvedený diagram ukazuje, co Google chce a vysvětluje, jak toho hodlá dosáhnout. Moduly Generic Kernel a GKI budou součástí AOSP a GKI může komunikovat s frameworkem Android a Hardware Abstraction Layer (HAL), které může dodavatel implementovat. Konkrétní proprietární kód, který prodejce požaduje v jádře (například ovladače fotoaparátu), bude místo toho vložen do modulu dodavatele, který se stane rozšířením GKI prostřednictvím KMI.

Jak může GKI pomoci vyřešit problém s fragmentací Androidu

Google vynakládá hodně práce na zefektivnění procesu vývoje chytrých telefonů. Každý OEM chce svou vlastní identitu značky a každý OEM chce mít možnost vlastnit svá zařízení. Na rozdíl od programu Android One mohou chytré telefony se systémem Android v podstatě být čímkoli, co chtějí, pokud dodržují soubor pravidel, která společnost Google stanoví pro získání licence GMS. V minulosti však Google neudělal mnoho pro to, aby kraloval ve vývoji zařízení Android změny jako Project Treble, Mainline a nyní je GKI v Androidu mnohem novější Dějiny.

Ale pomůže to? Mělo by to stačit, i když pravděpodobně půjde o mnohaletou záležitost, která později přinese viditelné ovoce. To se bude týkat pouze zařízení se systémem Android 12, což znamená, že v nadcházejících letech uvidíme zařízení, která nebudou mít GKI. To byla také kritika Project Treble, když to bylo oznámeno, i když to samozřejmě podporují všechna zařízení, která jsou dnes uvedena na trh. Tyto věci vyžadují čas, a jak Google pomalu získává vládu nad Androidem, proces vývoje je pro všechny OEM v ekosystém Android, i když někteří z nich by si raději ponechali plnou kontrolu nad linuxovým jádrem, které se používá na Androidu chytré telefony.