Google'i üldine kerneli kujutis on järgmine samm Androidi killustatuse probleemi lahendamise suunas

Google on aastaid töötanud Androidi killustatuse vähendamise nimel, kuigi osa selle põhjuseks on Androidi loomupärane olemus ning valiku ja vabaduse kahe teraga mõõk. Ruumis tegutseb lugematu arv originaalseadmete tootjaid ja kõik nad soovivad oma seadmete jaoks ise muudatusi teha. Probleem on siis selles, et tundub, et Android OS-i värskendused levivad aeglaselt, kuid Google ei saa tegelikult palju teha, et sundida originaalseadmete tootjaid oma seadmeid värskendama. Sellisena on parim, mida Google teha saab, muuta värskendusprotsess võimalikult lihtsaks ja hõõrdumatuks.

Androidi värskendamise valu leevendamine

Esimene suurem algatus Google’i pikaajalises arenduskoormuse vähendamise projektis oli Projekt Treble. 2017. aastal koos Android 8.0 Oreoga välja kuulutatud Project Treble modulariseeris Androidi, eraldades OS-i raamistiku tarnija juurutusest (HAL-id ja seadmespetsiifiline Linuxi kerneli kahvel). See hõlbustas Androidi originaalseadmete tootjatel oma OS-i uusimale AOSP-raamistikule ümber paigutada, kuna nad said käivitada uusima versiooni ilma tarnijatelt värskendatud koodita. Selle tulemusel saaksid originaalseadmete tootjad oma kohandatud Androidi kahvlid varem valmis teha ja suuremad OS-i värskendused kiiremini kasutusele võtta.

Järgmine samm Google'i plaanides oli Androidi peamiste komponentide värskenduste edastamise tõhustamine. Google nimetas seda algatust Projekti põhiliin kui ta tutvustas seda 2019. aastal koos Android 10-ga. Google võttis sisuliselt kontrolli OS-i peamiste komponentide üle ja keelas originaalseadmete tootjatel neid muuta. Seejärel seadistasid nad Google Play kaudu tarnemehhanismi, et saaksid nende põhikomponentide värskendusi kaugjuhtimisega juurutada, ilma et peaksid ootama, kuni originaalseadmete tootjad paigad ise rakendavad. Mainline parandas oluliselt seda, kui kiiresti seadmed saavad oluliste OS-i komponentide värskendatud versioone, mis omakorda parandas Androidi ökosüsteemi kui terviku turvalisust.

Mis puutub Treble'i, siis tegelikkuses ei tohiks Linuxi kernel olla suletud lähtekoodiga müüja koodiga. Todd Kjos kl selle aasta Linuxi torulukkseppade konverentsil on varem selgitanud Androidi killustatusega seotud raskusi ja suur osa sellest keskendub nüüd Linuxi tuumale, mida originaalseadmete tootjad oma seadmetega tarnivad. Konteksti jaoks ühendab Google iga põhiliini Linuxi kerneli "Androidi ühine kernel” (ACK) haru, mis jälgib täpselt põhiliini väljalaset, kuid lisab mõned Android-spetsiifilised paigad. SoC müüjad nagu Qualcomm, MediaTek ja Samsung hargnevad seejärel et kernel iga nende tehtud SoC jaoks. Seejärel võtavad originaalseadmete tootjad selle SoC-spetsiifilise tuuma ja lisavad täiendavaid plaastreid, et rakendada konkreetse riistvara tuge, mida nad soovivad tarnida.

Ülaltoodud diagramm näitab, kuidas seadme tuum läbib mitu muudatuste kihti, mis eraldavad selle Linuxi LTS-i tuumast kaugel. Selle lihtsustamiseks alustame Linuxi tuumaga ja see liidetakse mõne muudatusega Androidi ühisesse kerneli. Sealt alates liidetakse Android Common Kernel müüja tuumaks (Qualcomm, MediaTek jne) koos oma muudatuste ja muudatustega. Lõpuks liidetakse tarnija tuum OEM-i seadmepõhiseks tuumaks. Selleks etapiks on mis tahes seadme tuum kaugel Linuxi LTS-i tuumast, millega see algas.

Kõigi nende kahvlite tulemusena on kuni 50% Android-seadmes töötavast koodist puust väljas kood, mis tähendab, et see ei pärine ülesvoolu Linuxi või AOSP tavalistest tuumadest. See muudab eelnevate muudatuste ühendamise uskumatult keeruliseks (rääkimata sellest, et see on aeganõudev ja kulukas). Originaalseadmete tootjatel pole selleks stiimulit, kuid see tava võib kahjustada seadme turvalisust. See on ka põhjus, miks paljud Android-seadmed jäetakse vanematele LTS-i kerneli väljaannetele, mille kõrvalmõju on see, et seadmed kaotavad juurdepääsu uutele Linuxi kerneli funktsioonidele.

Android on killustatud ja Google teab seda

