Googles generiske kjernebilde er neste skritt mot å løse Androids fragmenteringsproblem

Google har jobbet med å redusere fragmentering på Android i årevis, selv om en del av årsaken til det er den iboende naturen til Android og det tveeggete sverdet av valg og frihet. Det er utallige OEM-er aktive i området, og alle ønsker å gjøre sine egne modifikasjoner for sine egne enheter. Problemet er da at det ser ut til at Android OS-oppdateringer er trege med å rulle ut over hele linja, men det er ikke mye Google faktisk kan gjøre for å tvinge OEM-er til å oppdatere enhetene sine. Som sådan er det nest beste Google kan gjøre å gjøre oppdateringsprosessen så enkel og friksjonsfri som mulig.

Lindrer smerten med Android-oppdateringen

Det første store initiativet i Googles langsiktige prosjekt for å redusere utviklingsbyrden var Prosjekt diskant. Project Treble ble kunngjort sammen med Android 8.0 Oreo i 2017, og modulariserte Android ved å skille OS-rammeverket fra leverandørimplementeringen (HAL-er og den enhetsspesifikke Linux-kjernegaffelen). Dette gjorde det enklere for Android OEM-er å rebase OS-ene sine på toppen av det nyeste AOSP-rammeverket, ettersom de kunne starte opp den nyeste versjonen uten å trenge oppdatert kode fra leverandører. Som et resultat kunne OEM-er klargjøre sine tilpassede Android-gafler raskere enn før, og i forlengelsen rulle ut store OS-oppdateringer raskere.

Det neste trinnet i Googles planer var å strømlinjeforme leveringen av oppdateringer til viktige Android-komponenter. Google kalte dette initiativet Prosjekt hovedlinje da den introduserte den sammen med Android 10 i 2019. Google tok i hovedsak kontroll over viktige OS-komponenter og forbyr OEM-er å endre dem. De satte deretter opp en leveringsmekanisme via Google Play slik at de kunne eksternt rulle ut oppdateringer til disse nøkkelkomponentene uten å måtte vente på at OEM-er skal bruke oppdateringene selv. Mainline forbedret kraftig hvor raskt enheter mottar oppdaterte versjoner av viktige OS-komponenter, og forbedret i sin tur sikkerheten til Android-økosystemet som helhet.

Når det kommer til diskant, burde Linux-kjernen realistisk sett ikke være klumpet inn med lukket kildekode. Todd Kjos kl årets Linux Rørleggerkonferanse har tidligere forklart vanskelighetene som står overfor når det kommer til fragmentering på Android, og mye av det er nå sentrert rundt Linux-kjernen som OEM-er leverer med enhetene sine. For kontekst deler Google hver hovedlinje Linux-kjerne til en "Android Common Kernel” (ACK) gren, som følger hovedlinjeutgivelsen nøye, men legger til noen Android-spesifikke patcher. SoC-leverandører som Qualcomm, MediaTek og Samsung gaffel at kjerne for hver SoC de lager. OEM-er tar deretter den SoC-spesifikke kjernen og legger til flere patcher for å implementere støtte for den spesifikke maskinvaren de vil sende.

Diagrammet ovenfor viser hvordan en enhets kjerne går gjennom flere lag med endring som abstraherer den langt fra Linux LTS-kjernen. For å forenkle det starter vi med Linux-kjernen, og den blir slått sammen til Android Common Kernel med noen få endringer. Derfra blir Android Common Kernel slått sammen til en leverandørkjerne (Qualcomm, MediaTek, etc) med sine egne modifikasjoner og endringer. Til slutt blir leverandørkjernen slått sammen til en OEMs enhetsspesifikke kjerne. På dette stadiet er en hvilken som helst enhets kjerne langt unna Linux LTS-kjernen som den startet med.

Som et resultat av alle disse gaflene er så mye som 50 % av koden som kjører på en Android-enhet utenfor trekode, noe som betyr at den ikke er fra oppstrøms Linux eller AOSP vanlige kjerner. Dette gjør det utrolig vanskelig (for ikke å snakke om tidkrevende og kostbart) å slå sammen oppstrømsendringer. For OEM-er er det ingen insentiv til å gjøre det, men denne praksisen kan være skadelig for enhetssikkerheten. Dette er også grunnen til at mange Android-enheter er igjen på eldre LTS-kjerneutgivelser, noe som har den bivirkningen at enheter mister tilgangen til nye Linux-kjernefunksjoner.

Android er fragmentert, og Google vet det

