Googles generiske kernebillede er det næste skridt mod at løse Androids fragmenteringsproblem

Google har arbejdet på at reducere fragmentering på Android i årevis, selvom en del af årsagen til det er Androids iboende natur og det tveæggede sværd af valg og frihed. Der er utallige OEM'er aktive i rummet, og de ønsker alle at lave deres egne modifikationer til deres egne enheder. Problemet er så, at det ser ud til, at Android OS-opdateringer er langsomme til at rulle ud over hele linjen, men der er ikke meget, som Google faktisk kan gøre for at tvinge OEM'er til at opdatere deres enheder. Som sådan er den næstbedste ting, Google kan gøre, at gøre opdateringsprocessen så let og friktionsfri som muligt.

Lindring af Android-opdateringssmerter

Det første store initiativ i Googles langsigtede projekt for at reducere udviklingsbyrden var Projekt Diskant. Project Treble blev annonceret sammen med Android 8.0 Oreo i 2017, og modulariserede Android ved at adskille OS-rammen fra leverandørimplementeringen (HAL'er og den enhedsspecifikke Linux-kernegaffel). Dette gjorde det lettere for Android OEM'er at rebase deres OS'er oven på den nyeste AOSP-ramme, da de kunne starte den nyeste version uden at skulle have opdateret kode fra leverandører. Som et resultat kunne OEM'er klargøre deres tilpassede Android-gafler hurtigere end før, og i forlængelse heraf udrulle større OS-opdateringer hurtigere.

Det næste trin i Googles planer var at strømline leveringen af ​​opdateringer til vigtige Android-komponenter. Google kaldte dette initiativ Projekt Hovedlinje da den introducerede det sammen med Android 10 i 2019. Google tog i bund og grund kontrol over vigtige OS-komponenter og forbyder OEM'er at ændre dem. De satte derefter en leveringsmekanisme op via Google Play, så de kunne fjernudrulle opdateringer til disse nøglekomponenter uden at skulle vente på, at OEM'er selv anvender programrettelserne. Mainline forbedrede i høj grad, hvor hurtigt enheder modtager opdaterede versioner af vigtige OS-komponenter, hvilket igen forbedrer sikkerheden for Android-økosystemet som helhed.

Når det kommer til Diskant, burde Linux-kernen realistisk set ikke klumpes ind med lukket kildekode. Todd Kjos kl dette års Linux Plumbers Conference har tidligere forklaret de vanskeligheder, der står over for, når det kommer til fragmentering på Android, og meget af det er nu centreret omkring Linux-kernen, som OEM'er sender med deres enheder. Til kontekst gafler Google hver hovedlinje Linux-kerne til en "Android Common Kernel” (ACK) gren, som nøje følger mainline-udgivelsen, men tilføjer et par Android-specifikke patches. SoC-leverandører som Qualcomm, MediaTek og Samsung gaffel derefter at kerne for hver SoC, de laver. OEM'er tager derefter den SoC-specifikke kerne og tilføjer yderligere patches for at implementere support til den specifikke hardware, de vil sende.

Ovenstående diagram viser, hvordan en enheds kerne går gennem adskillige ændringer, der abstraherer den langt fra Linux LTS-kernen. For at forenkle det starter vi med Linux-kernen, og den bliver flettet ind i Android Common Kernel med nogle få ændringer. Derfra bliver Android Common Kernel fusioneret til en leverandørkerne (Qualcomm, MediaTek osv.) med sine egne modifikationer og ændringer. Til sidst fusioneres leverandørkernen til en OEM's enhedsspecifikke kerne. På dette stadium er enhver enheds kerne langt væk fra den Linux LTS-kerne, den startede med.

Som et resultat af alle disse gafler er så meget som 50 % af koden, der kører på en Android-enhed, kode uden for træet, hvilket betyder, at den ikke er fra upstream Linux eller AOSP almindelige kerner. Dette gør det utroligt vanskeligt (for ikke at nævne tidskrævende og dyrt) at slå opstrømsændringer sammen. For OEM'er er der ikke noget incitament til at gøre det, men den praksis kan være skadelig for enhedssikkerheden. Det er også grunden til, at mange Android-enheder er tilbage på ældre LTS-kerneudgivelser, hvilket har den bivirkning, at enheder mister adgangen til nye Linux-kernefunktioner.

Android er fragmenteret, og Google ved det

Google ved godt, at dette er et problem, og har endda et afsnit kaldet "Omkostningerne ved fragmentering" i Android-udviklerdokumentationen. Google siger det "de fleste flagskibsenheder leveres med en kerneversion, der allerede er mindst 18 måneder gammel". Endnu værre, Google siger også det "Android 10 understøtter 3.18, 4.4, 4.9, 4.14 og 4.19 kerner, som i nogle tilfælde ikke er blevet forbedret med nye funktioner siden Android 8 i 2017." Dette gør det vanskeligt at tilføje funktioner, der kræver nye Linux-kerneversioner. Linux-kernen 3.18 blev lanceret i december 2014, dengang Android 5.0 Lollipop var den seneste version af Android. Det er helt klart et problem og kan holde platformen tilbage.

For eksempel er Code Aurora Forum, eller CAF for kort, vært for kildekoden til forskellige Qualcomm Snapdragon SoC'er. Qualcomm, som en SoC leverandør, distribuerer en splittet version af Linux-kernen til OEM'er/ODM'er, og disse virksomheder tilføjer derefter enhedsspecifikke ændringer på forsendelsen enheder. Det er det, der tilføjer flere lag af fragmentering. Derudover foretager Qualcomm ændringer i AOSP-rammerne for at optimere Android til hver af virksomhedens Snapdragon-mobilplatforme. Qualcomm distribuerer privat sin modificerede Linux-kerne, AOSP-framework og andre softwareværktøjer til sine partnere som en del af en Board Support Package eller BSP. CAF er det sted, hvor Qualcomm offentligt offentliggør disse Linux-kerneændringer og AOSP-rammeændringer.

Denne CAF-udgivelse kan være nyttig for brugerdefinerede ROM-udviklere, der ønsker at bruge den som udgangspunkt i stedet for ren AOSP, hvorfor du nogle gange ser "CAF-baserede" ROM'er på vores fora. Husker du Snapdragon 625, der så ud til at drive så mange mellemklassesmartphones i årevis? Det blev lanceret med Linux Kernel 3.18, og først i slutningen af ​​2018 (to år efter lanceringen af ​​chipsættet) opdaterede Qualcomm kernekilderne og udgav dem på CAF til msm8953 (chipsættets navn på Snapdragon 625), hvilket giver understøttelse af Linux Kernel 4.9. Problemet er, at de fleste OEM'er vil ikke opdatere telefoner til denne nye Linux-kerneversion, især ikke mellemklassetelefoner to år efter chippen blev frigivet. Det er ganske vist meget sjældent, at sådan en større kerneopdatering overhovedet sker i første omgang, men pointen er, at det har sket, så det er ikke bare et umuligt scenarie.

Alt i alt er den nuværende fragmentering i Android noget rod, for at sige det let. Googles seneste forsøg på at rette op på denne fragmentering kommer i form af det generiske kernebillede eller GKI.

Introduktion til det generiske kernebillede

For at imødegå denne fragmentering arbejdede Google på Android Generic Kernel Image (GKI). Dette er i bund og grund en kerne kompileret direkte fra en ACK-gren. GKI'en isolerer SoC-leverandør og OEM-tilpasninger til plugin-moduler, fjerner kode uden for træet og tillader Google at skubbe kerneopdateringer direkte til slutbrugeren. I over et år har Google arbejdet på en måde at levere GKI-opdateringer via Play Butik, ved brug af et Mainline-modul.

Som følge heraf skal enheder, der starter med Android 12, der kører Linux-kerne 5.10.43 eller nyere, gøre et af følgende, ifølge Mishaal Rahman.

• Implementer et Google-signeret boot-image

ELLER

• Implementer et boot-image med en kerne, der eksporterer en KMI (Kernel Module Interface), som er en delmængde af KMI'et eksporteret af GKI'en, eksporterer en brugerrums-API, der er et supersæt af UAPI'en, der er eksponeret af GKI'en, og understøtter alle funktioner i den tilsvarende GKI version

Leverandører kan oprette moduler, der tilsluttes GKI'en, men ideen med GKI'en er, at Google påtager sig ansvaret for at håndtere kerneændringer. Kernel Module Interface (eller KMI, mere om dette i de senere dele af artiklen) er faktisk der, hvor out-of-tree kode forventes at gå.

Google Pixel 6-serien lanceret med Android 12 ud af æsken og leveres med Linux-kerne 5.10, og det er den første telefon, der leveres med en GKI. Fordi Google potentielt kan opdatere kernen gennem Play Butik, kan vi endda se hyppige kerneopdateringer, da LTS-kerneopdateringer typisk udgives ugentligt. Uanset hvad, er det et meget bedre system end den aktuelt besværlige metode til opdatering via OTA, selvom det betyder, at det i sagens natur er bundet til GMS-rammerne.

Google definerer simpelthen GKI som følgende:

• Det er bygget ud fra ACK-kilderne.
• Det er en single-kernel binær plus tilhørende indlæsbare moduler pr. arkitektur, pr. LTS-udgivelse (i øjeblikket kun arm64 for android11-5.4 og android12-5.4).
• Det er testet med alle Android Platform-udgivelser, der understøttes for den tilknyttede ACK. Der er ingen udfasning af funktioner i en GKI-kerneversions levetid
• Det eksponerer en stabil KMI for chauffører inden for en given LTS.
• Den indeholder ikke SoC eller tavlespecifik kode.

Google ønsker endda at være i en position i 2023, hvor den kan tage en "upstream first"-udviklingsmodel. Dette vil hjælpe Google med at sikre, at ny kode lander først i mainline Linux-kernen, hvilket reducerer "teknisk gæld" påløbet kode uden for træet på Android-enheder.

Kernel Module Interface (KMI)

Kernel Module Interface, eller KMI, er en del af Googles løsning på den igangværende fragmentering i Android. I det væsentlige er SoC og board-understøttelse ikke længere placeret i kernekernen og flyttes i stedet ind i indlæsbare moduler. Både kernen og modulerne kan derefter opdateres uafhængigt, efterhånden som modulerne opdateres i /lib/modules. Selve GKI'en formodes at være så ren og generisk som muligt, hvilket er gjort muligt ved at overføre, hvad der nu er out-of-tree-kode, til separate moduler.

Som Ted Kjos forklaret kl dette års Linux Plumbers Conference, "det store flerårige fremstød er at få al den hardwarespecifikke kode ud af den generiske kerne og ind i leverandørmoduler. Vi skal have en stabil grænseflade mellem disse leverandørmoduler og den generiske kerne, så de kan sendes asynkront." GKI 1.0 er i bund og grund en "compliance test".

Faktisk betyder GKI-kompatibilitet, at enheden består VTS- og CTS-on-GSI+GKI-testene med det generiske systembillede (GSI) og GKI-kernen installeret ved at flashe GKI-startbilledet ind i boot-partitionen og GSI-systembilledet i systemet skillevæg. Vendor Test Suite, eller VTS, er en automatiseret test, som alle enheder skal bestå for at blive betragtet som kompatible med Project Treble. Compatibility Test Suite, eller CTS, er påkrævet for at få adgang til Googles suite af applikationer.

Enheder kan sendes med en anden produktkerne og kan bruge indlæsbare moduler, som GKI ikke leverer. Imidlertid skal både produkt- og GKI-kernerne indlæse moduler fra de samme vendor_boot og vendor partitioner. Derfor skal alle produktkerner have den samme binære kernemodulgrænseflade (KMI).

Ovenstående diagram viser, hvad Google har lyst at gøre, og forklarer, hvordan den agter at nå det. De generiske kerne- og GKI-moduler vil være en del af AOSP, og GKI kan kommunikere med Android-frameworket og Hardware Abstraction Layer (HAL), som en leverandør kan implementere. Den specifikke proprietære kode, som en leverandør ønsker i kernen (for eksempel kameradrivere), vil i stedet blive skubbet ind i et leverandørmodul, der bliver en udvidelse af GKI'en via KMI'en.

Hvordan GKI kan hjælpe med at løse Androids fragmenteringsproblem

Google har lagt meget arbejde i at strømline udviklingsprocessen for smartphones. Enhver OEM ønsker sin egen mærkeidentitet, og enhver OEM ønsker at være i stand til at have ejerskab til sine enheder. I modsætning til Android One-programmet kan Android-smartphones stort set være, hvad de vil, så længe de overholder det regelsæt, som Google opstiller for at modtage en GMS-licens. Men tidligere har Google ikke gjort meget for at regere i udviklingen af ​​Android-enheder ændringer som Project Treble, Mainline og nu GKI'en er meget nyere i Android's historie.

Men vil det hjælpe? Det burde det gøre, selvom det sandsynligvis bliver en flerårig affære, der bærer synlige frugter senere hen. Dette gælder kun for enheder, der starter med Android 12, hvilket betyder, at vi kommer til at se enheder, der ikke har en GKI i de kommende år. Det var også en kritik af Project Treble, da det blev annonceret, selvom alle enheder, der lanceres i dag, naturligvis understøtter det. Disse ting tager tid, og efterhånden som Google langsomt trækker herredømmet over Android, bliver udviklingsprocessen lettet for alle OEM'er i Android-økosystemet, selvom nogle af dem hellere vil beholde fuld kontrol over Linux-kernen, der bruges på Android smartphones.