Googlova generična slika jedra je naslednji korak k rešitvi problema razdrobljenosti Androida

Googlova generična slika jedra želi rešiti problem razdrobljenosti v Androidu, čeprav je to zapletena tema. Evo, kako to deluje.

Google si že leta prizadeva zmanjšati razdrobljenost Androida, čeprav je del vzroka za to inherentna narava Androida ter dvorezen meč izbire in svobode. V vesolju je dejavnih nešteto proizvajalcev originalne opreme in vsi želijo izdelati lastne modifikacije za svoje naprave. Težava je torej v tem, da se zdi, da se posodobitve operacijskega sistema Android počasi uvajajo na vseh področjih, vendar Google ne more storiti veliko, da bi prisilil proizvajalce originalne opreme, da posodobijo svoje naprave. Kot taka je naslednja najboljša stvar, ki jo lahko naredi Google, narediti postopek posodabljanja čim bolj preprost in brez trenja.

Lajšanje težav pri posodobitvi Androida

Prva večja pobuda v Googlovem dolgoročnem projektu zmanjšanja razvojnega bremena je bila Projekt Treble. Projekt Treble, ki je bil leta 2017 najavljen poleg Androida 8.0 Oreo, je modulariziral Android tako, da je ogrodje OS ločil od izvajanja prodajalca (HAL in razcep jedra Linuxa za napravo). To je proizvajalcem originalne opreme za Android olajšalo preosnovo svojih operacijskih sistemov na najnovejšo ogrodje AOSP, saj so lahko zagnali najnovejšo različico, ne da bi potrebovali posodobljeno kodo prodajalcev. Posledično bi proizvajalci originalne opreme lahko svoje vilice za Android po meri pripravili hitreje kot prej in posledično hitreje uvedli večje posodobitve OS.

Naslednji korak v Googlovih načrtih je bil poenostaviti dostavo posodobitev ključnih komponent Androida. Google je to pobudo poimenoval Projekt Mainline ko ga je leta 2019 predstavil skupaj z Androidom 10. Google je v bistvu prevzel nadzor nad ključnimi komponentami OS in proizvajalcem originalne opreme prepovedal njihovo spreminjanje. Nato vzpostavijo mehanizem dostave prek storitve Google Play, tako da lahko na daljavo uvedejo posodobitve teh ključnih komponent, ne da bi morali čakati, da proizvajalci originalne opreme sami namestijo popravke. Mainline je močno izboljšal, kako hitro naprave prejmejo posodobljene različice pomembnih komponent OS, s čimer je izboljšal varnost celotnega ekosistema Android.

Ko gre za Treble, pa jedra Linuxa realno ne bi smeli pomešati z zaprtokodno kodo prodajalca. Todd Kjos pri letošnji Linux Plumbers Conference je v preteklosti razložil težave, s katerimi se soočajo, ko gre za razdrobljenost na Androidu, in veliko tega se zdaj osredotoča na jedro Linuxa, ki ga proizvajalci originalne opreme pošiljajo s svojimi napravami. Za kontekst Google razdeli vsako glavno jedro Linuxa v »Skupno jedro Android” (ACK), ki natančno spremlja glavno izdajo, vendar dodaja nekaj popravkov, specifičnih za Android. Prodajalci SoC, kot so Qualcomm, MediaTek in Samsung, se nato razcepijo to jedro za vsak SoC, ki ga izdelajo. Proizvajalci originalne opreme nato vzamejo to jedro, specifično za SoC, in dodajo dodatne popravke za implementacijo podpore za specifično strojno opremo, ki jo želijo poslati.

Zgornji diagram prikazuje, kako gre jedro naprave skozi več plasti sprememb, ki ga abstrahirajo daleč od jedra Linux LTS. Za poenostavitev začnemo z jedrom Linuxa, ki se z nekaj spremembami združi v skupno jedro Android. Od tam se skupno jedro Androida združi v jedro prodajalca (Qualcomm, MediaTek itd.) z lastnimi modifikacijami in spremembami. Končno je jedro prodajalca združeno z jedrom proizvajalca originalne opreme, specifičnim za napravo. Do te stopnje je jedro katere koli naprave daleč od jedra Linux LTS, s katerim se je začelo.

Kot rezultat vseh teh forkov je kar 50 % kode, ki se izvaja v napravi Android, koda zunaj drevesa, kar pomeni, da ni iz zgornjih običajnih jeder Linuxa ali AOSP. Zaradi tega je izjemno težko (da ne omenjamo zamudno in drago) združiti spremembe navzgor. Za proizvajalce originalne opreme ni nobene spodbude za to, vendar je ta praksa lahko škodljiva za varnost naprave. To je tudi razlog, zakaj veliko naprav Android ostane na starejših izdajah jedra LTS, kar ima stranski učinek naprave, ki izgubijo dostop do novih funkcij jedra Linuxa.

Android je razdrobljen in Google se tega zaveda

