Imaginea generică Kernel de la Google este următorul pas către rezolvarea problemei de fragmentare a Android

Google a lucrat la reducerea fragmentării pe Android de ani de zile, deși o parte a cauzei este natura inerentă a Androidului și sabia cu două tăișuri a alegerii și libertății. Există nenumărați OEM-uri activi în spațiu și toți doresc să-și facă propriile modificări pentru propriile dispozitive. Problema este atunci că se pare că actualizările sistemului de operare Android întârzie să se difuzeze peste tot, dar Google nu poate face prea multe pentru a forța OEM-urile să-și actualizeze dispozitivele. Ca atare, cel mai bun lucru pe care Google îl poate face este să facă procesul de actualizare cât mai ușor și fără fricțiuni posibil.

Ușurează durerea de actualizare Android

Prima inițiativă majoră din proiectul pe termen lung al Google de reducere a sarcinii de dezvoltare a fost Proiect Treble. Anunțat împreună cu Android 8.0 Oreo în 2017, Project Treble a modularizat Android, separând cadrul sistemului de operare de implementarea furnizorului (HAL-uri și kernel-ul Linux specific dispozitivului). Acest lucru a făcut mai ușor pentru OEM-urile Android să-și rebazeze sistemele de operare peste cel mai recent cadru AOSP, deoarece puteau porni cea mai recentă versiune fără a avea nevoie de cod actualizat de la furnizori. Drept urmare, producătorii de echipamente originale și-ar putea pregăti furcile Android personalizate mai repede decât înainte și, prin extensie, pot lansa actualizări majore ale sistemului de operare mai rapid.

Următorul pas în planurile Google a fost să eficientizeze livrarea actualizărilor componentelor cheie Android. Google a numit această inițiativă Linia principală a proiectului când l-a introdus alături de Android 10 în 2019. În esență, Google a preluat controlul asupra componentelor cheie ale sistemului de operare și a interzis OEM-urilor să le modifice. Apoi au configurat un mecanism de livrare prin Google Play, astfel încât să poată lansa de la distanță actualizări pentru aceste componente cheie, fără a fi nevoie să aștepte ca OEM-urile să aplice ei înșiși patch-urile. Mainline a îmbunătățit considerabil cât de repede dispozitivele primesc versiuni actualizate ale componentelor importante ale sistemului de operare, îmbunătățind la rândul său securitatea ecosistemului Android în ansamblu.

Când vine vorba de Treble, totuși, kernel-ul Linux nu ar trebui să fie combinat cu codul de furnizor cu sursă închisă. Todd Kjos la Conferința instalatorilor Linux din acest an a explicat în trecut dificultățile cu care se confruntă atunci când vine vorba de fragmentare pe Android, iar multe dintre acestea se concentrează acum în jurul nucleului Linux pe care OEM-urile îl livrează împreună cu dispozitivele lor. Pentru context, Google furnizează fiecare nucleu Linux principal într-un „Kernel comun Android” (ACK), care urmărește îndeaproape versiunea principală, dar adaugă câteva corecții specifice Android. Furnizori de SoC cum ar fi Qualcomm, MediaTek și Samsung apoi se furcă acea kernel pentru fiecare SoC pe care îl fac. OEM-urile iau apoi acel nucleu specific SoC și adaugă corecții suplimentare pentru a implementa suport pentru hardware-ul specific pe care doresc să îl livreze.

Diagrama de mai sus arată modul în care nucleul unui dispozitiv trece prin mai multe straturi de schimbare care îl abstrag departe de kernel-ul Linux LTS. Pentru a o simplifica, începem cu kernel-ul Linux și se îmbină cu kernel-ul comun Android cu câteva modificări. De acolo, Android Common Kernel este fuzionat într-un nucleu de furnizor (Qualcomm, MediaTek, etc) cu propriile modificări și modificări. În cele din urmă, nucleul furnizorului este îmbinat într-un nucleu specific dispozitivului unui OEM. În această etapă, nucleul oricărui dispozitiv este departe de nucleul Linux LTS cu care a început.

Ca urmare a tuturor acestor fork-uri, până la 50% din codul care rulează pe un dispozitiv Android este cod în afara arborelui, ceea ce înseamnă că nu provine din nucleele comune Linux sau AOSP din amonte. Acest lucru face incredibil de dificilă (să nu mai vorbim de consumatoare de timp și costisitoare) îmbinarea modificărilor din amonte. Pentru OEM, nu există niciun stimulent să facă acest lucru, dar această practică poate fi dăunătoare pentru securitatea dispozitivului. Acesta este, de asemenea, motivul pentru care o mulțime de dispozitive Android sunt lăsate pe versiuni mai vechi de kernel LTS, ceea ce are ca efect secundar ca dispozitivele să piardă accesul la noile funcții ale nucleului Linux.

Android este fragmentat și Google știe asta

