Googlen Generic Kernel Image on seuraava askel Androidin pirstoutumisongelman ratkaisemisessa

Google on työskennellyt Androidin pirstoutumisen vähentämiseksi jo vuosia, vaikka osa tähän on Androidin luontainen luonne ja valinnan ja vapauden kaksiteräinen miekka. Avaruudessa toimii lukemattomia OEM-valmistajia, ja kaikki haluavat tehdä omia muutoksia omiin laitteisiinsa. Ongelmana on sitten se, että näyttää siltä, ​​​​että Android-käyttöjärjestelmän päivitykset julkaistaan ​​hitaasti, mutta Google ei voi tehdä paljoakaan pakottaakseen OEM-valmistajia päivittämään laitteitaan. Sellaisenaan seuraavaksi paras asia, jonka Google voi tehdä, on tehdä päivitysprosessista mahdollisimman helppoa ja kitkatonta.

Helpottaa Android-päivityskipua

Ensimmäinen iso aloite Googlen pitkäjänteisessä hankkeessa kehitystaakan keventämiseksi oli Projekti Treble. Vuonna 2017 Android 8.0 Oreon rinnalla julkistettu Project Treble modularisoi Androidin erottamalla käyttöjärjestelmäkehyksen toimittajan toteutuksesta (HAL: t ja laitekohtainen Linux-ytimen haarukka). Tämä helpotti Android OEM-valmistajien perustaa käyttöjärjestelmänsä uusimman AOSP-kehyksen päälle, koska he pystyivät käynnistämään uusimman version ilman, että tarvitsisivat päivitettyä koodia toimittajilta. Tämän seurauksena OEM-valmistajat saattoivat valmistaa mukautettuja Android-haarukkansa nopeammin kuin ennen, ja laajemmalti ottaa käyttöön suuret käyttöjärjestelmäpäivitykset nopeammin.

Seuraava askel Googlen suunnitelmissa oli virtaviivaistaa päivitysten toimittamista tärkeimpiin Android-komponentteihin. Google kutsui tätä aloitetta Projektin päälinja kun se esitteli sen Android 10:n rinnalla vuonna 2019. Google pohjimmiltaan otti hallintaansa käyttöjärjestelmän tärkeimmät komponentit ja kielsi OEM-valmistajia muuttamasta niitä. Sitten he määrittelivät toimitusmekanismin Google Playn kautta, jotta he voisivat julkaista päivityksiä näihin avainkomponentteihin etäältä ilman, että heidän tarvitsee odottaa, että OEM-valmistajat asentavat korjaukset itse. Mainline paransi huomattavasti sitä, kuinka nopeasti laitteet vastaanottavat päivitetyt versiot tärkeistä käyttöjärjestelmäkomponenteista, mikä puolestaan ​​parantaa koko Android-ekosysteemin turvallisuutta.

Mitä tulee Trebleen, Linux-ydintä ei kuitenkaan realistisesti pitäisi niputtaa suljetun lähdekoodin toimittajakoodiin. Todd Kjos klo tämän vuoden Linux Plumbers Conference on aiemmin selittänyt vaikeudet, joita kohdataan Androidin pirstoutumiseen, ja suuri osa siitä keskittyy nyt Linux-ytimeen, jonka OEM-valmistajat toimittavat laitteidensa mukana. Kontekstia varten Google haaroittelee jokaisen Linux-ytimen "Androidin yhteinen ydin” (ACK) haara, joka seuraa tarkasti pääversiota, mutta lisää muutaman Android-kohtaisen korjaustiedoston. SoC-toimittajat, kuten Qualcomm, MediaTek ja Samsung, haarautuvat sitten että ydin jokaiselle heidän valmistamalleen SoC: lle. OEM-valmistajat ottavat sitten kyseisen SoC-kohtaisen ytimen ja lisäävät lisäkorjauksia toteuttaakseen tuen tietylle laitteistolle, jonka he haluavat toimittaa.