Google vet godt at dette er et problem, og har til og med en seksjon kalt "Kostnadene ved fragmentering" i Android-utviklerdokumentasjonen. Google sier det "de fleste flaggskipenheter leveres med en kjerneversjon som allerede er minst 18 måneder gammel". Enda verre, Google sier også det "Android 10 støtter 3.18, 4.4, 4.9, 4.14 og 4.19 kjerner, som i noen tilfeller ikke har blitt forbedret med nye funksjoner siden Android 8 i 2017." Dette gjør det vanskelig å legge til funksjoner som krever nye Linux-kjerneversjoner. Linux-kjerne 3.18 ble lansert i desember 2014, da Android 5.0 Lollipop var den nyeste versjonen av Android. Det er helt klart et problem og kan holde plattformen tilbake.

For eksempel er Code Aurora Forum, eller CAF for kort, vert for kildekoden for ulike Qualcomm Snapdragon SoCs. Qualcomm, som en SoC leverandør, distribuerer en splittet versjon av Linux-kjernen til OEM-er/ODM-er, og disse selskapene legger deretter til enhetsspesifikke endringer på frakt enheter. Det er dette som legger til flere lag med fragmentering. I tillegg gjør Qualcomm endringer i AOSP-rammeverket for å optimalisere Android for hver av selskapets Snapdragon-mobilplattformer. Qualcomm distribuerer privat sin modifiserte Linux-kjerne, AOSP-rammeverk og andre programvareverktøy til sine partnere som en del av en Board Support Package, eller BSP. CAF er der Qualcomm offentlig publiserer disse Linux-kjerneendringene og AOSP-rammeverksendringene.

Denne CAF-utgivelsen kan være nyttig for tilpassede ROM-utviklere som ønsker å bruke den som et utgangspunkt i stedet for ren AOSP, og det er derfor du noen ganger ser "CAF-baserte" ROM-er på forumene våre. Husker du Snapdragon 625 som så ut til å drive så mange mellomstore smarttelefoner i årevis? Som ble lansert med Linux Kernel 3.18, og først mot slutten av 2018 (to år etter at brikkesettet ble lansert) oppdaterte Qualcomm kjernekildene og publiserte dem på CAF for msm8953 (brikkesettnavnet til Snapdragon 625) som gir støtte for Linux Kernel 4.9. Problemet er at de fleste OEM-er vil ikke oppdatere telefoner til denne nye Linux-kjerneversjonen, spesielt ikke mellomtonetelefoner to år etter at brikken ble løslatt. Riktignok er det svært sjelden at en slik stor kjerneoppdatering i det hele tatt skjer i utgangspunktet, men poenget er at det har skjedde, så det er ikke bare et umulig scenario.

Alt i alt er den nåværende fragmenteringen i Android et rot, for å si det lett. Googles siste forsøk på å fikse denne fragmenteringen kommer i form av Generic Kernel Image, eller GKI.

Vi introduserer det generiske kjernebildet

For å løse denne fragmenteringen jobbet Google med Android Generic Kernel Image (GKI). Dette er egentlig en kjerne kompilert rett fra en ACK-gren. GKI isolerer SoC-leverandør og OEM-tilpasninger til plugin-moduler, eliminerer kode utenfor treet og lar Google sende kjerneoppdateringer direkte til sluttbrukeren. I over et år har Google jobbet med en måte å levere GKI-oppdateringer via Play Store, ved bruk av en hovedlinjemodul.

Som et resultat må enheter som starter med Android 12 som kjører Linux-kjerne 5.10.43 eller nyere gjøre ett av følgende: ifølge Mishaal Rahman.

• Implementer et Google-signert oppstartsbilde

ELLER

• Distribuer et oppstartsbilde med en kjerne som eksporterer en KMI (Kernel Module Interface) som er et undersett av KMI eksportert av GKI, eksporterer et brukerroms-API som er et supersett av UAPI-en som er eksponert av GKI, og støtter alle funksjonene til den tilsvarende GKI-en versjon

Leverandører kan lage moduler som kobles til GKI, men ideen med GKI er at Google tar på seg ansvaret for å håndtere kjerneendringer. Kernel Module Interface (eller KMI, mer om dette i de senere delene av artikkelen) er i praksis der koden utenfor treet forventes å gå.

Google Pixel 6-serien lansert med Android 12 ut av esken og leveres med Linux-kjerne 5.10, og det er den første telefonen som leveres med en GKI. Fordi Google potensielt kan oppdatere kjernen gjennom Play Store, kan vi til og med se hyppige kjerneoppdateringer, ettersom LTS-kjerneoppdateringer vanligvis utgis ukentlig. Uansett er det et mye bedre system enn den for øyeblikket tungvinte metoden for oppdatering via OTA, selv om dette betyr at den iboende er knyttet til GMS-rammeverket.