Google știe foarte bine că aceasta este o problemă și chiar are o secțiune numită „Costurile fragmentării" în documentația pentru dezvoltatori Android. Google spune asta „Majoritatea dispozitivelor emblematice sunt livrate cu o versiune de kernel care are deja cel puțin 18 luni vechime”. Și mai rău, Google spune și asta „Android 10 acceptă nucleele 3.18, 4.4, 4.9, 4.14 și 4.19, care în unele cazuri nu au fost îmbunătățite cu noi funcții de la Android 8 în 2017.” Acest lucru face dificilă adăugarea de funcții care necesită versiuni noi de kernel Linux. Nucleul Linux 3.18 a fost lansat în decembrie 2014, când Android 5.0 Lollipop era cea mai recentă versiune de Android. Aceasta este în mod clar o problemă și poate ține platforma înapoi.

De exemplu, Code Aurora Forum, sau CAF pe scurt, găzduiește codul sursă pentru diferite SoC Qualcomm Snapdragon. Qualcomm, ca SoC furnizor, distribuie o versiune forked a kernel-ului Linux către OEM/ODM, iar acele companii adaugă apoi modificări specifice dispozitivului la livrare dispozitive. Aceasta este ceea ce adaugă mai multe straturi de fragmentare. În plus, Qualcomm aduce modificări cadrului AOSP pentru a optimiza Android pentru fiecare dintre platformele mobile Snapdragon ale companiei. Qualcomm distribuie în mod privat kernel-ul Linux modificat, cadrul AOSP și alte instrumente software către partenerii săi ca parte a unui pachet de suport pentru bord sau BSP. CAF este locul în care Qualcomm publică public aceste modificări ale nucleului Linux și modificări ale cadrului AOSP.

Această versiune CAF poate fi utilă pentru dezvoltatorii de ROM personalizate care doresc să o folosească ca punct de plecare mai degrabă decât AOSP pur, motiv pentru care vedeți uneori ROM-uri „bazate pe CAF” pe forumurile noastre. Îți amintești de Snapdragon 625 care părea să alimenteze atât de multe smartphone-uri de gamă medie de ani de zile? Acesta a fost lansat cu Linux Kernel 3.18 și abia spre sfârșitul lui 2018 (la doi ani după lansarea chipset-ului) Qualcomm a actualizat sursele kernelului și le-a publicat pe CAF pentru msm8953 (numele chipset-ului Snapdragon 625) care aduce suport pentru Linux Kernel 4.9. Problema este că majoritatea OEM-urilor nu va actualiza telefoanele la această nouă versiune de nucleu Linux, în special nu telefoanele de gamă medie la doi ani după ce cipul a fost eliberată. Desigur, este foarte rar ca o actualizare majoră a nucleului să se întâmple chiar și în primul rând, dar ideea este că are sa întâmplat, deci nu este doar un scenariu imposibil.

Una peste alta, fragmentarea actuală în Android este o mizerie, ca să o spunem ușor. Cele mai recente încercări ale Google de a remedia această fragmentare vin sub forma Generic Kernel Image sau GKI.

Prezentarea imaginii generice Kernel

Pentru a rezolva această fragmentare, Google a lucrat la Android Generic Kernel Image (GKI). Acesta este în esență un nucleu compilat direct dintr-o ramură ACK. GKI izolează personalizările furnizorilor de SoC și OEM la modulele plugin, eliminând codul din arbore și permițând Google să trimită actualizările kernelului direct către utilizatorul final. De peste un an, Google lucrează la o modalitate de a furniza actualizări GKI prin Magazinul Play, prin utilizarea unui modul Mainline.

Ca urmare, dispozitivele care se lansează cu Android 12 care rulează nucleul Linux 5.10.43 sau o versiune ulterioară trebuie să facă una dintre următoarele: conform lui Mishaal Rahman.

• Implementați o imagine de pornire semnată de Google

SAU

• Implementați o imagine de pornire cu un nucleu care exportă un KMI (Kernel Module Interface) care este un subset al KMI exportat de GKI, exportă un API userspace care este un superset al UAPI-ului expus de GKI și acceptă toate caracteristicile GKI corespunzătoare versiune

Furnizorii pot crea module care se conectează la GKI, dar ideea GKI este că Google își asumă responsabilitatea pentru gestionarea modificărilor kernelului. Interfața Modulului Kernel (sau KMI, mai multe despre aceasta în părțile ulterioare ale articolului) este efectiv locul unde se așteaptă să ajungă codul din afara arborelui.

Seria Google Pixel 6 a fost lansată cu Android 12 din cutie și este livrat cu nucleul Linux 5.10 și este primul telefon livrat cu un GKI. Deoarece Google ar putea să actualizeze nucleul prin Magazinul Play, este posibil să vedem chiar actualizări frecvente ale nucleului, deoarece actualizările nucleului LTS sunt de obicei lansate săptămânal. În orice caz, este un sistem mult mai bun decât metoda greoaie în prezent de actualizare prin OTA, deși acest lucru înseamnă că este legat în mod inerent de cadrul GMS.