Yllä oleva kaavio näyttää, kuinka laitteen ydin käy läpi useita muutoskerroksia, jotka erottavat sen kaukana Linux LTS-ytimestä. Sen yksinkertaistamiseksi aloitamme Linux-ytimestä, ja se yhdistetään Androidin yhteiseen ytimeen muutamilla muutoksilla. Sieltä Android Common Kernel yhdistetään toimittajan ytimeen (Qualcomm, MediaTek jne.) omilla muokkauksillaan ja muutoksillaan. Lopuksi toimittajan ydin yhdistetään OEM: n laitekohtaiseen ytimeen. Tässä vaiheessa minkä tahansa laitteen ydin on kaukana Linux LTS-ytimestä, jolla se aloitettiin.

Kaikkien näiden haarukoiden seurauksena jopa 50 % Android-laitteen koodista on puun ulkopuolista koodia, mikä tarkoittaa, että se ei ole peräisin ylävirran Linux- tai AOSP: n yleisistä ytimistä. Tämä tekee alkuvaiheen muutosten yhdistämisestä uskomattoman vaikeaa (puhumattakaan aikaa vievästä ja kallista). OEM-valmistajilla ei ole kannustinta tehdä niin, mutta tämä käytäntö voi olla haitallista laitteen turvallisuudelle. Tästä syystä monet Android-laitteet jäävät vanhempiin LTS-ytimen julkaisuihin, minkä sivuvaikutuksena on, että laitteet menettävät pääsyn uusiin Linux-ytimen ominaisuuksiin.

Android on hajanainen, ja Google tietää sen

Google tietää varsin hyvin, että tämä on ongelma, ja sillä on jopa osio nimeltä "Hajanaisuuden kustannukset" Android-kehittäjän dokumentaatiossa. Google sanoo niin "useimmat lippulaivalaitteet toimitetaan ytimen versiolla, joka on jo vähintään 18 kuukautta vanha". Vielä pahempaa, Google sanoo myös tämän "Android 10 tukee 3.18-, 4.4-, 4.9-, 4.14- ja 4.19-ytimiä, joita ei joissain tapauksissa ole parannettu uusilla ominaisuuksilla sitten Android 8:n vuonna 2017." Tämä vaikeuttaa uusia Linux-ytimen versioita vaativien ominaisuuksien lisäämistä. Linux-ydin 3.18 julkaistiin joulukuussa 2014, jolloin Android 5.0 Lollipop oli Androidin uusin versio. Se on selvästi ongelma ja voi jarruttaa alustaa.

Esimerkiksi Code Aurora Forum tai lyhyesti CAF isännöi lähdekoodia useille Qualcomm Snapdragon SoC: ille. Qualcomm, SoC myyjä, jakelee haarukkaversion Linux-ytimestä OEM-/ODM: ille, ja nämä yritykset lisäävät laitekohtaisia ​​muutoksia toimitukseen laitteet. Tämä lisää useita kerroksia pirstoutuneisuutta. Lisäksi Qualcomm tekee muutoksia AOSP-kehykseen optimoidakseen Androidin jokaiselle yrityksen Snapdragon-mobiilialustoille. Qualcomm jakaa yksityisesti muokatun Linux-ytimen, AOSP-kehyksen ja muut ohjelmistotyökalut kumppaneilleen osana Board Support Packagea eli BSP: tä. CAF on paikka, jossa Qualcomm julkaisee nämä Linux-ytimen muutokset ja AOSP-kehyksen muutokset.

Tämä CAF-julkaisu voi olla hyödyllinen mukautetuille ROM-kehittäjille, jotka haluavat käyttää sitä lähtökohtana pelkän AOSP: n sijaan, minkä vuoksi näet joskus "CAF-pohjaiset" ROMit foorumeillamme. Muistatko Snapdragon 625:n, joka näytti tehoavan niin moniin keskitason älypuhelimiin vuosien ajan? Se käynnistettiin Linux Kernel 3.18:lla, ja vasta vuoden 2018 lopulla (kaksi vuotta piirisarjan julkaisun jälkeen) Qualcomm päivitti ytimen lähteet ja julkaisi ne CAF msm8953:lle (Snapdragon 625:n piirisarjan nimi), joka tuo tuen Linux Kernel 4.9:lle. Ongelmana on, että useimmat OEM-valmistajat ei päivitä puhelimia tähän uuteen Linux-ytimen versioon, etenkään keskitason puhelimiin kaksi vuotta sirun valmistumisen jälkeen vapautettu. On tosin hyvin harvinaista, että tällainen suuri ytimen päivitys edes tapahtuu alun perin, mutta pointti on, että se on tapahtui, joten se ei ole vain mahdoton skenaario.

