Google's Generic Kernel Image heeft tot doel het probleem van fragmentatie in Android op te lossen, ook al is het een ingewikkeld onderwerp. Dit is hoe het werkt.
Google werkt al jaren aan het terugdringen van de fragmentatie op Android, hoewel een deel van de oorzaak daarvan de inherente aard van Android en het tweesnijdende zwaard van keuze en vrijheid is. Er zijn talloze OEM's actief in de sector, en ze willen allemaal hun eigen aanpassingen aan hun eigen apparaten maken. Het probleem is dan dat het erop lijkt dat Android OS-updates langzaam over de hele linie worden uitgerold, maar Google kan niet veel doen om OEM's te dwingen hun apparaten bij te werken. Het beste wat Google kan doen is het updateproces zo eenvoudig en soepel mogelijk maken.
De pijn bij de Android-update verzachten
Het eerste grote initiatief in het langetermijnproject van Google om de ontwikkelingslast te verminderen was Project Treble. Project Treble werd in 2017 samen met Android 8.0 Oreo aangekondigd en heeft Android gemodulariseerd door het OS-framework te scheiden van de leveranciersimplementatie (HAL's en de apparaatspecifieke Linux-kernelvork). Dit maakte het voor Android-OEM's gemakkelijker om hun besturingssystemen opnieuw te baseren op het nieuwste AOSP-framework, omdat ze de nieuwste versie konden opstarten zonder bijgewerkte code van leveranciers nodig te hebben. Als gevolg hiervan konden OEM's hun aangepaste Android-vorken sneller klaarmaken dan voorheen, en bij uitbreiding grote OS-updates sneller uitrollen.
De volgende stap in de plannen van Google was het stroomlijnen van de levering van updates voor belangrijke Android-componenten. Google noemde dit initiatief Project Hoofdlijn toen het het in 2019 naast Android 10 introduceerde. Google nam in wezen de controle over de belangrijkste OS-componenten over en verbood OEM's deze te wijzigen. Vervolgens zetten ze een leveringsmechanisme op via Google Play, zodat ze op afstand updates voor deze belangrijke componenten konden uitrollen zonder te hoeven wachten tot OEM's de patches zelf hadden toegepast. Mainline heeft de snelheid waarmee apparaten bijgewerkte versies van belangrijke OS-componenten ontvangen aanzienlijk verbeterd, waardoor de beveiliging van het Android-ecosysteem als geheel is verbeterd.
Als het echter om Treble gaat, zou de Linux-kernel realistisch gezien niet op één hoop moeten worden gegooid met closed-source leverancierscode. Todd Kjos op de Linux Plumbers Conference van dit jaar heeft in het verleden de problemen uitgelegd waarmee we te maken krijgen als het gaat om fragmentatie op Android, en een groot deel daarvan concentreert zich nu rond de Linux-kernel die OEM's met hun apparaten leveren. Voor de context splitst Google elke hoofdlijn Linux-kernel op in een “Android gemeenschappelijke kernel” (ACK) branch, die de hoofdrelease nauwlettend volgt, maar een paar Android-specifieke patches toevoegt. SoC-leveranciers zoals Qualcomm, MediaTek en Samsung splitsen zich vervolgens af Dat kernel voor elke SoC die ze maken. OEM's nemen vervolgens die SoC-specifieke kernel en voegen extra patches toe om ondersteuning te implementeren voor de specifieke hardware die ze willen leveren.
Het bovenstaande diagram laat zien hoe de kernel van een apparaat verschillende lagen van verandering doorloopt, waardoor deze ver verwijderd is van de Linux LTS-kernel. Om het te vereenvoudigen, beginnen we met de Linux Kernel, en deze wordt met een paar wijzigingen samengevoegd met de Android Common Kernel. Van daaruit wordt de Android Common Kernel samengevoegd tot een leverancierskernel (Qualcomm, MediaTek, enz.) met zijn eigen aanpassingen en wijzigingen. Ten slotte wordt de leverancierskernel samengevoegd met de apparaatspecifieke kernel van een OEM. In dit stadium is de kernel van elk apparaat ver verwijderd van de Linux LTS-kernel waarmee het begon.
Als resultaat van al deze forks is maar liefst 50% van de code die op een Android-apparaat draait code die niet in de boomstructuur voorkomt, wat betekent dat deze niet afkomstig is van upstream Linux- of AOSP-gemeenschappelijke kernels. Dit maakt het ongelooflijk moeilijk (om nog maar te zwijgen van tijdrovend en kostbaar) om upstream-veranderingen samen te voegen. Voor OEM's is er geen reden om dit te doen, maar deze praktijk kan schadelijk zijn voor de apparaatbeveiliging. Dit is ook de reden waarom veel Android-apparaten op oudere LTS-kernelreleases blijven staan, wat als neveneffect heeft dat apparaten de toegang tot nieuwe Linux-kernelfuncties verliezen.
Android is gefragmenteerd en Google weet dat
Google weet heel goed dat dit een probleem is en heeft zelfs een sectie met de naam 'De kosten van fragmentatie" in de Android-ontwikkelaarsdocumentatie. Google zegt dat "de meeste vlaggenschipapparaten worden geleverd met een kernelversie die al minstens 18 maanden oud is". Erger nog, Google zegt dat ook "Android 10 ondersteunt 3.18, 4.4, 4.9, 4.14 en 4.19 kernels, die in sommige gevallen niet zijn uitgebreid met nieuwe functies sinds Android 8 in 2017." Dit maakt het moeilijk om functies toe te voegen waarvoor nieuwe Linux-kernelversies nodig zijn. Linux kernel 3.18 werd gelanceerd in december 2014, toen Android 5.0 Lollipop de nieuwste versie van Android was. Dat is duidelijk een probleem en kan het platform tegenhouden.
Code Aurora Forum, kortweg CAF, host bijvoorbeeld de broncode voor verschillende Qualcomm Snapdragon SoC's. Qualcomm, als SoC leverancier, distribueert een gevorkte versie van de Linux-kernel onder OEM's/ODM's, en die bedrijven voegen vervolgens apparaatspecifieke wijzigingen toe bij de verzending apparaten. Dit is wat verschillende lagen van fragmentatie toevoegt. Daarnaast brengt Qualcomm wijzigingen aan in het AOSP-framework om Android te optimaliseren voor elk van de mobiele Snapdragon-platforms van het bedrijf. Qualcomm distribueert zijn aangepaste Linux-kernel, AOSP-framework en andere softwaretools privé aan zijn partners als onderdeel van een Board Support Package of BSP. CAF is de plek waar Qualcomm deze Linux-kernelwijzigingen en AOSP-frameworkwijzigingen publiekelijk publiceert.
Deze CAF-uitgave kan nuttig zijn voor ontwikkelaars van aangepaste ROM's die deze als startpunt willen gebruiken in plaats van pure AOSP. Daarom zie je soms “CAF-gebaseerde” ROM's op onze forums. Herinner je je de Snapdragon 625 nog, die jarenlang zoveel smartphones uit het middensegment leek aan te drijven? Dat werd gelanceerd met Linux Kernel 3.18, en pas tegen het einde van 2018 (twee jaar na de lancering van de chipset) heeft Qualcomm de kernelbronnen bijgewerkt en gepubliceerd op CAF voor msm8953 (de chipsetnaam van de Snapdragon 625) die ondersteuning biedt voor Linux Kernel 4.9. Het probleem is dat de meeste OEM's zal geen telefoons updaten naar deze nieuwe Linux-kernelversie, vooral geen telefoons uit het middensegment twee jaar nadat de chip was verschenen uitgegeven. Toegegeven, het komt zelden voor dat een dergelijke grote kernelupdate überhaupt plaatsvindt, maar het punt is dat het heeft is gebeurd, dus het is niet alleen een onmogelijk scenario.
Al met al is de huidige fragmentatie in Android op zijn zachtst gezegd een puinhoop. De nieuwste pogingen van Google om deze fragmentatie op te lossen komen in de vorm van de Generic Kernel Image, oftewel de GKI.
Introductie van de generieke kernelimage
Om deze fragmentatie aan te pakken, heeft Google gewerkt aan de Android Generic Kernel Image (GKI). Dit is in wezen een kernel die rechtstreeks vanuit een ACK-branch is gecompileerd. De GKI isoleert SoC-leveranciers en OEM-aanpassingen in plug-inmodules, waardoor out-of-tree-code wordt geëlimineerd en Google kernelupdates rechtstreeks naar de eindgebruiker kan pushen. Google werkt al ruim een jaar aan een manier om GKI-updates via de Play Store aan te bieden, door het gebruik van een Mainline-module.
Als gevolg hiervan moeten apparaten die worden gestart met Android 12 en waarop Linux-kernel 5.10.43 of hoger wordt uitgevoerd, een van de volgende handelingen uitvoeren: volgens Mishaal Rahman.
- Implementeer een door Google ondertekende opstartimage
OF
- Implementeer een opstartimage met een kernel die een KMI (Kernel Module Interface) exporteert die een subset is van de KMI die door de GKI wordt geëxporteerd, exporteert een gebruikersruimte-API die een superset is van de UAPI die wordt weergegeven door de GKI, en die alle functies van de overeenkomstige GKI ondersteunt versie
Leveranciers kunnen modules maken die op de GKI aansluiten, maar het idee van de GKI is dat Google de verantwoordelijkheid op zich neemt voor het afhandelen van kernelwijzigingen. De Kernel Module Interface (of KMI, meer hierover in de latere delen van het artikel) is feitelijk de plek waar out-of-tree-code naar verwachting naartoe gaat.
De Google Pixel 6-serie werd standaard gelanceerd met Android 12 en wordt geleverd met Linux-kernel 5.10, en het is de eerste telefoon die wordt geleverd met een GKI. Omdat Google de kernel mogelijk via de Play Store zou kunnen updaten, kunnen we zelfs regelmatig kernelupdates zien. aangezien LTS-kernelupdates doorgaans wekelijks worden uitgebracht. Hoe dan ook, het is een veel beter systeem dan de momenteel omslachtige methode van updaten via OTA, hoewel dit wel betekent dat het inherent verbonden is met het GMS-framework.
Google definieert de GKI eenvoudigweg als volgt:
- Het is opgebouwd uit de ACK-bronnen.
- Het is een binair bestand met één kernel plus bijbehorende laadbare modules per architectuur, per LTS-release (momenteel alleen arm64 voor
android11-5.4Enandroid12-5.4). - Het is getest met alle Android Platform-releases die worden ondersteund voor de bijbehorende ACK. Er is geen beëindiging van functies gedurende de levensduur van een GKI-kernelversie
- Het biedt bestuurders binnen een bepaalde LTS een stabiele KMI.
- Het bevat geen SoC of bordspecifieke code.
Google wil tegen 2023 zelfs in een positie verkeren waarin het een ‘upstream first’ ontwikkelingsmodel kan hanteren. Dit zal Google helpen ervoor te zorgen dat nieuwe code als eerste in de hoofdlijn Linux-kernel terechtkomt, waardoor de "technische schulden" die buiten de boomcode op Android-apparaten zijn opgebouwd, worden verminderd.
De kernelmodule-interface (KMI)
De Kernel Module Interface, of KMI, maakt deel uit van Google's oplossing voor de voortdurende fragmentatie in Android. In wezen bevinden SoC- en bordondersteuning zich niet langer in de kernkernel, maar worden ze in plaats daarvan verplaatst naar laadbare modules. Zowel de kernel als de modules kunnen dan onafhankelijk worden bijgewerkt, terwijl modules worden bijgewerkt in /lib/modules. De GKI zelf moet zo schoon en generiek mogelijk zijn, wat mogelijk wordt gemaakt door wat nu out-of-tree-code is, over te brengen naar afzonderlijke modules.
Zoals Ted Kjos uitgelegd bij op de Linux Plumbers Conference van dit jaar, "is de grote, meerjarige inspanning om alle hardwarespecifieke code uit de generieke kernel en in leveranciersmodules te krijgen. We moeten een stabiele interface hebben tussen die leveranciersmodules en de generieke kernel, zodat ze asynchroon kunnen worden verzonden." GKI 1.0 is in wezen een "compliancetest".
GKI-compatibiliteit betekent in feite dat het apparaat de VTS- en CTS-on-GSI+GKI-tests met de Generic System Image (GSI) doorstaat en de GKI-kernel geïnstalleerd door de GKI-opstartimage naar de opstartpartitie en de GSI-systeemimage in het systeem te flashen partitie. De Vendor Test Suite, of VTS, is een geautomatiseerde test waaraan alle apparaten moeten slagen om als compatibel met Project Treble te worden beschouwd. De Compatibility Test Suite, of CTS, is vereist om toegang te krijgen tot het applicatiepakket van Google.
Apparaten kunnen worden geleverd met een andere productkernel en kunnen laadbare modules gebruiken die GKI niet levert. Zowel de product- als de GKI-kernels moeten echter modules laden van dezelfde Vendor_boot- en Vendor-partities. Daarom moeten alle productkernels dezelfde binaire kernelmodule-interface (KMI) hebben.
Het bovenstaande diagram laat zien wat Google wil te doen, en legt uit hoe zij dat wil bereiken. De Generic Kernel- en GKI-modules zullen deel uitmaken van AOSP, en de GKI kan communiceren met het Android-framework en de Hardware Abstraction Layer (HAL) die een leverancier kan implementeren. De specifieke bedrijfseigen code die een leverancier in de kernel wil hebben (bijvoorbeeld camerastuurprogramma's) zal in plaats daarvan in een leveranciersmodule worden gepusht die via de KMI een uitbreiding van de GKI wordt.
Hoe de GKI het fragmentatieprobleem van Android kan helpen oplossen
Google heeft veel werk gestoken in het stroomlijnen van het ontwikkelingsproces van smartphones. Elke OEM wil zijn eigen merkidentiteit en elke OEM wil eigenaar kunnen zijn van zijn apparaten. In tegenstelling tot het Android One-programma kunnen Android-smartphones vrijwel alles zijn wat ze willen, zolang ze zich maar houden aan de regels die Google stelt om een GMS-licentie te krijgen. In het verleden heeft Google echter niet veel gedaan om de ontwikkeling van Android-apparaten te beheersen veranderingen zoals Project Treble, Mainline en nu is de GKI een stuk recenter in Android geschiedenis.
Maar zal het helpen? Dat zou moeten lukken, ook al wordt het waarschijnlijk een meerjarige aangelegenheid die later zichtbaar resultaat zal opleveren. Dit geldt alleen voor apparaten die starten met Android 12, wat betekent dat we de komende jaren apparaten zullen zien die geen GKI hebben. Dat was ook kritiek op Project Treble toen dat werd aangekondigd, hoewel alle apparaten die tegenwoordig op de markt komen dit uiteraard ondersteunen. Deze zaken vergen tijd, en naarmate Google langzaam de regie over Android overneemt, wordt het ontwikkelingsproces voor alle OEM's in de wereld versoepeld. het Android-ecosysteem, ook al zouden sommigen van hen liever de volledige controle behouden over de Linux-kernel die op Android wordt gebruikt smartphones.