Google teab väga hästi, et see on probleem, ja tal on isegi jaotis nimega "Killustumise kulud" Androidi arendaja dokumentatsioonis. Google ütleb seda "enamik juhtseadmeid tarnitakse kerneli versiooniga, mis on juba vähemalt 18 kuud vana". Veelgi hullem, seda ütleb ka Google "Android 10 toetab 3.18, 4.4, 4.9, 4.14 ja 4.19 tuumasid, mida mõnel juhul pole pärast Android 8 2017. aastal uute funktsioonidega täiustatud." See muudab uute Linuxi kerneli versioonide jaoks vajalike funktsioonide lisamise keeruliseks. Linuxi kernel 3.18 käivitati 2014. aasta detsembris, kui Android 5.0 Lollipop oli Androidi uusim versioon. See on ilmselgelt probleem ja võib platvormi tagasi hoida.

Näiteks Code Aurora Forum ehk lühidalt CAF majutab erinevate Qualcomm Snapdragon SoC-de lähtekoodi. Qualcomm kui SoC tarnija, levitab OEM-idele/ODM-idele Linuxi kerneli kahvelversiooni ja need ettevõtted lisavad seejärel tarnimisel seadmepõhiseid muudatusi seadmeid. See lisab mitu kihti killustatust. Lisaks teeb Qualcomm muudatusi AOSP raamistikus, et optimeerida Androidi iga ettevõtte Snapdragoni mobiiliplatvormi jaoks. Qualcomm levitab oma muudetud Linuxi kernelit, AOSP raamistikku ja muid tarkvaratööriistu oma partneritele privaatselt juhatuse tugipaketi ehk BSP osana. CAF on koht, kus Qualcomm avaldab avalikult need Linuxi tuuma muudatused ja AOSP raamistiku muudatused.

See CAF-i väljalase võib olla kasulik kohandatud ROM-i arendajatele, kes soovivad seda kasutada pigem lähtepunktina kui puhta AOSP-na, mistõttu näete mõnikord "CAF-põhised" ROMid meie foorumites. Kas mäletate Snapdragon 625, mis näis aastaid nii paljudele keskklassi nutitelefonidele toite andvat? See käivitati Linuxi kernel 3.18-ga ja alles 2018. aasta lõpus (kaks aastat pärast kiibistiku käivitamist) värskendas Qualcomm kerneli allikaid ja avaldas need CAF msm8953 jaoks (Snapdragon 625 kiibistiku nimi), mis toetab Linuxi tuuma 4.9. Probleem on selles, et enamik originaalseadmete tootjaid ei värskenda telefone sellele uuele Linuxi kerneli versioonile, eriti mitte keskklassi telefone kaks aastat pärast kiibi kasutuselevõttu vabastatud. Tõsi, see on väga haruldane, et selline suur kerneli värskendus üldse juhtub, kuid asi on selles, et on juhtus, nii et see pole lihtsalt võimatu stsenaarium.

Kokkuvõttes on praegune Androidi killustatus kergelt öeldes jama. Google'i viimased katsed seda killustumist parandada on üldise kerneli kujutise ehk GKI kujul.

Tutvustame üldist tuumapilti

Selle killustatuse lahendamiseks töötas Google Androidi üldise kerneli kujutise (GKI) kallal. See on sisuliselt otse ACK-i harust kompileeritud kernel. GKI isoleerib SoC tarnija ja OEM-i kohandused pistikprogrammide moodulitest, välistades puuvälise koodi ja võimaldades Google'il saata kerneli värskendused otse lõppkasutajale. Google on üle aasta töötanud selle nimel, et pakkuda Play poe kaudu GKI värskendusi, põhiliini mooduli abil.

Seetõttu peavad seadmed, mis käivituvad operatsioonisüsteemiga Android 12 ja mis käitavad Linuxi kerneli versiooni 5.10.43 või uuemat versiooni, tegema ühte järgmistest: Mishaal Rahmani järgi.

• Juurutage Google'i allkirjastatud alglaadimispilt

VÕI

• Juurutage alglaadimiskujutis kerneliga, mis ekspordib KMI-d (Kernel Module Interface), mis on GKI eksporditud KMI alamhulk, ekspordib kasutajaruumi API, mis on GKI avaldatud UAPI superkomplekt ja toetab kõiki vastava GKI funktsioone versioon

Tarnijad saavad luua GKI-ga ühendatavaid mooduleid, kuid GKI idee seisneb selles, et Google võtab tuumamuudatuste haldamise eest vastutuse. Kerneli mooduli liides (või KMI, selle kohta lähemalt artikli hilisemates osades) on tegelikult koht, kus eeldatakse, et puuväline kood läheb.

Google Pixel 6 seeria käivitati koos operatsioonisüsteemiga Android 12 ja tarnitakse koos Linuxi kerneliga 5.10 ning see on esimene telefon, mis tarnitakse koos GKI-ga. Kuna Google võib tuuma uuendada Play poe kaudu, võime näha isegi sagedasi kerneli värskendusi, kuna LTS-i kerneli värskendusi avaldatakse tavaliselt kord nädalas. Mõlemal juhul on see palju parem süsteem kui praegu tülikas OTA kaudu värskendamise meetod, kuigi see tähendab, et see on oma olemuselt seotud GMS-i raamistikuga.

Google defineerib GKI lihtsalt järgmiselt:

