A Google általános kernelképe a következő lépés az Android töredezettségi problémájának megoldása felé

A Google évek óta dolgozik az Android töredezettségének csökkentésén, bár ennek részben az Android velejáró természete, valamint a választás és a szabadság kétélű kardja van. Számtalan OEM tevékenykedik a térben, és mindegyikük saját maga akarja módosítani a saját eszközeit. A probléma tehát az, hogy úgy tűnik, hogy az Android operációs rendszer frissítései lassan terjednek ki, de a Google valójában nem tehet sokat azért, hogy az OEM-eket eszközeik frissítésére kényszerítse. Mint ilyen, a következő legjobb dolog, amit a Google tehet, hogy a frissítési folyamatot a lehető legegyszerűbbé és súrlódásmentesebbé teszi.

Az Android frissítési fájdalmának enyhítése

A Google fejlesztési terhek csökkentését célzó hosszú távú projektjében az első jelentős kezdeményezés az volt Projekt Treble. Az Android 8.0 Oreo mellett 2017-ben bejelentett Project Treble modularizálta az Androidot azáltal, hogy elválasztotta az operációs rendszer keretrendszerét a gyártói megvalósítástól (HAL-ok és az eszközspecifikus Linux kernelfork). Ez megkönnyítette az Android OEM-ek számára, hogy a legújabb AOSP-keretrendszerre alapozzák operációs rendszereiket, mivel a gyártók frissített kódja nélkül tudták elindítani a legújabb verziót. Ennek eredményeként az OEM-ek a korábbinál gyorsabban elkészíthették egyéni Android-forgácsaikat, és ezen túlmenően gyorsabban terjeszthetik ki a főbb operációs rendszer-frissítéseket.

A Google terveinek következő lépése az volt, hogy racionalizálja a frissítések kézbesítését a legfontosabb Android-komponensekhez. A Google elnevezte ezt a kezdeményezést Projekt fővonal amikor 2019-ben bemutatta az Android 10 mellett. A Google lényegében átvette az irányítást az operációs rendszer kulcsfontosságú összetevői felett, és megtiltotta az OEM-eknek, hogy módosítsák azokat. Ezután beállítottak egy kézbesítési mechanizmust a Google Playen keresztül, hogy távolról telepíthessék ezekre a kulcsfontosságú összetevőkre vonatkozó frissítéseket anélkül, hogy meg kellene várniuk, míg az OEM-ek maguk telepítik a javításokat. A Mainline nagymértékben javította, hogy az eszközök milyen gyorsan kapják meg a fontos operációs rendszer-összetevők frissített verzióit, ezzel pedig javítva az Android ökoszisztéma egészének biztonságát.

Ami azonban a Treble-t illeti, a Linux kernelt nem szabad egy zárt forráskódú gyártói kóddal összerakni. Todd Kjos at az idei Linux vízvezeték-szerelők konferenciája korábban elmagyarázta azokat a nehézségeket, amelyekkel szembe kell nézni, amikor az Androidon a töredezettségről van szó, és ezek nagy része manapság a Linux kernel köré összpontosul, amelyet az OEM-ek az eszközeikkel együtt szállítanak. A kontextus kedvéért a Google minden fő Linux kernelt egy „Android közös kernel” (ACK) ág, amely szorosan követi a fővonali kiadást, de hozzáad néhány Android-specifikus javítást. Az olyan SoC-szállítók, mint a Qualcomm, a MediaTek és a Samsung, aztán elágaznak hogy kernel minden általuk készített SoC-hez. Az OEM-ek ezután veszik az adott SoC-specifikus kernelt, és további javításokat adnak hozzá, hogy megvalósítsák a szállítani kívánt hardver támogatását.

