Generic Kernel Image spoločnosti Google je ďalším krokom k vyriešeniu problému fragmentácie systému Android

Google už roky pracuje na znižovaní fragmentácie v systéme Android, aj keď súčasťou toho je prirodzená povaha Androidu a dvojsečný meč voľby a slobody. Existuje nespočetné množstvo OEM aktívnych vo vesmíre a všetci chcú robiť svoje vlastné úpravy pre svoje vlastné zariadenia. Problém je potom v tom, že sa zdá, že aktualizácie operačného systému Android sa vo všeobecnosti zavádzajú pomaly, ale Google skutočne nemôže urobiť veľa, aby prinútil výrobcov OEM aktualizovať svoje zariadenia. Ďalšou najlepšou vecou, ​​​​ktorú môže spoločnosť Google urobiť, je urobiť proces aktualizácie tak jednoduchým a bezproblémovým, ako je to len možné.

Zmiernenie bolesti pri aktualizácii systému Android

Prvou veľkou iniciatívou v rámci dlhodobého projektu spoločnosti Google na zníženie vývojovej záťaže bolo Projekt Treble. Projekt Treble, ohlásený spolu s Androidom 8.0 Oreo v roku 2017, modularizoval Android oddelením rámca OS od implementácie dodávateľa (HAL a vidlica jadra Linuxu pre konkrétne zariadenie). To uľahčilo výrobcom Android OEM prebudovanie ich operačných systémov na najnovšom rámci AOSP, pretože mohli spustiť najnovšiu verziu bez potreby aktualizovaného kódu od dodávateľov. Výsledkom je, že výrobcovia OEM mohli pripraviť svoje vlastné platformy Android rýchlejšie ako predtým a vďaka rozšíreniu rýchlejšie zavádzať hlavné aktualizácie operačného systému.

Ďalším krokom v plánoch spoločnosti Google bolo zefektívniť doručovanie aktualizácií kľúčových komponentov systému Android. Google túto iniciatívu nazval Hlavná línia projektu keď ho predstavila spolu so systémom Android 10 v roku 2019. Google v podstate prevzal kontrolu nad kľúčovými komponentmi OS a zakázal výrobcom OEM ich upravovať. Potom nastavili mechanizmus doručovania cez Google Play, aby mohli na diaľku zaviesť aktualizácie týchto kľúčových komponentov bez toho, aby museli čakať, kým OEM sami aplikujú opravy. Mainline výrazne zlepšil, ako rýchlo zariadenia prijímajú aktualizované verzie dôležitých komponentov operačného systému, čím sa zlepšila bezpečnosť ekosystému Android ako celku.

Pokiaľ však ide o Treble, linuxové jadro by sa reálne nemalo spájať s kódom dodávateľa s uzavretým zdrojom. Todd Kjos o tohtoročná konferencia Linux Plumbers Conference v minulosti vysvetlila ťažkosti, s ktorými sa stretávame, pokiaľ ide o fragmentáciu v systéme Android, a mnohé z nich sa teraz sústreďujú okolo linuxového jadra, ktoré výrobcovia OEM dodávajú so svojimi zariadeniami. Pre kontext Google rozdelí každé jadro hlavného radu Linuxu na „Android Common Kernel“ (ACK), ktorá podrobne sleduje hlavné vydanie, ale pridáva niekoľko opráv špecifických pre Android. Dodávatelia SoC ako Qualcomm, MediaTek a Samsung potom vidia že jadro pre každý SoC, ktorý vyrobia. OEM potom vezmú toto jadro špecifické pre SoC a pridajú ďalšie záplaty na implementáciu podpory pre konkrétny hardvér, ktorý chcú dodať.