• See on üles ehitatud ACK-i allikatest.
• See on ühest tuumast koosnev kahendmoodul ja sellega seotud laaditavad moodulid arhitektuuri ja LTS-i väljalaske kohta (praegu ainult arm64 jaoks android11-5.4 ja android12-5.4).
• Seda on testitud kõigi Androidi platvormi väljalasetega, mida sellega seotud ACK-i jaoks toetatakse. GKI kerneli versiooni eluea jooksul funktsioonid ei katkestata
• See avaldab antud LTS-i draiveritele stabiilse KMI.
• See ei sisalda SoC- ega plaadispetsiifilist koodi.

Google soovib isegi olla 2023. aastaks olukorras, kus ta saab kasutusele võtta "ülesvoolu kõigepealt" arendusmudeli. See aitab Google'il tagada, et uus kood satuks esimesena põhiliini Linuxi kernelisse, vähendades Android-seadmetes kogunenud "tehnilist võlga".

Kerneli mooduli liides (KMI)

Kernel Module Interface ehk KMI on osa Google'i lahendusest Androidi jätkuvale killustatusele. Sisuliselt ei asu SoC ja plaadi tugi enam tuuma tuumas ja need viiakse selle asemel laaditavatesse moodulitesse. Nii tuuma kui ka mooduleid saab siis iseseisvalt värskendada, kuna mooduleid värskendatakse /lib/modules. GKI ise peaks olema võimalikult puhas ja üldine, mis on võimalik tänu sellele, et laaditakse praegu väljas olev kood eraldi moodulitesse.

Nagu Ted Kjos selgitas kl Selle aasta Linuxi torulukkseppade konverentsil "suur mitmeaastane tõuge on saada kogu riistvaraspetsiifiline kood üldisest tuumast välja müüja moodulitesse. Meil peab olema stabiilne liides nende tootjamoodulite ja üldise kerneli vahel, et neid saaks asünkroonselt tarnida." GKI 1.0 on sisuliselt "vastavustest".

Tegelikult tähendab GKI ühilduvus seda, et seade läbib VTS ja CTS-on-GSI+GKI testid üldise süsteemipildiga (GSI) ja GKI kernel, mis installiti, välgutades GKI alglaadimiskujutise alglaadimise partitsiooni ja GSI süsteemi kujutist süsteemis vahesein. Vendor Test Suite ehk VTS on automatiseeritud test, mille kõik seadmed peavad läbima, et neid Project Treble'iga ühilduvaks lugeda. Google'i rakenduste komplektile juurdepääsuks on vajalik ühilduvustesti komplekt ehk CTS.

Seadmeid saab tarnida erineva tootetuumaga ja kasutada laaditavaid mooduleid, mida GKI ei paku. Kuid nii toote kui ka GKI tuumad peavad laadima mooduleid samast vendor_boot ja tarnija partitsioonist. Seetõttu peavad kõik tootetuumad omama sama binaarse kerneli mooduli liidest (KMI).

Ülaltoodud diagramm näitab, mida Google tahab teha, ja selgitab, kuidas ta kavatseb selleni jõuda. Generic Kernel ja GKI moodulid on osa AOSP-st ning GKI saab suhelda Androidi raamistiku ja riistvara abstraktsioonikihiga (HAL), mida müüja võib rakendada. Spetsiifiline patenteeritud kood, mida tarnija kernelisse soovib (nt kaameradraiverid), lükatakse selle asemel tarnija moodulisse, millest saab KMI kaudu GKI laiendus.

Kuidas GKI aitab lahendada Androidi killustatuse probleemi

Google on nutitelefonide arendusprotsessi sujuvamaks muutmiseks palju tööd teinud. Iga originaalseadmete tootja soovib oma kaubamärgi identiteeti ja iga originaalseadmete tootja soovib omada oma seadmeid. Erinevalt Android One'i programmist võivad Android-nutitelefonid olla peaaegu kõik, mida nad soovivad, kui nad järgivad Google'i GMS-litsentsi saamiseks kehtestatud reegleid. Varem pole Google aga Android-seadmete arenduses valitsemise nimel palju teinud muudatused, nagu Project Treble, Mainline ja nüüd on GKI Androidis palju uuem ajalugu.

Aga kas see aitab? Seda peaks tegema, kuigi tõenäoliselt on see mitu aastat kestev afäär, mis kannab hiljem nähtavat vilja. See kehtib ainult seadmete kohta, mis käivituvad operatsioonisüsteemiga Android 12, mis tähendab, et näeme veel aastaid seadmeid, millel pole GKI-d. See oli ka Project Treble'i kriitika, kui see välja kuulutati, kuigi ilmselgelt toetavad seda kõik tänapäeval käivitatud seadmed. Need asjad võtavad aega ja kuna Google hakkab aeglaselt Androidi valitsema, on arendusprotsess kõigis selles riigis asuvate originaalseadmete tootjate jaoks kergem. Androidi ökosüsteemi, isegi kui mõned neist pigem säilitaksid täieliku kontrolli Androidis kasutatava Linuxi tuuma üle nutitelefonid.