A fenti diagram azt mutatja, hogy az eszköz kernelje hogyan megy keresztül több olyan változáson, amelyek a Linux LTS kerneltől távol absztrahálják. Az egyszerűsítés érdekében a Linux Kernellel kezdjük, és néhány változtatással beolvad az Android közös kernelbe. Innentől kezdve az Android Common Kernel beolvad egy gyártói kernelbe (Qualcomm, MediaTek stb.), saját módosításokkal és változtatásokkal. Végül a gyártó kernelt egyesítik az OEM készülék-specifikus kernelébe. Ebben a szakaszban bármely eszköz kernelje messze van attól a Linux LTS kerneltől, amellyel indult.

Az összes ilyen elágazás eredményeképpen az Android-eszközökön futó kódok 50%-a fán kívüli kód, ami azt jelenti, hogy nem az upstream Linux vagy AOSP általános kerneleiből származik. Ez hihetetlenül megnehezíti (nem beszélve időigényes és költséges) az upstream változtatások összevonását. Az OEM-gyártókat ez nem ösztönzi, de ez a gyakorlat káros lehet az eszközök biztonságára nézve. Ez az oka annak is, hogy sok Android-eszköz maradt a régebbi LTS-kernel-kiadásokon, aminek az a mellékhatása, hogy az eszközök elveszítik az új Linux-kernel-funkciókhoz való hozzáférést.

Az Android töredezett, és a Google tudja ezt

A Google jól tudja, hogy ez probléma, sőt van egy "A töredezettség költségei" az Android fejlesztői dokumentációjában. A Google azt mondja "a legtöbb zászlóshajó eszközt olyan kernelverzióval szállítják, amely már legalább 18 hónapos". Még rosszabb, hogy a Google is ezt mondja "Az Android 10 támogatja a 3.18-as, 4.4-es, 4.9-es, 4.14-es és 4.19-es kerneleket, amelyek bizonyos esetekben nem lettek új funkciókkal bővítve a 2017-es Android 8 óta." Ez megnehezíti az új Linux kernelverziókat igénylő funkciók hozzáadását. A 3.18-as Linux kernel 2014 decemberében jelent meg, még akkor, amikor az Android 5.0 Lollipop volt az Android legújabb verziója. Ez egyértelműen probléma, és visszatarthatja a platformot.

Például a Code Aurora Forum vagy röviden CAF különféle Qualcomm Snapdragon SoC-k forráskódját tárolja. Qualcomm, mint SoC szállító, elosztja a Linux kernel villás változatát az OEM-eknek/ODM-eknek, majd ezek a cégek eszközspecifikus változtatásokat adnak hozzá a szállításhoz. eszközöket. Ez az, ami több réteg töredezettséget ad hozzá. Ezenkívül a Qualcomm módosítja az AOSP-keretrendszert, hogy optimalizálja az Androidot a vállalat minden Snapdragon mobilplatformjára. A Qualcomm a módosított Linux kernelt, AOSP-kernelt és egyéb szoftvereszközöket magántulajdonban terjeszti partnerei számára a Board Support Package, vagyis a BSP részeként. A CAF az a hely, ahol a Qualcomm nyilvánosan közzéteszi ezeket a Linux-kernel-módosításokat és az AOSP-kernelmódosításokat.

Ez a CAF-kiadás hasznos lehet azoknak az egyéni ROM-fejlesztőknek, akik kiindulópontként szeretnék használni, nem pedig tiszta AOSP-ként, ezért néha látni „CAF-alapú” ROM-ok fórumainkon. Emlékszel a Snapdragon 625-re, amelyről úgy tűnt, hogy éveken át annyi középkategóriás okostelefont hajtott? Ez a Linux Kernel 3.18-as verziójával indult, és csak 2018 vége felé (két évvel a chipkészlet megjelenése után) frissítette a Qualcomm a kernelforrásokat, és tette közzé őket CAF az msm8953-hoz (a Snapdragon 625 chipkészlet neve), amely támogatja a Linux Kernel 4.9-et. A probléma az, hogy a legtöbb OEM nem frissíti a telefonokat erre az új Linux kernel verzióra, különösen nem a középkategóriás telefonokat két évvel a chip megjelenése után kiadták. Igaz, nagyon ritka, hogy egy ilyen nagy kernelfrissítés eleve megtörténjen, de a lényeg az, hogy van megtörtént, tehát ez nem csak egy lehetetlen forgatókönyv.