Vyššie uvedený diagram ukazuje, ako jadro zariadenia prechádza niekoľkými vrstvami zmien, ktoré ho abstrahujú ďaleko od jadra Linux LTS. Aby sme to zjednodušili, začneme jadrom Linuxu a s niekoľkými zmenami sa zlúči do spoločného jadra systému Android. Odtiaľ sa Android Common Kernel zlúči do jadra dodávateľa (Qualcomm, MediaTek atď.) s vlastnými úpravami a zmenami. Nakoniec sa jadro dodávateľa zlúči do jadra OEM špecifického pre zariadenie. V tejto fáze je jadro akéhokoľvek zariadenia veľmi vzdialené od jadra Linux LTS, s ktorým začalo.

Výsledkom všetkých týchto forkov je, že až 50 % kódu spusteného na zariadení so systémom Android je mimo stromu, čo znamená, že nepochádza z upstream bežných jadier Linuxu alebo AOSP. Vďaka tomu je neuveriteľne ťažké (nehovoriac o časovo náročnom a nákladnom) zlúčiť zmeny v upstreame. Pre výrobcov OEM neexistuje žiadna motivácia, aby tak urobili, ale tento postup môže byť škodlivý pre bezpečnosť zariadenia. To je tiež dôvod, prečo je veľa zariadení so systémom Android ponechaných na starších vydaniach jadra LTS, čo má za následok, že zariadenia strácajú prístup k novým funkciám jadra Linuxu.

Android je fragmentovaný a Google to vie

Google veľmi dobre vie, že ide o problém, a dokonca má sekciu s názvom „Náklady na fragmentáciu“ v dokumentácii pre vývojárov systému Android. Google to hovorí „väčšina vlajkových zariadení sa dodáva s verziou jadra, ktorá je už najmenej 18 mesiacov stará“. Ešte horšie je, že to hovorí aj Google "Android 10 podporuje jadrá 3.18, 4.4, 4.9, 4.14 a 4.19, ktoré v niektorých prípadoch neboli vylepšené o nové funkcie od Androidu 8 v roku 2017." To sťažuje pridávanie funkcií, ktoré vyžadujú nové verzie jadra Linuxu. Linuxové jadro 3.18 bolo spustené v decembri 2014, keď bol Android 5.0 Lollipop najnovšou verziou Androidu. To je jednoznačne problém a môže to brzdiť platformu.

Napríklad Code Aurora Forum alebo skrátene CAF je hostiteľom zdrojového kódu pre rôzne SoC Qualcomm Snapdragon. Qualcomm ako SoC dodávateľ distribuuje rozvetvenú verziu linuxového jadra výrobcom OEM/ODM a tieto spoločnosti potom pridávajú zmeny špecifické pre zariadenie zariadení. Práve to pridáva niekoľko vrstiev fragmentácie. Okrem toho Qualcomm robí zmeny v rámci AOSP s cieľom optimalizovať Android pre každú z mobilných platforiem Snapdragon spoločnosti. Qualcomm súkromne distribuuje svoje upravené linuxové jadro, rámec AOSP a ďalšie softvérové ​​nástroje svojim partnerom ako súčasť balíka podpory rady alebo BSP. CAF je miesto, kde Qualcomm verejne publikuje tieto zmeny jadra Linuxu a zmeny rámca AOSP.

Toto vydanie CAF môže byť užitočné pre vývojárov vlastných ROM, ktorí ho chcú použiť ako východiskový bod namiesto čistého AOSP, a preto niekedy vidíte ROM „založené na modeli CAF“ na našich fórach. Pamätáte si na Snapdragon 625, ktorý roky poháňal toľko smartfónov strednej triedy? To sa začalo s jadrom Linux 3.18 a až ku koncu roka 2018 (dva roky po spustení čipovej sady) spoločnosť Qualcomm aktualizovala zdroje jadra a zverejnila ich na CAF pre msm8953 (názov čipovej sady Snapdragon 625), ktorý prináša podporu pre Linux Kernel 4.9. Problém je, že väčšina OEM nebude aktualizovať telefóny na túto novú verziu jadra Linuxu, najmä nie telefóny strednej triedy dva roky po tom, ako bol čip prepustený. Je pravda, že je veľmi zriedkavé, aby sa takáto veľká aktualizácia jadra vôbec stala, ale ide o to, že má stalo, takže to nie je len nemožný scenár.