Kaiken kaikkiaan Androidin nykyinen pirstoutuminen on kevyesti sanottuna sotkua. Googlen viimeisimmät yritykset korjata tämä pirstoutuminen ovat yleisen ydinkuvan tai GKI: n muodossa.

Esittelyssä yleinen ydinkuva

Tämän pirstoutumisen korjaamiseksi Google työskenteli Android Generic Kernel Image (GKI) -kuvan parissa. Tämä on pohjimmiltaan suoraan ACK-haarasta käännetty ydin. GKI eristää SoC-toimittajan ja OEM-muokkaukset laajennusmoduuleille, eliminoi puun ulkopuolisen koodin ja sallii Googlen lähettää ytimen päivitykset suoraan loppukäyttäjälle. Google on yli vuoden ajan työskennellyt tapaa toimittaa GKI-päivitykset Play Kaupan kautta, Mainline-moduulin avulla.

Tämän seurauksena laitteiden, jotka käynnistyvät Android 12:lla ja joissa on Linux-ydin 5.10.43 tai uudempi, on tehtävä jokin seuraavista: Mishaal Rahmanin mukaan.

• Ota käyttöön Google-allekirjoitettu käynnistyskuva

TAI

• Ota käyttöön käynnistyskuva ytimellä, joka vie KMI: n (Kernel Module Interface), joka on osa GKI: n viemää KMI: tä, vie käyttäjätilan API: n, joka on GKI: n paljastaman UAPI: n superjoukko ja tukee kaikkia vastaavan GKI: n ominaisuuksia. versio

Toimittajat voivat luoda moduuleja, jotka kytkeytyvät GKI: hen, mutta GKI: n ideana on, että Google ottaa vastuun ytimen muutosten käsittelystä. Ydinmoduulin käyttöliittymä (tai KMI, tästä lisää artikkelin myöhemmissä osissa) on käytännössä se paikka, jossa puun ulkopuolisen koodin odotetaan menevän.

Google Pixel 6 -sarja julkaistiin Android 12:lla, ja sen mukana toimitetaan Linux-ydin 5.10, ja se on ensimmäinen puhelin, jossa on GKI. Koska Google saattaa päivittää ytimen Play Kaupan kautta, saatamme jopa nähdä usein päivityksiä, koska LTS-ytimen päivitykset julkaistaan ​​yleensä viikoittain. Joka tapauksessa se on paljon parempi järjestelmä kuin tällä hetkellä raskas tapa päivittää OTA: n kautta, vaikka tämä tarkoittaakin, että se on luonnostaan ​​sidottu GMS-kehykseen.

Google yksinkertaisesti määrittelee GKI: n seuraavasti:

• Se on rakennettu ACK-lähteistä.
• Se on yhden ytimen binaari ja siihen liittyvät ladattavat moduulit arkkitehtuurikohtaisesti, LTS-julkaisua kohti (tällä hetkellä vain arm64 android11-5.4 ja android12-5.4).
• Se on testattu kaikilla Android Platform -julkaisuilla, joita tuetaan siihen liittyvälle ACK: lle. GKI-ydinversion käyttöiän aikana ominaisuuksia ei ole poistettu
• Se paljastaa vakaan KMI: n tietyn LTS: n kuljettajille.
• Se ei sisällä SoC- tai korttikohtaista koodia.

Google haluaa jopa olla asemassa vuoteen 2023 mennessä, jossa se voi ottaa "alkuvirtaan ensin" kehitysmallin. Tämä auttaa Googlea varmistamaan, että uusi koodi päätyy ensimmäisenä päälinjan Linux-ytimeen, mikä vähentää "teknistä velkaa" Android-laitteissa.

Kernel Module Interface (KMI)