Összességében elmondható, hogy az Android jelenlegi töredezettsége finoman szólva káosz. A Google legújabb próbálkozásai ennek a töredezettségnek a kijavítására a Generic Kernel Image vagy a GKI formájában jelentkeznek.

Az általános kernelkép bemutatása

A töredezettség kezelése érdekében a Google az Android Generic Kernel Image-en (GKI) dolgozott. Ez lényegében egy kernel, amelyet egyenesen egy ACK ágból fordítanak le. A GKI elkülöníti az SoC-szállító és az OEM testreszabásait a beépülő modulokhoz, így kiküszöböli a fán kívüli kódot, és lehetővé teszi a Google számára, hogy a kernelfrissítéseket közvetlenül a végfelhasználóhoz küldje. A Google több mint egy éve dolgozik azon, hogy a GKI-frissítéseket a Play Áruházban szállíthassa, fővonali modul használatával.

Ennek eredményeként az Android 12-vel induló, 5.10.43-as vagy újabb Linux kernelt futtató eszközöknek meg kell tenniük a következők egyikét: Mishaal Rahman szerint.

• Helyezzen üzembe egy Google által aláírt rendszerindító képet

VAGY

• Telepítsen egy rendszerindító lemezképet olyan kernellel, amely egy KMI-t (Kernel Module Interface) exportál, amely a GKI által exportált KMI részhalmaza, egy felhasználói tér API-t exportál, amely a GKI által közzétett UAPI szuperkészlete, és támogatja a megfelelő GKI összes funkcióját változat

A gyártók létrehozhatnak olyan modulokat, amelyek csatlakoztathatók a GKI-hez, de a GKI ötlete az, hogy a Google magára vállalja a kernelváltozások kezelésének felelősségét. A Kernel Module Interface (vagy KMI, erről bővebben a cikk későbbi részeiben) gyakorlatilag az a hely, ahol a fán kívüli kódot várják.

A Google Pixel 6 sorozat Android 12-vel indult, és 5.10-es Linux kernellel szállítják, és ez az első telefon, amelyet GKI-vel szállítanak. Mivel a Google esetleg frissítheti a kernelt a Play Áruházban, akár gyakori kernelfrissítéseket is láthatunk, mivel az LTS kernelfrissítések általában hetente jelennek meg. Akárhogy is, ez egy sokkal jobb rendszer, mint az OTA-n keresztüli frissítés jelenleg nehézkes módja, bár ez azt jelenti, hogy eredendően kapcsolódik a GMS keretrendszerhez.

A Google egyszerűen a következőképpen határozza meg a GKI-t:

• Az ACK forrásokból épül fel.
• Ez egy egy kernelből álló bináris plusz kapcsolódó betölthető modulok architektúránként, LTS kiadásonként (jelenleg csak arm64 android11-5.4 és android12-5.4).
• Az összes Android Platform-kiadáson tesztelve van, amely támogatott a kapcsolódó ACK-hez. A GKI kernelverziójának élettartama alatt a funkciók nem szűnnek meg
• Stabil KMI-t tesz elérhetővé a járművezetők számára egy adott LTS-en belül.
• Nem tartalmaz SoC vagy kártyaspecifikus kódot.

A Google még 2023-ra is olyan pozícióba akar kerülni, hogy „először az upstream” fejlesztési modellt alkalmazza. Ez segíteni fogja a Google-t abban, hogy az új kód elsőként kerüljön be a fő Linux kernelbe, csökkentve ezzel az Android-eszközökön felhalmozott „műszaki adósságokat”.

A Kernel Module Interface (KMI)

