A Google azt tervezi, hogy 2023-tól átáll egy "upstream first" fejlesztési modellre a Linux kernel funkcióihoz Androidban. Olvasson tovább, ha többet szeretne megtudni.
Amikor ugyanabban a mondatban látja az "Android" és a "töredezettség" szavakat, valószínűleg azonnal a Android verzió terjesztési táblázat. Van néhány entitás, amelyre a legtöbben ujjal mutogatnak, amikor arról panaszkodnak, hogy az Android operációs rendszer frissítései lassan jelennek meg, de a Google csak annyit tehet, hogy Kényszerítés Az OEM-ek gyorsabban fejleszthetik és terjeszthetik ki a frissítéseket. A Google azonban megteheti, hogy csökkenti a fejlesztési időt és ezáltal a frissítések kiadásának költségeit.
A Google fejlesztési terhek csökkentését célzó hosszú távú projektjének első jelentősebb kezdeményezése az Projekt Treble. Az Android 8.0 Oreo mellett 2017-ben bejelentett Project Treble modularizálta az Androidot azáltal, hogy elválasztotta az operációs rendszer keretrendszerét a gyártói megvalósítástól (HAL-ok és az eszközspecifikus Linux kernelfork). Ez megkönnyítette az Android OEM-ek számára, hogy a legújabb AOSP-keretrendszerre alapozzák operációs rendszereiket, mivel a gyártók frissített kódja nélkül tudták elindítani a legújabb verziót. Ennek eredményeként az OEM-ek a korábbinál gyorsabban elkészíthették egyéni Android-forgácsaikat, és ezen túlmenően gyorsabban terjeszthetik ki a főbb operációs rendszer-frissítéseket.
A Google terveinek következő lépése az volt, hogy egyszerűsítse a frissítések kézbesítését a legfontosabb Android-komponensekhez. A Google elnevezte ezt a kezdeményezést Projekt fővonal amikor 2019-ben bemutatta az Android 10 mellett. A Google lényegében átvette az irányítást az operációs rendszer kulcsfontosságú összetevői felett, és megtiltotta az OEM-eknek, hogy módosítsák azokat. Ezután beállítottak egy kézbesítési mechanizmust a Google Playen keresztül, hogy távolról telepíthessék ezekre a kulcsfontosságú összetevőkre vonatkozó frissítéseket anélkül, hogy meg kellene várniuk, míg az OEM-ek maguk telepítik a javításokat. A Mainline nagymértékben javította, hogy az eszközök milyen gyorsan kapják meg a fontos operációs rendszer-összetevők frissített verzióit, ezzel pedig javítva az Android ökoszisztéma egészének biztonságát.
De ami ezután következik, az még fontosabb, és vitathatatlanul a Google hosszú távú stratégiájának legfontosabb része. Amikor korábban rámutattunk, hogy a Treble hogyan modularizálta az Androidot az operációs rendszer keretrendszerének elválasztásával a szállító megvalósítása, az "eszköz-specifikus Linux kernel fork"-ot a szállító részeként felvettük kód. Bárki, aki ismeri a Linuxot asztali számítógépeken, felismeri a problémát: miért van a zárt forráskódú gyártói kódban egybeépítve? A probléma az, hogy míg az Android-eszközöket a Linux kernellel szállítják, ez a kernel rendelkezik a sok a fán kívüli kódból.
Hogyan kerültünk oda? A probléma, amint azt a Google szoftvermérnöke, Todd Kjos felvázolta az idei Linux vízvezeték-szerelők konferenciája (keresztül ArsTechnica), azért van, mert a fő Linux-kernelt többször elágazik, mielőtt Android-eszközre kiszállításra kerülne. A Google minden fő Linux kernelt egy "Android közös kernel" ág, amely szorosan követi a fő kiadást, de hozzáad néhány Android-specifikus javítást. Az olyan SoC-szállítók, mint a Qualcomm, a MediaTek és a Samsung, aztán elágaznak hogy kernel minden általuk készített SoC-hez. Az OEM-ek ezután veszik az adott SoC-specifikus kernelt, és további javításokat adnak hozzá, hogy megvalósítsák a szállítani kívánt hardver támogatását.
E változások miatt"Az eszközön futó kód akár 50%-a fán kívüli kód (nem az upstream Linux vagy AOSP általános kernelekből)", a Google szerint. A fán kívüli kódok nagy mennyisége ezeken az eszközökön hosszú és kihívásokkal teli folyamattá teszi az upstream változtatások összevonását. Ez káros az eszközök biztonságára nézve, mivel az OEM-eknek keményebben kell dolgozniuk a Linux kernelben felfedezett sebezhetőségek javításán. Ezenkívül ez a legtöbb Android-eszközön több éves kernel-kiadáson marad, ami azt jelenti, hogy lemaradnak az új Linux-kernel-funkciókról.
A probléma megoldása érdekében a Google az Android Generic Kernel Image-en (GKI) dolgozik, amely lényegében egy ACK-ágból közvetlenül összeállított kernel. A GKI elkülöníti az SoC-szállító és az OEM testreszabásait a beépülő modulokhoz, így kiküszöböli a fán kívüli kódot, és lehetővé teszi a Google számára, hogy a kernelfrissítéseket közvetlenül a végfelhasználóhoz küldje. A Google több mint egy éve dolgozik azon, hogy a GKI-frissítéseket a Play Áruházban szállíthassa, fővonali modul használatával.
Forrásaink szerint olyan eszközök, amelyek a Android 12 és az 5.10-es Linux kernellel szállítva, telepítenie kell a Google által aláírt rendszerindító lemezképet. A Google sajátja Pixel 6 A sorozat Android 12-vel indul, és 5.10-es Linux kernellel fog megjelenni, így a két telefon lehet az első olyan tömegpiaci eszköz, amelyet GKI-vel szállítanak.
Ezenkívül a Google munkatársa, Todd Kjos felfedte, hogy a vállalat azt tervezi, hogy az új Linux-kernel-szolgáltatások "először upstream" fejlesztési modelljére tér át. Ez segíteni fogja a Google-t annak biztosításában, hogy az új kód elsőként kerüljön be a fő Linux kernelbe, ami csökkenti a jövőbeni technikai adósságokat, ha több fán kívüli kód landol Android-eszközökön.
A héten a Linux vízvezeték-szerelők konferenciáján Kjos elmondta: "Mivel a fán kívüli modulok nagyon fontosak a mi használati esetünkben, arra számítunk, hogy mindig lesz egy sor exportálásunk, és vannak olyan dolgok, amelyek különböznek, vagy kiegészítik azt, ami felfelé, de ez az egész projekt egy több éves projekt, amely azon fáradozik, hogy a lehető legtöbb fán kívüli folttól megszabaduljunk, és a lehető legjobban igazodjunk a felfelé." A Google arra törekszik, hogy 2022 végéig befejezze a meglévő funkciók upstreamelése és a szállítóváltások elkülönítése érdekében végzett munkáját és 2023-tól kezdődően a vállalat azt tervezi, hogy alkalmazza ezt az „először upstream” fejlesztési modellt, hogy elkerülje az ilyen problémákat a jövő.