Celkovo vzaté, súčasná fragmentácia v Androide je zľahka povedané neporiadok. Najnovšie pokusy Google napraviť túto fragmentáciu prichádzajú vo forme Generic Kernel Image alebo GKI.

Predstavujeme Generic Kernel Image

S cieľom vyriešiť túto fragmentáciu spoločnosť Google pracovala na generickom obrázku jadra systému Android (GKI). Toto je v podstate jadro zostavené priamo z vetvy ACK. GKI izoluje prispôsobenia dodávateľa SoC a OEM modulom zásuvných modulov, čím eliminuje kód mimo stromu a umožňuje spoločnosti Google posielať aktualizácie jadra priamo koncovému používateľovi. Spoločnosť Google už viac ako rok pracuje na spôsobe poskytovania aktualizácií GKI prostredníctvom Obchodu Play, pomocou hlavného modulu.

Výsledkom je, že zariadenia spúšťané s Androidom 12 s jadrom Linuxu 5.10.43 alebo vyšším musia vykonať jeden z nasledujúcich krokov: podľa Mishaala Rahmana.

• Nasaďte spúšťací obraz podpísaný spoločnosťou Google

ALEBO

• Nasaďte zavádzací obraz s jadrom, ktoré exportuje KMI (Kernel Module Interface), ktoré je podmnožinou KMI exportovaného GKI, exportuje používateľské rozhranie API, ktoré je nadmnožinou UAPI vystaveného GKI, a podporuje všetky funkcie zodpovedajúceho GKI verzia

Dodávatelia môžu vytvárať moduly, ktoré sa zapájajú do GKI, ale myšlienkou GKI je, že Google preberá bremeno zodpovednosti za spracovanie zmien jadra. Rozhranie modulu jadra (alebo KMI, viac o tom v neskorších častiach článku) je efektívne tam, kde sa očakáva, že kód mimo stromu pôjde.

Séria Google Pixel 6 bola uvedená na trh s Androidom 12 a dodáva sa s jadrom Linuxu 5.10 a je to prvý telefón, ktorý sa dodáva s GKI. Pretože Google by mohol potenciálne aktualizovať jadro prostredníctvom Obchodu Play, môžeme dokonca vidieť časté aktualizácie jadra, keďže aktualizácie jadra LTS sa zvyčajne vydávajú týždenne. V každom prípade je to oveľa lepší systém ako v súčasnosti ťažkopádny spôsob aktualizácie prostredníctvom OTA, hoci to znamená, že je neodmysliteľne spojený s rámcom GMS.

Google jednoducho definuje GKI takto:

• Je zostavený zo zdrojov ACK.
• Je to binárny systém s jedným jadrom plus pridružené načítateľné moduly na architektúru a vydanie LTS (v súčasnosti iba arm64 pre android11-5.4 a android12-5.4).
• Testuje sa so všetkými vydaniami platformy Android, ktoré sú podporované pre súvisiace ACK. Počas životnosti verzie jadra GKI neexistuje žiadna podpora funkcie
• Vodičom v rámci daného LTS vystavuje stabilné KMI.
• Neobsahuje SoC ani kód špecifický pre dosku.

Google dokonca chce byť do roku 2023 v pozícii, v ktorej bude môcť zaujať vývojový model „najskôr upstream“. Pomôže to Googlu zabezpečiť, aby sa nový kód dostal na prvé miesto v hlavnom linuxovom jadre, čím sa zníži „technický dlh“ nahromadený mimo stromového kódu na zariadeniach so systémom Android.

Rozhranie modulu jadra (KMI)

