Googleova Generic Kernel Image sljedeći je korak prema rješavanju problema fragmentacije Androida

Google već godinama radi na smanjenju fragmentacije na Androidu, iako je dio uzroka tome inherentna priroda Androida i dvosjekli mač izbora i slobode. Bezbrojni su OEM-ovi aktivni u svemiru i svi oni žele napraviti vlastite modifikacije za svoje uređaje. Problem je u tome što se čini da se ažuriranja OS-a Android sporo uvode u cijeloj ploči, ali ne postoji mnogo toga što Google zapravo može učiniti da natjera OEM-ove da ažuriraju svoje uređaje. Kao takva, sljedeća najbolja stvar koju Google može učiniti je učiniti proces ažuriranja što lakšim i lakšim.

Ublažavanje problema s ažuriranjem Androida

Prva velika inicijativa u Googleovom dugoročnom projektu smanjenja tereta razvoja bila je Projekt Treble. Najavljen zajedno s Androidom 8.0 Oreo 2017., Project Treble modularizirao je Android odvajanjem okvira OS-a od implementacije dobavljača (HAL-ovi i vilica Linux kernela specifična za uređaj). To je OEM-ovima za Android olakšalo ponovno baziranje svojih operativnih sustava na najnovijem okviru AOSP, jer su mogli pokrenuti najnoviju verziju bez potrebe za ažuriranim kodom od dobavljača. Kao rezultat toga, OEM-ovi bi mogli pripremiti svoje prilagođene Android forkove brže nego prije, a time i brže uvesti glavna ažuriranja OS-a.

Sljedeći korak u Googleovim planovima bio je pojednostaviti isporuku ažuriranja ključnih komponenti Androida. Google je ovu inicijativu nazvao Glavni projekt kada ga je predstavio zajedno s Androidom 10 2019. Google je u biti preuzeo kontrolu nad ključnim komponentama OS-a i zabranio proizvođačima originalne opreme da ih mijenjaju. Zatim su postavili mehanizam isporuke putem Google Playa kako bi mogli daljinski uvesti ažuriranja za te ključne komponente bez čekanja da proizvođači originalne opreme sami primijene zakrpe. Mainline je uvelike poboljšao brzinu kojom uređaji primaju ažurirane verzije važnih komponenti OS-a, zauzvrat poboljšavajući sigurnost Android ekosustava u cjelini.

Međutim, kada je u pitanju Treble, Linux kernel realno se ne bi trebao stavljati u jednu ruku s kodom dobavljača zatvorenog koda. Todd Kjos na ovogodišnju Linux Plumbers Conference je u prošlosti objasnio poteškoće s kojima se suočavaju kada je u pitanju fragmentacija na Androidu, a mnogo toga sada se vrti oko Linux kernela koji proizvođači originalne opreme isporučuju sa svojim uređajima. Za kontekst, Google račva svaku glavnu jezgru Linuxa u "Android Common Kernel” (ACK) ogranak, koji pomno prati glavno izdanje, ali dodaje nekoliko zakrpa specifičnih za Android. Dobavljači SoC-a kao što su Qualcomm, MediaTek i Samsung tada se odvajaju da kernel za svaki SoC koji naprave. OEM-ovi zatim uzimaju taj kernel specifičan za SoC i dodaju dodatne zakrpe za implementaciju podrške za određeni hardver koji žele isporučiti.

Gornji dijagram pokazuje kako kernel uređaja prolazi kroz nekoliko slojeva promjena koje ga apstrahiraju daleko od Linux LTS kernela. Da bismo ga pojednostavili, počinjemo s jezgrom Linuxa, a ona se spaja s zajedničkom jezgrom Androida uz nekoliko promjena. Odatle se zajednička jezgra Androida spaja s jezgrom dobavljača (Qualcomm, MediaTek itd.) sa svojim modifikacijama i promjenama. Konačno, jezgra dobavljača spojena je u jezgru specifičnu za OEM uređaj. Do ove faze, kernel bilo kojeg uređaja daleko je od Linux LTS kernela s kojim je započeo.

Kao rezultat svih tih račvanja, čak 50% koda koji se izvodi na Android uređaju je kod izvan stabla, što znači da nije iz uzvodnih Linux ili AOSP uobičajenih jezgri. Zbog toga je nevjerojatno teško (da ne spominjemo dugotrajno i skupo) spajanje uzvodnih promjena. Za OEM-e nema poticaja za to, ali ta praksa može biti štetna za sigurnost uređaja. To je također razlog zašto je puno Android uređaja ostavljeno na starijim izdanjima LTS kernela, što ima nuspojavu uređaja koji gube pristup novim značajkama Linux kernela.

Android je fragmentiran i Google to zna

