Google is van plan om vanaf 2023 over te stappen op een ‘upstream first’-ontwikkelingsmodel voor Linux-kernelfuncties in Android. Lees verder voor meer informatie.
Wanneer je de woorden 'Android' en 'fragmentatie' in dezelfde zin ziet, springen je gedachten waarschijnlijk onmiddellijk naar de Distributiediagram voor Android-versies. Er zijn een paar entiteiten waar de meeste mensen naar wijzen als ze klagen dat Android OS-updates traag over de hele linie worden uitgerold, maar Google kan er maar zoveel aan doen kracht OEM's kunnen updates sneller ontwikkelen en uitrollen. Wat Google wel kan doen, is de ontwikkeltijd en daarmee de kosten voor het uitrollen van updates verkorten.
Het eerste grote initiatief in het langetermijnproject van Google om de ontwikkelingslasten te verminderen is 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.
Maar wat daarna komt is zelfs nog belangrijker, en misschien wel het belangrijkste onderdeel van de langetermijnstrategie van Google. Toen we er eerder op wezen hoe Treble Android modulair maakte door het OS-framework te scheiden van de implementatie van de leverancier, hebben we de "apparaatspecifieke Linux-kernelvork" opgenomen als onderdeel van die leverancier code. Iedereen die bekend is met Linux op desktops zal daar een probleem herkennen: waarom wordt het op één hoop gegooid met closed-source leverancierscode? Het probleem is dat hoewel Android-apparaten worden geleverd met de Linux-kernel, deze kernel beschikt over een kavel van out-of-tree-code.
Hoe zijn we daar terechtgekomen? Het probleem, zoals beschreven door Google-software-ingenieur Todd Kjos op de Linux Plumbers Conference van dit jaar (via ArsTechnica), komt doordat de belangrijkste Linux-kernel verschillende keren wordt gevorkt voordat deze op een Android-apparaat wordt verzonden. Google splitst elke hoofdlijn Linux-kernel op in een "Android gemeenschappelijke kernel" 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.
Door deze veranderingen "maar liefst 50% van de code die op een apparaat draait, is code buiten de boomstructuur (niet van upstream Linux of algemene AOSP-kernels)", aldus Google. De grote hoeveelheid out-of-tree-code op deze apparaten maakt het samenvoegen van upstream-wijzigingen een lang en uitdagend proces. Dit is schadelijk voor de apparaatbeveiliging, omdat OEM's harder moeten werken om patches te implementeren voor kwetsbaarheden die in de Linux-kernel zijn ontdekt. Bovendien blijven de meeste Android-apparaten hierdoor achter op jaren oude kernelreleases, wat betekent dat ze nieuwe Linux-kernelfuncties missen.
In een poging dit probleem aan te pakken, werkt Google aan de Android Generic Kernel Image (GKI), die in wezen een kernel is die rechtstreeks vanuit een ACK-tak 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.
Volgens onze bronnen zijn apparaten die starten met Androïde 12 en geleverd met Linux-kernel 5.10 moet een door Google ondertekende opstartimage implementeren. Google's eigen Pixel6 -serie wordt standaard gelanceerd met Android 12 en geleverd met Linux-kernel 5.10, dus de twee telefoons kunnen de eerste massamarktapparaten zijn die worden geleverd met een GKI.
Bovendien onthulde Todd Kjos van Google dat het bedrijf van plan is over te stappen op een "upstream first" ontwikkelingsmodel voor nieuwe Linux-kernelfuncties. Dit zal Google helpen ervoor te zorgen dat nieuwe code als eerste in de hoofdlijn Linux-kernel terechtkomt, waardoor de toekomstige technische schulden zullen worden verminderd die voortvloeien uit meer out-of-tree code die op Android-apparaten terechtkomt.
Op de Linux Plumbers Conference deze week zei Kjos: "Omdat out-of-tree-modules erg belangrijk zijn voor onze use case, verwachten we dat we altijd een reeks exports zullen hebben en een aantal dingen die anders zijn of een aanvulling vormen op wat er is stroomopwaarts, maar dit hele project is een meerjarig project dat eraan werkt om zoveel mogelijk plekken die buiten de boom vallen te verwijderen, en zoveel mogelijk af te stemmen op stroomopwaarts." Google streeft ernaar zijn werkzaamheden voor het upstreamen van bestaande functies en het isoleren van leverancierswijzigingen tegen eind 2022 af te ronden en het bedrijf is van plan om vanaf 2023 dit ‘upstream first’-ontwikkelingsmodel over te nemen om dergelijke problemen in de toekomst te voorkomen. toekomst.