Google definește pur și simplu GKI după cum urmează:

• Este construit din sursele ACK.
• Este un binar cu un singur nucleu plus module încărcate asociate pe arhitectură, pe versiunea LTS (în prezent, doar arm64 pentru android11-5.4 și android12-5.4).
• Este testat cu toate versiunile platformei Android care sunt acceptate pentru ACK asociat. Nu există nicio depreciere a funcțiilor pe durata de viață a unei versiuni de kernel GKI
• Expune un KMI stabil șoferilor dintr-un anumit LTS.
• Nu conține SoC sau cod specific plăcii.

Google vrea chiar să fie într-o poziție până în 2023 în care să poată adopta un model de dezvoltare „în amonte”. Acest lucru va ajuta Google să se asigure că noul cod ajunge pe primul loc în nucleul principal Linux, reducând „datoria tehnică” acumulată în afara codului arborelui pe dispozitivele Android.

Interfața modulului Kernel (KMI)

Interfața Modulului Kernel, sau KMI, face parte din soluția Google pentru fragmentarea în curs de desfășurare în Android. În esență, SoC și suportul plăcii nu mai sunt localizate în nucleul de bază, ci sunt mutate în module încărcate. Atât nucleul, cât și modulele pot fi actualizate independent atunci, deoarece modulele sunt actualizate în /lib/modules. GKI în sine ar trebui să fie cât mai curat și generic posibil, ceea ce este posibil prin descărcarea a ceea ce este acum cod în afara arborelui în module separate.

Ca Ted Kjos explicat la Conferința instalatorilor Linux din acest an, „mare impuls multianual este de a scoate tot codul specific hardware-ului din nucleul generic și în modulele furnizorului. Trebuie să avem o interfață stabilă între acele module de furnizor și nucleul generic, astfel încât să poată fi livrate asincron.” GKI 1.0 este în esență un „test de conformitate”.

De fapt, compatibilitatea GKI înseamnă că dispozitivul trece testele VTS și CTS-on-GSI+GKI cu imaginea de sistem generică (GSI) și nucleul GKI instalat prin intermiterea imaginii de boot GKI în partiția de pornire și imaginea sistemului GSI în sistem compartimentare. Vendor Test Suite, sau VTS, este un test automat pe care trebuie să îl treacă toate dispozitivele pentru a fi considerate compatibile cu Project Treble. Compatibility Test Suite, sau CTS, este necesar pentru a accesa suita de aplicații Google.

Dispozitivele pot fi livrate cu un nucleu de produs diferit și pot folosi module încărcabile pe care GKI nu le furnizează. Cu toate acestea, atât produsul, cât și nucleele GKI trebuie să încarce module din aceleași partiții vendor_boot și vendor. Prin urmare, toate nucleele de produs trebuie să aibă aceeași interfață de modul nucleu binar (KMI).

Diagrama de mai sus arată ce este Google vrea de făcut și explică cum intenționează să ajungă la asta. Modulele Generic Kernel și GKI vor face parte din AOSP, iar GKI poate comunica cu framework-ul Android și Hardware Abstraction Layer (HAL) pe care un furnizor le poate implementa. Codul proprietar specific pe care un furnizor îl dorește în nucleu (de exemplu, driverele camerei) va fi în schimb introdus într-un modul de furnizor care devine o extensie a GKI prin intermediul KMI.

Cum poate ajuta GKI să rezolve problema fragmentării Android

Google a depus mult de lucru pentru eficientizarea procesului de dezvoltare a smartphone-urilor. Fiecare OEM își dorește propria identitate de marcă și fiecare OEM vrea să poată deține proprietatea asupra dispozitivelor sale. Spre deosebire de programul Android One, smartphone-urile Android pot fi aproape orice doresc, atâta timp cât respectă setul de reguli pe care Google le stabilește pentru a primi o licență GMS. Cu toate acestea, în trecut, Google nu a făcut prea multe pentru a domnă în dezvoltarea de dispozitive Android modificări precum Project Treble, Mainline și acum GKI-ul fiind mult mai recent în Android istorie.

Dar va ajuta? Ar trebui să funcționeze, deși este probabil să fie o afacere de mai mulți ani, care dă roade vizibile mai târziu. Acest lucru se va aplica numai dispozitivelor care se lansează cu Android 12, ceea ce înseamnă că vom vedea dispozitive care nu au GKI în anii următori. Aceasta a fost, de asemenea, o critică la adresa Proiectului Treble când a fost anunțat, deși, evident, toate dispozitivele lansate în prezent îl acceptă. Aceste lucruri necesită timp și, pe măsură ce Google trage încet domniile pe Android, procesul de dezvoltare este ușor pentru toți OEM-urile din ecosistemul Android, chiar dacă unii dintre ei ar prefera să păstreze controlul deplin asupra nucleului Linux care este folosit pe Android smartphone-uri.