Google vrlo dobro zna da je to problem i čak ima odjeljak pod nazivom "Troškovi fragmentacije" u dokumentaciji za razvojne programere Androida. Google to kaže "većina vodećih uređaja isporučuje se s verzijom kernela koja je već stara najmanje 18 mjeseci". Još gore, Google to također kaže "Android 10 podržava 3.18, 4.4, 4.9, 4.14 i 4.19 jezgre, koje u nekim slučajevima nisu poboljšane novim značajkama od Androida 8 2017." To otežava dodavanje značajki koje zahtijevaju nove verzije Linux kernela. Linux kernel 3.18 lansiran je u prosincu 2014., još u vrijeme kada je Android 5.0 Lollipop bio najnovija verzija Androida. To je očito problem i može kočiti platformu.

Na primjer, Code Aurora Forum, ili skraćeno CAF, ugošćuje izvorni kod za razne Qualcomm Snapdragon SoC-ove. Qualcomm, kao SoC dobavljač, distribuira račvastu verziju Linux kernela OEM/ODM proizvođačima, a te tvrtke zatim dodaju promjene specifične za uređaj prilikom isporuke uređaja. To je ono što dodaje nekoliko slojeva fragmentacije. Osim toga, Qualcomm mijenja okvir AOSP kako bi optimizirao Android za svaku od tvrtkinih mobilnih platformi Snapdragon. Qualcomm privatno distribuira svoju modificiranu jezgru Linuxa, okvir AOSP i druge softverske alate svojim partnerima kao dio paketa za podršku odbora ili BSP. CAF je mjesto gdje Qualcomm javno objavljuje ove promjene jezgre Linuxa i promjene okvira AOSP.

Ovo CAF izdanje može biti korisno za prilagođene ROM programere koji ga žele koristiti kao početnu točku, a ne čisti AOSP, zbog čega ponekad vidite ROM-ovi koji se temelje na CAF-u na našim forumima. Sjećate se Snapdragona 625 koji je godinama pokretao toliko pametnih telefona srednje klase? To je pokrenuto s Linux kernelom 3.18, a tek pred kraj 2018. (dvije godine nakon lansiranja čipseta) Qualcomm je ažurirao izvore kernela i objavio ih na CAF za msm8953 (naziv čipseta za Snapdragon 625) koji donosi podršku za Linux kernel 4.9. Problem je u tome što većina OEM-a neće ažurirati telefone na ovu novu verziju Linux kernela, posebno ne telefone srednje klase dvije godine nakon što je čip pušten na slobodu. Doduše, vrlo je rijetko da se takvo veliko ažuriranje kernela uopće dogodi, ali poanta je da ima dogodilo, tako da to nije samo nemoguć scenarij.

Sve u svemu, trenutna fragmentacija u Androidu je, najblaže rečeno, haos. Najnoviji pokušaji Googlea da popravi tu fragmentaciju dolaze u obliku Generic Kernel Image ili GKI.

Predstavljamo generičku sliku kernela

Kako bi riješio ovu fragmentaciju, Google je radio na Android Generic Kernel Image (GKI). Ovo je u biti kernel kompajliran ravno iz ACK grane. GKI izolira prilagodbe dobavljača SoC-a i OEM-a za module dodataka, eliminirajući kod izvan stabla i dopuštajući Googleu da ažuriranja kernela šalje izravno krajnjem korisniku. Više od godinu dana Google je radio na načinu isporuke GKI ažuriranja putem Trgovine Play, korištenjem Mainline modula.

Kao rezultat toga, uređaji koji se pokreću s Androidom 12 koji pokreću Linux kernel 5.10.43 ili noviji moraju učiniti nešto od sljedećeg, prema Mishaalu Rahmanu.

• Postavite sliku za pokretanje koju je potpisao Google

ILI

• Postavite sliku za pokretanje s kernelom koji izvozi KMI (Kernel Module Interface) koji je podskup KMI-ja koji izvozi GKI, izvozi API korisničkog prostora koji je nadskup UAPI-ja koji izlaže GKI i podržava sve značajke odgovarajućeg GKI-ja verzija

Dobavljači mogu kreirati module koji se uključuju u GKI, ali ideja GKI-ja je da Google preuzima teret odgovornosti za rukovanje promjenama kernela. Sučelje modula kernela (ili KMI, više o tome u kasnijim dijelovima članka) zapravo je mjesto gdje se očekuje da ide kod izvan stabla.

Serija Google Pixel 6 lansirana je s Androidom 12 odmah po otvaranju i isporučuje se s Linux kernelom 5.10, a to je prvi telefon koji se isporučuje s GKI-jem. Budući da bi Google potencijalno mogao ažurirati kernel putem Trgovine Play, mogli bismo čak vidjeti česta ažuriranja kernela, budući da se ažuriranja LTS kernela obično objavljuju tjedno. U svakom slučaju, to je puno bolji sustav od trenutno glomazne metode ažuriranja putem OTA-e, iako to ne znači da je inherentno povezan s GMS okvirom.