Kernel Module Interface eli KMI on osa Googlen ratkaisua Androidin jatkuvaan pirstoutumiseen. Pohjimmiltaan SoC ja piirilevytuki eivät enää sijaitse ydinytimessä, vaan ne siirretään ladattaviin moduuleihin. Sekä ydin että moduulit voidaan päivittää itsenäisesti, kun moduulit päivitetään /lib/modules. Itse GKI: n oletetaan olevan mahdollisimman puhdas ja geneerinen, mikä on mahdollista purkamalla nyt puun ulkopuolinen koodi erillisiin moduuleihin.

Kuten Ted Kjos selitti osoitteessa Tämän vuoden Linux Plumbers Conference, "suuri monivuotinen työntö on saada kaikki laitteistokohtainen koodi pois yleisestä ytimestä ja osaksi toimittajamoduuleja. Meillä on oltava vakaa rajapinta näiden toimittajamoduulien ja yleisen ytimen välillä, jotta ne voidaan toimittaa asynkronisesti." GKI 1.0 on pohjimmiltaan "yhteensopivuustesti".

Itse asiassa GKI-yhteensopivuus tarkoittaa, että laite läpäisee VTS- ja CTS-on-GSI+GKI-testit yleisen järjestelmäkuvan (GSI) kanssa. ja GKI-ydin asennettuna vilkkumalla GKI-käynnistysotos järjestelmän käynnistysosioon ja GSI-järjestelmäkuva osio. Vendor Test Suite eli VTS on automaattinen testi, joka kaikkien laitteiden on läpäistävä, jotta niitä voidaan pitää Project Treblen kanssa yhteensopivina. Yhteensopivuustestipaketti eli CTS vaaditaan, jotta voit käyttää Googlen sovelluspakettia.

Laitteet voidaan toimittaa eri tuoteytimen kanssa, ja ne voivat käyttää ladattavia moduuleja, joita GKI ei tarjoa. Sekä tuotteen että GKI-ytimien on kuitenkin ladattava moduuleja samoista vendor_boot- ja vendor-osioista. Siksi kaikilla tuoteytimillä on oltava sama binary kernel module interface (KMI).

Yllä oleva kaavio näyttää mitä Google haluaa tehdä, ja selittää, miten se aikoo saavuttaa sen. Generic Kernel- ja GKI-moduulit ovat osa AOSP: tä, ja GKI voi kommunikoida Android-kehyksen ja Hardware Abstraction Layerin (HAL) kanssa, jotka myyjä voi toteuttaa. Erityinen oma koodi, jonka toimittaja haluaa ytimeen (esimerkiksi kameran ajurit), työnnetään sen sijaan toimittajamoduuliin, josta tulee GKI: n laajennus KMI: n kautta.

Kuinka GKI voi auttaa ratkaisemaan Androidin pirstoutumisongelman

Google on tehnyt paljon työtä älypuhelimien kehitysprosessin virtaviivaistamiseksi. Jokainen OEM haluaa oman brändi-identiteettinsä, ja jokainen OEM haluaa omistaa laitteet. Toisin kuin Android One -ohjelma, Android-älypuhelimet voivat olla melkein mitä tahansa, kunhan ne noudattavat sääntöjä, jotka Google asettaa saadakseen GMS-lisenssin. Aiemmin Google ei kuitenkaan ole tehnyt paljon hallitakseen Android-laitteiden kehitystä muutokset, kuten Project Treble, Mainline ja nyt GKI on paljon uudempi Androidissa historia.

Mutta auttaako se? Sen pitäisi toimia, vaikka kyseessä on todennäköisesti monivuotinen tapaus, joka kantaa näkyvää hedelmää myöhemmin. Tämä koskee vain laitteita, jotka käynnistetään Android 12:lla, mikä tarkoittaa, että tulemme näkemään laitteita, joissa ei ole GKI: tä vuosiin. Se oli myös kritiikki Project Treblelle, kun se julkistettiin, vaikka ilmeisesti kaikki nykyään lanseeratut laitteet tukevat sitä. Nämä asiat vievät aikaa, ja kun Google vähitellen valtaa Androidin, kehitysprosessi helpottuu kaikkien OEM-valmistajien osalta. Android-ekosysteemiin, vaikka jotkut heistä mieluummin säilyttäisivät täyden hallinnan Androidissa käytettävästä Linux-ytimestä älypuhelimet.