Google dobro ve, da je to težava, in ima celo razdelek, imenovan "Stroški razdrobljenosti« v dokumentaciji za razvijalce za Android. Google to pravi "večina vodilnih naprav ima različico jedra, ki je že stara vsaj 18 mesecev". Še huje, to pravi tudi Google "Android 10 podpira jedra 3.18, 4.4, 4.9, 4.14 in 4.19, ki v nekaterih primerih niso bila izboljšana z novimi funkcijami od Androida 8 leta 2017." Zaradi tega je težko dodati funkcije, ki zahtevajo nove različice jedra Linuxa. Jedro Linuxa 3.18 je bilo predstavljeno decembra 2014, ko je bil Android 5.0 Lollipop najnovejša različica Androida. To je očitno problem in lahko zadrži platformo.

Na primer, Code Aurora Forum ali na kratko CAF gosti izvorno kodo za različne Qualcomm Snapdragon SoC. Qualcomm kot SoC prodajalec, distribuira razcepljeno različico jedra Linuxa proizvajalcem originalne opreme/izdelovalcem originalne opreme, ta podjetja pa nato ob pošiljanju dodajo spremembe, specifične za napravo. naprave. To dodaja več plasti razdrobljenosti. Poleg tega Qualcomm spreminja okvir AOSP za optimizacijo Androida za vsako od mobilnih platform podjetja Snapdragon. Qualcomm zasebno distribuira svoje spremenjeno jedro Linuxa, ogrodje AOSP in druga programska orodja svojim partnerjem kot del paketa Board Support Package ali BSP. CAF je mesto, kjer Qualcomm javno objavi te spremembe jedra Linuxa in spremembe okvira AOSP.

Ta izdaja CAF je lahko uporabna za razvijalce ROM-a po meri, ki jo želijo uporabiti kot izhodišče namesto čistega AOSP, zaradi česar včasih vidite ROM-i, ki temeljijo na CAF, na naših forumih. Se spomnite Snapdragona 625, za katerega se je zdelo, da leta poganja toliko pametnih telefonov srednjega razreda? To se je začelo z jedrom Linux 3.18 in šele proti koncu leta 2018 (dve leti po lansiranju nabora čipov) je Qualcomm posodobil izvorne kode jedra in jih objavil na CAF za msm8953 (ime nabora čipov za Snapdragon 625), ki prinaša podporo za Linux Kernel 4.9. Težava je v tem, da večina proizvajalcev originalne opreme ne bo posodobil telefonov na to novo različico jedra Linuxa, še posebej ne telefonov srednjega razreda dve leti po tem, ko je bil čip izpuščen. Res je, da se takšna večja posodobitev jedra sploh zgodi zelo redko, a bistvo je, da ima zgodilo, torej ne gre le za nemogoč scenarij.

Skratka, trenutna razdrobljenost v Androidu je lahkotno rečeno zmešnjava. Zadnji poskusi Googla, da bi popravil to razdrobljenost, prihajajo v obliki generične slike jedra ali GKI.

Predstavljamo generično sliko jedra

Da bi rešil to razdrobljenost, je Google delal na Android Generic Kernel Image (GKI). To je v bistvu jedro, prevedeno neposredno iz veje ACK. GKI izolira prilagoditve prodajalca SoC in OEM za module vtičnikov, odpravlja kodo zunaj drevesa in omogoča Googlu, da posreduje posodobitve jedra neposredno končnemu uporabniku. Google že več kot eno leto išče način za dostavo posodobitev GKI prek Trgovine Play, z uporabo modula Mainline.

Posledično morajo naprave, ki se zaženejo z Androidom 12 in uporabljajo jedro Linuxa 5.10.43 ali novejšo različico, storiti nekaj od naslednjega, po besedah ​​Mishaala Rahmana.

  • Namestite zagonsko sliko, ki jo je podpisal Google

ALI

  • Razmestite zagonsko sliko z jedrom, ki izvozi KMI (vmesnik modula jedra), ki je podnabor KMI, ki ga izvozi GKI, izvozi API uporabniškega prostora, ki je nadnabor UAPI, ki ga izpostavi GKI, in podpira vse funkcije ustreznega GKI različica

Prodajalci lahko ustvarijo module, ki se priključijo na GKI, vendar je ideja GKI ta, da Google prevzame breme odgovornosti za ravnanje s spremembami jedra. Vmesnik modula jedra (ali KMI, več o tem v poznejših delih članka) je pravzaprav tisto, kamor naj bi šla koda zunaj drevesa.

Serija Google Pixel 6 je bila predstavljena z operacijskim sistemom Android 12 takoj po pripravi in ​​je dobavljena z jedrom Linux 5.10 ter je prvi telefon, ki je bil dobavljen z GKI. Ker bi Google lahko posodobil jedro prek Trgovine Play, bomo morda celo videli pogoste posodobitve jedra, ker so posodobitve jedra LTS običajno objavljene tedensko. V vsakem primeru je veliko boljši sistem od trenutno okorne metode posodabljanja prek OTA, čeprav to pomeni, da je sam po sebi vezan na okvir GMS.