Google jednostavno definira GKI na sljedeći način:

• Izgrađen je iz ACK izvora.
• To je binarna datoteka s jednom jezgrom plus povezani moduli koji se mogu učitavati po arhitekturi, po LTS izdanju (trenutno samo arm64 za android11-5.4 i android12-5.4).
• Testiran je sa svim izdanjima platforme Android koja su podržana za pridruženi ACK. Ne postoji odustajanje značajke tijekom životnog vijeka verzije GKI kernela
• Izlaže stabilan KMI vozačima unutar određenog LTS-a.
• Ne sadrži SoC niti kôd specifičan za ploču.

Google čak želi biti u poziciji do 2023. u kojoj može uzeti razvojni model "upstream first". Ovo će pomoći Googleu da osigura da novi kod prvi stigne u glavnu jezgru Linuxa, smanjujući "tehnički dug" akumuliran kod izvan stabla na Android uređajima.

Sučelje modula kernela (KMI)

Sučelje modula kernela, ili KMI, dio je Googleovog rješenja za tekuću fragmentaciju u Androidu. U biti, SoC i podrška za ploču više se ne nalaze u jezgri jezgre i umjesto toga su premješteni u module koji se mogu učitavati. I kernel i moduli mogu se neovisno ažurirati, jer se moduli ažuriraju /lib/modules. Sam GKI bi trebao biti što čistiji i generički, što je omogućeno rasterećenjem onoga što je sada kod izvan stabla u zasebne module.

Kao Ted Kjos objasnio na ovogodišnje Linux Plumbers Conference, "veliki višegodišnji napor je da se sav hardverski specifični kod iz generičke jezgre prenese u module dobavljača. Moramo imati stabilno sučelje između tih modula dobavljača i generičkog kernela kako bi se mogli isporučivati ​​asinkrono." GKI 1.0 je u biti "test usklađenosti".

Zapravo, GKI kompatibilnost znači da uređaj prolazi VTS i CTS-on-GSI+GKI testove s Generic System Image (GSI) i GKI kernel instaliran flashiranjem GKI boot slike u boot particiju i GSI sistemske slike u sustavu pregrada. Vendor Test Suite ili VTS automatizirani je test koji svi uređaji moraju proći da bi se smatrali kompatibilnima s Project Treble. Za pristup Googleovom paketu aplikacija potreban je Compatibility Test Suite ili CTS.

Uređaji se mogu isporučiti s drugom jezgrom proizvoda i mogu koristiti module koji se mogu učitati koje GKI ne nudi. Međutim, i proizvod i GKI kerneli moraju učitati module s iste particije vendor_boot i vendor. Stoga sve jezgre proizvoda moraju imati isto binarno sučelje modula jezgre (KMI).

Gornji dijagram pokazuje što Google želi učiniti i objašnjava kako to namjerava postići. Moduli Generički kernel i GKI bit će dio AOSP-a, a GKI može komunicirati s okvirom Androida i slojem apstrakcije hardvera (HAL) koji dobavljač može implementirati. Određeni vlasnički kod koji dobavljač želi u kernelu (na primjer, upravljački programi za kameru) umjesto toga bit će gurnut u modul dobavljača koji postaje proširenje GKI-ja putem KMI-ja.

Kako GKI može pomoći u rješavanju problema fragmentacije Androida

Google je uložio puno truda u pojednostavljenje procesa razvoja pametnih telefona. Svaki OEM želi identitet vlastite robne marke i svaki OEM želi imati vlasništvo nad svojim uređajima. Za razliku od programa Android One, Android pametni telefoni mogu biti što god požele, sve dok se pridržavaju skupa pravila koje je Google postavio kako bi dobili GMS licencu. Međutim, u prošlosti Google nije učinio puno da bi zavladao razvojem Android uređaja promjene kao što su Project Treble, Mainline i sada GKI koji je puno noviji u Androidu povijesti.

Ali hoće li pomoći? Trebalo bi uspjeti, iako će to vjerojatno biti višegodišnja afera koja će kasnije uroditi vidljivim plodom. Ovo će se primjenjivati ​​samo na uređaje koji se pokreću s Androidom 12, što znači da ćemo još godinama vidjeti uređaje koji nemaju GKI. To je također bila kritika projekta Treble kada je to najavljeno, iako ga očito podržavaju svi uređaji koji se danas lansiraju. Za te je stvari potrebno vrijeme, a kako Google polako preuzima vlast na Androidu, proces razvoja je olakšan za sve OEM-ove u ekosustava Androida, čak i ako bi neki od njih radije zadržali punu kontrolu nad jezgrom Linuxa koja se koristi na Androidu pametni telefoni.