A Kernel Module Interface (KMI) a Google megoldásának része az Android folyamatos töredezettségére. Lényegében az SoC és az alaplap támogatása már nem a mag kernelben található, hanem betölthető modulokba kerül. Ekkor a kernel és a modulok egymástól függetlenül is frissíthetők, ahogy a modulok frissülnek /lib/modules. Magának a GKI-nek a lehető legtisztábbnak és legáltalánosabbnak kell lennie, amit a ma már fán kívüli kód külön modulokba való kirakása tesz lehetővé.

mint Ted Kjos magyarázta at Az idei Linux vízvezeték-szerelők konferenciáján "a nagy, több éves erőfeszítés az, hogy az összes hardver-specifikus kódot kivonják az általános kernelből és a gyártói modulokba. Stabil interfésszel kell rendelkeznünk ezen gyártói modulok és az általános kernel között, hogy aszinkron módon szállíthassák." A GKI 1.0 lényegében egy "megfelelőségi teszt".

Valójában a GKI-kompatibilitás azt jelenti, hogy az eszköz megfelel a VTS és a CTS-on-GSI+GKI teszteknek a Generic System Image (GSI) segítségével. és a GKI rendszermag telepítése a GKI rendszerindító lemezképnek a rendszerindító partícióba való flashelésével és a rendszerben lévő GSI rendszerképpel partíció. A Vendor Test Suite vagy a VTS egy automatizált teszt, amelyen minden eszköznek át kell mennie ahhoz, hogy kompatibilis legyen a Project Treble-lel. A kompatibilitási tesztcsomag vagy CTS szükséges a Google alkalmazáscsomagjának eléréséhez.

Az eszközök más termékmaggal is szállíthatók, és olyan betölthető modulokat is használhatnak, amelyeket a GKI nem biztosít. Mindazonáltal mind a terméknek, mind a GKI kernelnek ugyanabból a vendor_boot és szállítói partícióból kell betöltenie a modulokat. Ezért minden termékmagnak ugyanazzal a bináris kernelmodul interfésszel (KMI) kell rendelkeznie.

A fenti diagram azt mutatja, amit a Google akar megtenni, és elmagyarázza, hogyan kívánja ezt elérni. A Generic Kernel és a GKI modulok az AOSP részei lesznek, és a GKI kommunikálhat az Android keretrendszerrel és a hardverabsztrakciós réteggel (HAL), amelyet a gyártó megvalósíthat. A gyártó által a kernelbe beszerelt sajátos kód (például kamera-illesztőprogramok) ehelyett egy szállítói modulba kerül, amely a KMI-n keresztül a GKI kiterjesztése lesz.

Hogyan segíthet a GKI megoldani az Android töredezettségi problémáját?

A Google sok munkát fektetett az okostelefonok fejlesztési folyamatának egyszerűsítésére. Minden OEM szeretne saját márkaidentitást, és minden OEM szeretne birtokolni eszközeit. Az Android One programmal ellentétben az Android okostelefonok nagyjából olyanok lehetnek, amilyenek akarnak, feltéve, hogy betartják azokat a szabályokat, amelyeket a Google a GMS-licenc megszerzése érdekében határoz meg. A múltban azonban a Google nem sokat tett azért, hogy uralkodjon az Android készülékek fejlesztésében változások, mint például a Project Treble, a Mainline, és most a GKI sokkal frissebb az Androidban történelem.

De vajon segít? Meg kell tennie, bár valószínűleg több éves ügyről van szó, amely később látható gyümölcsöt hoz. Ez csak az Android 12-vel induló eszközökre vonatkozik, vagyis évekig látni fogunk olyan eszközöket, amelyekben nem lesz GKI. Ez is a Project Treble kritikája volt, amikor bejelentették, bár nyilvánvalóan minden manapság piacra dobott eszköz támogatja ezt. Ezekhez a dolgokhoz idő kell, és ahogy a Google lassan az Androidon uralkodik, a fejlesztési folyamat az összes OEM-nél leegyszerűsödik. az Android ökoszisztéma, még akkor is, ha némelyikük inkább megtartja a teljes irányítást az Androidon használt Linux kernel felett okostelefonok.