Google preprosto definira GKI kot naslednje:

  • Zgrajen je iz virov ACK.
  • To je dvojiška datoteka z enim jedrom in pripadajočimi moduli, ki jih je mogoče naložiti na arhitekturo, na izdajo LTS (trenutno samo arm64 za android11-5.4 in android12-5.4).
  • Preizkušen je z vsemi izdajami platforme Android, ki jih podpira povezani ACK. Funkcija ni opuščena za celotno življenjsko dobo različice jedra GKI
  • Gonilnikom v danem LTS izpostavi stabilen KMI.
  • Ne vsebuje SoC ali kode, specifične za ploščo.

Google celo želi biti do leta 2023 v položaju, ko lahko sprejme razvojni model "najprej navzgor". To bo Googlu pomagalo zagotoviti, da bo nova koda prva pristala v glavnem jedru Linuxa, kar bo zmanjšalo "tehnični dolg", nakopičen izven drevesne kode na napravah Android.

Vmesnik modula jedra (KMI)

Vmesnik modula jedra ali KMI je del Googlove rešitve za nenehno razdrobljenost v sistemu Android. V bistvu se SoC in podpora za ploščo ne nahajata več v jedru jedra in sta namesto tega premaknjena v module, ki jih je mogoče naložiti. Tako jedro kot module je mogoče posodobiti neodvisno, saj se moduli posodobijo v /lib/modules. Sam GKI naj bi bil čim bolj čist in splošen, kar je mogoče z raztovarjanjem tega, kar je zdaj zunajdrevesna koda, v ločene module.

Kot Ted Kjos pojasnil pri na letošnji konferenci vodovodarjev Linuxa, "je velik večletni napor, da se vsa koda, specifična za strojno opremo, prenese iz splošnega jedra v module prodajalca. Imeti moramo stabilen vmesnik med temi moduli prodajalca in generičnim jedrom, da se lahko pošiljajo asinhrono." GKI 1.0 je v bistvu "test skladnosti".

Pravzaprav združljivost z GKI pomeni, da naprava opravi teste VTS in CTS-on-GSI+GKI z Generic System Image (GSI) in jedro GKI, nameščeno z bliskavico zagonske slike GKI v zagonsko particijo in sistemske slike GSI v sistemu particija. Vendor Test Suite ali VTS je avtomatiziran test, ki ga morajo opraviti vse naprave, da se štejejo za združljive s Project Treble. Za dostop do Googlove zbirke aplikacij je potreben paket Compatibility Test Suite ali CTS.

Naprave so lahko dobavljene z drugim jedrom izdelka in lahko uporabljajo naložljive module, ki jih GKI ne ponuja. Vendar morata izdelek in jedra GKI naložiti module iz iste particije vendor_boot in vendor. Zato morajo imeti vsa jedra izdelkov enak binarni vmesnik modula jedra (KMI).

Zgornji diagram prikazuje, kaj Google želi storiti, in razloži, kako namerava to doseči. Moduli Generic Kernel in GKI bodo del AOSP, GKI pa bo lahko komuniciral z ogrodjem Android in plastjo abstrakcije strojne opreme (HAL), ki ju lahko implementira prodajalec. Posebna lastniška koda, ki jo prodajalec želi v jedru (na primer gonilniki kamere), bo namesto tega potisnjena v modul prodajalca, ki postane razširitev GKI prek KMI.

Kako lahko GKI pomaga rešiti problem fragmentacije Androida

Google je vložil veliko dela v racionalizacijo razvojnega procesa pametnih telefonov. Vsak proizvajalec originalne opreme želi lastno identiteto blagovne znamke in vsak proizvajalec originalne opreme želi biti lastnik svojih naprav. V nasprotju s programom Android One so lahko pametni telefoni Android karkoli hočejo, če se držijo niza pravil, ki jih Google določi za pridobitev licence GMS. Vendar pa Google v preteklosti ni storil prav veliko, da bi zavladal razvoju naprav Android, s spremembe, kot so Project Treble, Mainline in zdaj GKI, ki je v Androidu veliko novejši zgodovina.

Toda ali bo pomagalo? Moralo bi, čeprav bo to verjetno večletna afera, ki bo obrodila vidne sadove kasneje. To bo veljalo samo za naprave, ki se zaženejo z Androidom 12, kar pomeni, da bomo v prihodnjih letih videli naprave, ki nimajo GKI. To je bila tudi kritika projekta Treble, ko je bil objavljen, čeprav ga očitno podpirajo vse naprave, ki so dane danes. Te stvari zahtevajo čas in ker Google počasi prevzema oblast nad Androidom, je razvojni proces olajšan za vse proizvajalce originalne opreme v ekosistema Android, čeprav bi nekateri od njih raje obdržali popoln nadzor nad jedrom Linuxa, ki se uporablja v sistemu Android pametni telefoni.