Google definerer ganske enkelt GKI som følgende:

• Den er bygget fra ACK-kildene.
• Det er en enkeltkjerne binær pluss tilhørende lastbare moduler per arkitektur, per LTS-utgivelse (foreløpig kun arm64 for android11-5.4 og android12-5.4).
• Den er testet med alle Android-plattformutgivelser som støttes for den tilknyttede ACK. Det er ingen funksjonsavvikling for levetiden til en GKI-kjerneversjon
• Det eksponerer en stabil KMI for sjåfører innenfor en gitt LTS.
• Den inneholder ikke SoC eller tavlespesifikk kode.

Google ønsker til og med å være i en posisjon innen 2023 der den kan ta en "oppstrøms først" utviklingsmodell. Dette vil hjelpe Google med å sikre at ny kode lander først i hovedlinje Linux-kjernen, og reduserer "teknisk gjeld" påløpt kode utenfor treet på Android-enheter.

Kernel Module Interface (KMI)

Kernel Module Interface, eller KMI, er en del av Googles løsning på den pågående fragmenteringen i Android. I hovedsak er SoC og styrestøtte ikke lenger plassert i kjernekjernen, men flyttes i stedet inn i lastbare moduler. Både kjernen og modulene kan oppdateres uavhengig da, ettersom modulene oppdateres i /lib/modules. Selve GKI-en skal være så ren og generisk som mulig, noe som gjøres mulig ved å laste det som nå er utenfor treet-kode til separate moduler.

Som Ted Kjos forklart kl årets Linux Rørleggerkonferanse, "det store flerårige fremstøtet er å få all den maskinvarespesifikke koden ut av den generiske kjernen og inn i leverandørmoduler. Vi må ha et stabilt grensesnitt mellom disse leverandørmodulene og den generiske kjernen slik at de kan sendes asynkront." GKI 1.0 er egentlig en "overholdelsestest".

Faktisk betyr GKI-kompatibilitet at enheten består VTS- og CTS-on-GSI+GKI-testene med Generic System Image (GSI) og GKI-kjernen installert ved å blinke GKI-oppstartsbildet inn i oppstartspartisjonen og GSI-systembildet i systemet skillevegg. Vendor Test Suite, eller VTS, er en automatisert test som alle enheter må bestå for å anses som kompatible med Project Treble. Compatibility Test Suite, eller CTS, kreves for å få tilgang til Googles applikasjonspakke.

Enheter kan sendes med en annen produktkjerne og kan bruke lastbare moduler som GKI ikke tilbyr. Imidlertid må både produktet og GKI-kjernene laste inn moduler fra samme vendor_boot og vendor partisjoner. Derfor må alle produktkjerner ha det samme binære kjernemodulgrensesnittet (KMI).

Diagrammet ovenfor viser hva Google ønsker å gjøre, og forklarer hvordan den har tenkt å nå det. Generic Kernel- og GKI-modulene vil være en del av AOSP, og GKI kan kommunisere med Android-rammeverket og Hardware Abstraction Layer (HAL) som en leverandør kan implementere. Den spesifikke proprietære koden som en leverandør vil ha i kjernen (for eksempel kameradrivere) vil i stedet bli presset inn i en leverandørmodul som blir en utvidelse av GKI via KMI.

Hvordan GKI kan bidra til å løse Androids fragmenteringsproblem

Google har lagt ned mye arbeid i å effektivisere utviklingsprosessen for smarttelefoner. Hver OEM ønsker sin egen merkeidentitet, og hver OEM ønsker å kunne ha eierskap til enhetene sine. I motsetning til Android One-programmet, kan Android-smarttelefoner stort sett være hva de vil, så lenge de overholder regelverket som Google setter for å motta en GMS-lisens. Tidligere har Google imidlertid ikke gjort mye for å regjere i utviklingen av Android-enheter endringer som Project Treble, Mainline og nå GKI er mye nyere i Android historie.

Men vil det hjelpe? Det burde det gjøre, selv om det sannsynligvis blir en flerårig affære som bærer synlig frukt senere. Dette vil bare gjelde enheter som lanseres med Android 12, noe som betyr at vi kommer til å se enheter som ikke har en GKI i årene som kommer. Det var også en kritikk av Project Treble da det ble kunngjort, selv om åpenbart alle enheter som lanseres i dag støtter det. Disse tingene tar tid, og ettersom Google sakte tar styringen på Android, blir utviklingsprosessen lettere for alle OEM-er i Android-økosystemet, selv om noen av dem heller vil beholde full kontroll over Linux-kjernen som brukes på Android smarttelefoner.