Kernel Module Interface, alebo KMI, je súčasťou riešenia Google na prebiehajúcu fragmentáciu v systéme Android. V podstate sa SoC a podpora dosky už nenachádzajú v jadre jadra a namiesto toho sa presúvajú do načítateľných modulov. Jadro aj moduly sa potom môžu aktualizovať nezávisle, pretože moduly sa aktualizujú v /lib/modules. Samotné GKI má byť čo najčistejšie a najvšeobecnejšie, čo je umožnené presunutím kódu, ktorý je teraz mimo strom, do samostatných modulov.

Ako Ted Kjos vysvetlené na tohtoročnej konferencie Linux Plumbers Conference, „veľkým viacročným úsilím je dostať všetok hardvérovo špecifický kód z generického jadra do modulov dodávateľov. Musíme mať stabilné rozhranie medzi týmito modulmi dodávateľov a generickým jadrom, aby sa mohli odosielať asynchrónne." GKI 1.0 je v podstate "test zhody".

V skutočnosti kompatibilita GKI znamená, že zariadenie prejde testami VTS a CTS-on-GSI+GKI s generickým obrazom systému (GSI). a jadro GKI nainštalované flashovaním zavádzacieho obrazu GKI do zavádzacieho oddielu a obrazu systému GSI v systéme oddiel. Vendor Test Suite alebo VTS je automatický test, ktorým musia prejsť všetky zariadenia, aby boli považované za kompatibilné s Project Treble. Na prístup k súprave aplikácií Google sa vyžaduje súprava na testovanie kompatibility alebo CTS.

Zariadenia sa môžu dodávať s iným produktovým jadrom a môžu používať načítateľné moduly, ktoré GKI neposkytuje. Avšak jadrá produktu aj GKI musia načítať moduly z rovnakých vendor_boot a vendor partícií. Preto sa vyžaduje, aby všetky jadrá produktov mali rovnaké rozhranie binárneho modulu jadra (KMI).

Vyššie uvedený diagram ukazuje, čo Google chce a vysvetľuje, ako to chce dosiahnuť. Moduly Generic Kernel a GKI budú súčasťou AOSP a GKI môže komunikovať s rámcom Android a hardvérovou abstraktnou vrstvou (HAL), ktorú môže dodávateľ implementovať. Špecifický proprietárny kód, ktorý predajca požaduje v jadre (napríklad ovládače fotoaparátu), sa namiesto toho vloží do modulu dodávateľa, ktorý sa stane rozšírením GKI prostredníctvom KMI.

Ako môže GKI pomôcť vyriešiť problém fragmentácie systému Android

Google vynaložil veľa práce na zefektívnenie procesu vývoja smartfónov. Každý OEM chce svoju vlastnú identitu značky a každý OEM chce mať možnosť vlastniť svoje zariadenia. Na rozdiel od programu Android One môžu byť smartfóny so systémom Android takmer čímkoľvek, čo chcú, pokiaľ dodržiavajú súbor pravidiel, ktoré spoločnosť Google stanovuje na získanie licencie GMS. V minulosti však Google neurobil veľa pre to, aby kraľoval vo vývoji zariadení so systémom Android zmeny, ako napríklad Project Treble, Mainline a teraz je GKI v systéme Android oveľa novší histórie.

Ale pomôže to? Malo by to stačiť, hoci pravdepodobne pôjde o viacročnú záležitosť, ktorá neskôr prinesie viditeľné ovocie. Bude sa to týkať iba zariadení so systémom Android 12, čo znamená, že v nasledujúcich rokoch uvidíme zariadenia, ktoré nebudú mať GKI. To bola tiež kritika Project Treble, keď to bolo oznámené, aj keď to samozrejme podporujú všetky zariadenia, ktoré sú dnes uvedené na trh. Tieto veci si vyžadujú čas, a keďže Google pomaly preberá vládu nad Androidom, proces vývoja je pre všetkých OEM v ekosystém Android, aj keď niektorí z nich by si radšej ponechali plnú kontrolu nad jadrom Linuxu, ktoré sa používa v systéme Android smartfóny.