Project Mainline este cea mai mare schimbare pentru Android de la Project Treble. Iată ce înseamnă și ce fac toate modulele. Verificați-l!
Una dintre cele mai mari schimbări în Android din ultimii ani, care a zburat sub radar, relativ vorbind împotriva importanței sale, a fost introducerea Linia principală a proiectului în Android 10. Google impune includerea unor module specifice Mainline în versiunile Android, cu Android 11 venind cu a total obligatoriu combinat de 25 de module Mainline. Iată o explicație despre ce este Project Mainline și ce își propune să rezolve, alături de o listă a tuturor modulelor de Project Mainline din Android.
Ce este Project Mainline?
Pentru a înțelege corect Project Mainline, va trebui să derulăm puțin înapoi. Dacă te întorci cu câțiva ani în urmă, o mare parte din conversația despre actualizările Android s-a centrat pe problema fragmentării. Fragmentarea a fost una dintre cele mai mari provocări pe care Google le-a rezolvat pe Android în jurul erei Ice Cream Sandwich - Lollipop. Chiar dacă Android ca platformă a primit actualizări regulate într-un model în mare măsură previzibil, aceste actualizări obișnuiau să dureze foarte mult timp pentru a ajunge în mâinile consumatorilor finali, dacă este deloc. Deci, în timp ce Google remedia erori critice și probleme de securitate la nivel de platformă, lansarea efectivă a acestor modificări a lăsat mult de dorit. Au fost/sunt o mulțime de intermediari (furnizor SoC, OEM, transportatori etc.) și o mulțime de părți mobile implicate în furnizarea de actualizări pentru telefonul dvs., iar problema de fragmentare nu părea că s-ar rezolva de la sine fără a necesita o lovire puternică interventii.
Unul dintre eforturile majore de a aborda această problemă a venit sub forma Proiect Treble alături de Android 8.0 Oreo, care a implicat o rearhitectură majoră a Android, separând componentele cadrului sistemului de operare Android de HAL-urile furnizorului și kernel-ul Linux. Project Treble, în esență, a modularizat Android prin separarea cadrului OS de software-ul de nivel inferior specific dispozitivului. În acest fel, producătorii de dispozitive (OEM) nu trebuie să aștepte ca producătorii de siliciu (furnizorul de SoC) să își actualizeze codul de implementare a furnizorului, iar OEM-urile ar putea actualiza în mod independent cadrul de operare Android. Rezultatul final este adoptarea mai rapidă a versiunilor Android mai noi de la OEM, deoarece acestea nu mai au nevoie așteptați ca intermediarul (furnizorul de SoC) să-și termine treaba mai întâi înainte să înceapă să o facă a lor.
În timp ce situația actualizării Android nu s-a îmbunătățit dramatic de la început cu Project Treble, a permis în mare măsură OEM mai larg participarea la Android 10 și Android 11 beta, precum și facilitarea pentru OEM să își actualizeze mai multe dispozitive într-un mod mai rapid. cronologie. În plus, întregul concept al GSI (Imaginea Sistemului Generic) a avut un impact major asupra dezvoltării pieței de schimb pe forumurile noastre.
Dezvoltatorul pornește Android 11 pe 22 de dispozitive mai vechi cu un Project Treble GSI
Project Mainline extinde eforturile Proiectului Treble. În timp ce Treble a redus gradul de dependență a OEM-urilor de furnizorii de SoC pentru fiecare actualizare a sistemului de operare, Mainline reduce gradul de dependență Google de OEM pentru a furniza actualizări de securitate componentelor cheie ale sistemului de operare. Project Mainline extinde filozofia Treble la părți mai critice ale cadrului Android, eliminând OEM-urile ca intermediari dependenți din această ecuație. Scopul proiectului Mainline este ca Google să preia controlul asupra componentelor cadrului și aplicațiilor de sistem care sunt critică pentru securitate și menținerea coerenței dezvoltării departe de OEM. Proiectul Mainline este denumit pe bună dreptate ca cel cea mai mare schimbare la Android de la Project Treble.
Pentru Project Mainline, Google utilizează module Mainline care sunt furnizate prin cadrul Serviciilor Google Play și Magazinul Google Play. Fiecare modul Mainline este livrat fie ca fișier APK, fie ca fișier APEX, fie ca APK-in-APEX. Când un modul Mainline este actualizat, utilizatorul vede o notificare „Google Play System Update” (GPSU) pe dispozitivul său. În mod efectiv, pentru a furniza actualizări ale componentelor critice, Google a ocolit necesitatea de a aștepta ca un OEM să lanseze o actualizare, alegând să facă singur sarcina.
La fel de Afirmă Google pe site-ul Android:
Componentele de sistem modulare le permit partenerilor Google și Android să distribuie actualizări pe scară largă, rapid și fără probleme către dispozitivele utilizatorilor finali, într-un mod neintruziv. De exemplu, combinația dintre fragmentarea codecului media și erorile critice poate încetini dramatic adoptarea aplicației și implicarea utilizatorilor. Actualizările frecvente ale modulelor legate de media pot reduce fragmentarea codecului pentru a face comportamentul aplicației media mai consistent pe diferite dispozitive Android și pot remedia erorile critice pentru a construi încrederea utilizatorilor.
Android 10 sau o versiune ulterioară convertește componentele selectate ale sistemului în module, dintre care unele folosesc formatul container APEX (introdus în Android 10) iar unele folosesc formatul APK. Arhitectura modulară permite ca componentele sistemului să fie actualizate cu remedieri critice de erori și altele îmbunătățiri după cum este necesar, fără a afecta implementările furnizorilor de nivel inferior sau aplicațiile de nivel superior și Servicii.
La fel de Ars Technica mențiuni:
Proiectul Mainline, AKA „Actualizări de sistem Google Play”, a fost introdus în Android 10 ca un efort major de a face componentele de bază ale sistemului Android mai modulare și mai actualizabile. Mainline a introdus un nou tip de fișier „APEX” special pentru componentele sistemului, cu scopul de a expedia codul Android de bază prin Magazinul Play la fel de ușor cum trimiteți o actualizare a aplicației. Anterior, singurul bloc de cod care se poate livra Android era APK, un tip de fișier conceput inițial pentru aplicații terțe. Acest lucru a venit cu tot felul de restricții de securitate și a putut porni doar târziu în procesul de pornire, așa că APEX a fost creat având în vedere componente de sistem mai puternice. APEX-urile pot fi create numai de Google sau de producătorul dispozitivului dvs., astfel încât să fie considerabil mai puternice și să găzduiască componente critice de pornire, cum ar fi timpul de rulare a aplicației.
Mainline nu este doar o soluție tehnică, ci și despre crearea mai multor părți din Android distribuite centralizat de Google, care implică negocieri cu producătorii de dispozitive și ca toți să accepte să livreze același bloc de cod. Modulele principale devin în cele din urmă obligatorii pentru livrare, așa că Mainline este de fapt o colaborare mare cu producătorii de dispozitive pentru a se asigura că un singur modul la nivelul ecosistemului satisface nevoile tuturor. Nu fiecare modul Mainline este un modul APEX ultra-puternic – unele sunt doar APK-uri care sunt acum cod Android distribuit de Google.
Linia principală a proiectului — Module
Cu Android 10, Google a impus includerea a 13 module specifice Mainline. Cu Android 11, numărul total de module obligatorii este de 25. Iată lista completă, alături de câteva detalii cheie:
Numele modulului |
Numele pachetului |
Tip |
Dispozitiv actualizat la sau lansat cu Android 11 |
Dispozitiv lansat cu Android 10 |
Dispozitiv actualizat la Android 10 |
---|---|---|---|---|---|
adbd |
com.google.android.adbd |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Android Neural Network API Runtime |
com.google.android.neuralnetworks |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Conectare la portalul captiv |
com.google.android.captiveportallogin |
APK |
Trebuie sa |
Foarte recomandat |
Opțional |
Transmisie prin telefon |
com.google.android.cellbroadcast |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Conscript |
com.google.android.conscrypt |
APEX |
Trebuie sa |
Foarte recomandat |
Opțional |
Rezolvare DNS |
com.google.android.resolv |
APEX |
Trebuie sa |
Foarte recomandat |
Opțional |
Interfața de utilizare pentru documente |
com.google.android.documentsui |
APK |
Trebuie sa |
Trebuie sa |
Opțional |
ExtServices - APK |
com.google.android.ext.services |
APK |
Trebuie sa |
Trebuie sa |
Trebuie sa |
ExtServices - APEX |
com.google.android.extservices |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Biblioteca IPsec/IKEv2 |
com.google.android.ipsec |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Codecuri media |
com.google.android.media.swcodec |
APEX |
Trebuie sa |
Trebuie sa |
Opțional |
Componentele cadrului media |
com.google.android.media |
APEX |
Trebuie sa |
Trebuie sa |
Opțional |
Furnizor de media |
com.google.android.mediaprovider |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Metadatele modulului |
com.google.android.modulemetadata |
APK |
Trebuie sa |
Trebuie sa |
Trebuie sa |
Componentele stivei de rețea |
com.google.android.networkstack |
APK |
Trebuie sa |
Foarte recomandat |
Opțional |
Configurarea permisiunii stivei de rețea |
com.google.android.networkstack.permissionconfig |
APK |
Trebuie sa |
Foarte recomandat |
Opțional |
Controller de permisiuni - APK |
com.google.android.permissioncontroller |
APK |
Trebuie sa |
Trebuie sa |
Trebuie sa |
Controller de permisiuni - APEX |
com.google.android.permission |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Extensii SDK |
com.google.android.sdkext |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Statsd |
com.google.android.os.statsd |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Pachetul cu versiunea trenului de telemetrie |
com.google.mainline.telemetry |
APK |
Trebuie sa |
Neacceptat |
Neacceptat |
Tethering |
com.google.android.tethering |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Date de fus orar |
com.google.android.tzdata |
APEX |
Nu trebuie să |
Trebuie sa |
Opțional |
Date de fus orar 2 |
com.google.android.tzdata2 |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Wifi³ |
com.google.android.wifi |
APEX |
Trebuie sa |
Neacceptat |
Neacceptat |
Pentru a oferi un anumit context coloanelor de mai sus, coloana intitulată „Dispozitiv actualizat la sau lansat cu Android 11” include detalii despre dacă modulul trebuie să fie prezent (sau nu trebuie să fie prezent, în cazul datelor de fus orar din cauza includerii alternativei sale) pe toate dispozitivele care fie au fost actualizate la Android 11, fie se lansează cu Android 11 din cutie. În mod similar, dispozitivele care se lansează cu Android 10 trebuie să includă câteva module, se recomandă insistent să includă altele și nu sunt acceptate de restul. Pentru dispozitivele care sunt actualizate la Android 10 (spre deosebire de cele lansate cu Android), lista modulelor necesare este mai scurtă.
Ce face fiecare modul Mainline?
Iată o scurtă explicație pentru fiecare dintre modulele Mainline:
Adbd
Modulul adbd gestionează sesiunile de depanare adb și IDE din linia de comandă. Modularizarea adbd permite Google să ofere îmbunătățiri de performanță și remedieri de erori mai rapid. Acest lucru este esențial, deoarece unele erori din trecut erau legate de consumarea bateriei și ar putea determina dispozitivele să continue să folosească CPU 100% până când telefonul moare. Așadar, obținerea acestor remedieri este crucială pentru Google, deoarece adb este utilizat pe scară largă de dezvoltatorii de aplicații și de OEM pentru testare.
Android Neural Networks API Runtime
Aceasta este o bibliotecă care se află între o aplicație și driverele de backend. API-ul, la rândul său, este un API C Android pentru rularea operațiunilor de învățare automată intensivă din punct de vedere computațional pe dispozitive mobile și pentru a permite operațiuni de inferență accelerate de hardware.
Transmisie prin telefon
Cell Broadcast se referă la alerte de urgență și non-urgență (cum ar fi alertele AMBER). Acest modul se ocupă de sarcinile din jurul acestor alerte și de alte funcții auxiliare, cum ar fi decodarea SMS și geofencing pentru alertele de urgență wireless.
Conscript
Modulul Conscrypt se ocupă de implementarea TLS de la Android și de alte funcții criptografice, cum ar fi generatoarele de chei, ciperurile și rezumatele mesajelor. Expedierea aceasta se face ca un modul permite Google să accelereze îmbunătățirile de securitate, fără a fi nevoie să se bazeze pe actualizările OTA.
Rezolvare DNS
După cum sugerează și numele, soluția DNS rezolvă DNS, adică transformă adresele URL care pot fi citite de om în adrese IP. Modulul conține codul care implementează soluția DNS stub, iar livrarea acestuia ca modul permite Google să ofere utilizatorilor o protecție mai bună împotriva interceptării DNS și a atacurilor de actualizare a configurației.
Interfața de utilizare pentru documente
Documents UI este modulul responsabil cu controlul accesului la anumite fișiere pentru componentele care gestionează permisiunile documentelor. După cum afirmă Google, introducerea accesului la stocare și a permisiunilor într-un modul crește confidențialitatea și securitatea pentru utilizatorii finali, în timp ce caracteristica de suprapunere a resurselor de rulare (RRO) permite OEM-urilor să tematice experiența (referindu-se la aplicația Fișiere) dacă au nevoie la. Ca modul, toate dispozitivele Google-Android vor fi livrate cu aceeași experiență Documents UI.
ExtServices
Acest modul include componente cadru pentru funcționalitatea de bază a sistemului de operare, cum ar fi clasarea notificărilor, strategiile de completare automată a textului, memoria cache, supravegherea pachetelor și alte servicii.
Biblioteca IPsec/IKEv2
Acest modul de bibliotecă se ocupă de funcțiile noi și existente în jurul rețelei LAN fără fir Interworking (IWLAN) și VPN-uri, cum ar fi negocierea parametrilor de securitate precum chei, algoritmi și tunel configuratii. Ideea cu modularizarea acestor funcții este de a promova consistența ecosistemului și de a oferi o modalitate de a oferi soluții rapide pentru problemele de securitate și interoperabilitate.
Acestea sunt trei module bifurcate, dar au funcții care se bazează unul pe celălalt. Aceste module media gestionează tipurile și codurile media, interacționează cu ExoPlayer, expun controalele de transport și informațiile de redare în cadru, optimizează metadatele indexate etc. Tine minte Stagefright, exploit care a schimbat Android și a adus însuși conceptul de actualizări lunare de securitate pe platformă? Exploatarea s-a bazat pe vulnerabilități din biblioteca de redare media. Deci, o modularizare a componentelor media permite Google să reacționeze rapid și pe scară largă în cazul în care se găsesc erori de securitate în această componentă adesea vizată.
Funcția acestui modul este imediat clară din numele său, deși scopul său nu este. Modulul Metadate modul conține...metadate despre lista de module de pe dispozitiv. Și cam atât.
Componentele stivei de rețea, Configurarea permisiunii stivei de rețea, Conectarea portalului captiv
Modulul Network Stack Components oferă servicii IP comune, monitorizarea conectivității la rețea, detectarea portalului de conectare captiv. Modulul Configurare permisiuni definește permisiunea care permite altor module să efectueze sarcini legate de rețea. Modulul Captive Portal Login se ocupă cu Captive Portals — pagini web care sunt afișate când conectat la anumite rețele Wi-Fi publice, unde utilizatorului i se cere să introducă detalii pentru a obține internet acces.
Controller de permisiuni
Acest modul oferă politici de confidențialitate actualizabile și elemente de interfață cu privire la acordarea și gestionarea permisiunilor. Dacă acest lucru sună familiar cu ceea ce face Programul de instalare a pachetelor, asta este pentru că este. Funcții precum acordarea permisiunilor de rulare, gestionarea și urmărirea utilizării au făcut parte din aplicația Package Installer până la Android 9. În Android 10, aplicația Package Installer este împărțită în secțiuni pentru a permite actualizarea logicii permisiunilor. Modulul Permission Controller este livrat ca fișier APK, iar în Android 11, modulul poate revoca automat permisiunile de rulare pentru aplicațiile care nu au fost utilizate pentru o perioadă lungă de timp.
Extensii SDK
Acest modul este puțin greu de înțeles și, în consecință, de explicat. Fiecărei versiuni Android i se atribuie un nivel SDK (de obicei +1 față de predecesorul său). Atunci când o aplicație vizează un anumit SDK, se presupune că dezvoltatorul a ținut cont de modificările comportamentale ale platformei și ale API-ului pe care le-a adus versiunea Android.
Modulul Extensii SDK decide nivelul „SDK de extensie” al dispozitivului și expune API-urile pentru aplicații pentru a interoga nivelul SDK-ului de extensie. Cam atât se menționează documentația oficială. ArsTechnica, totusi, mentioneaza că acesta este probabil un strat API secundar care va fi livrat prin Magazinul Play.
Statsd, pachet pentru versiunea trenului de telemetrie
Statsd este responsabil pentru colectarea valorilor dispozitivului. Pachetul Telemetry Train Version, pe de altă parte, nu conține cod activ sau nicio funcționalitate proprie. Conține pur și simplu un număr de versiune pentru „Trenul de telemetrie”, despre care Google spune că este un set de module legate de valori. Pe baza numărului versiunii, Google Play afișează utilizatorilor finali versiunea corecției de securitate și își dă seama dacă sunt disponibile actualizări pentru modulele legate de valori.
Tethering
Modulul Tethering partajează conexiunea la internet a dispozitivului cu alte dispozitive client conectate prin Wi-Fi, USB, Bluetooth sau Ethernet. Modulul include componentele de tethering și dependențele acestora. Prin utilizarea acestui modul Tethering, OEM-urile se pot baza pe o implementare de referință unică și standard și pot oferi o experiență consecventă pe toate dispozitivele.
Date de fus orar
Modulul Date fus orar actualizează ora de vară (DST) și fusurile orare pe dispozitivele Android, standardizând atât datele (care pot și se schimbă destul de frecvent ca răspuns la motive religioase, politice și geopolitice) și mecanismul de actualizare din ecosistem. Android 8.1 și Android 9 au folosit un mecanism de actualizare a datelor de fus orar bazat pe APK, iar Android 10 îl înlocuiește cu un mecanism de actualizare a modulului bazat pe APEX. Google afirmă că AOSP continuă să includă codul platformei necesar pentru actualizările bazate pe APK, așadar dispozitivele care fac upgrade la Android 10 pot primi în continuare actualizări ale datelor de fus orar furnizate de partener prin intermediul APK. Cu toate acestea, Google avertizează că actualizările bazate pe APK înlocuiesc o actualizare bazată pe APEX.
Wifi
Acesta este modulul pentru funcționalitatea Wi-Fi. Utilizatorii finali pot obține acum o experiență Wi-Fi consecventă pe dispozitivele Android, precum și remedieri ale problemelor de interoperabilitate prin actualizări de module, aplicații dezvoltatorii pot obține o fragmentare redusă a platformei, iar OEM-urile pot îndeplini cerințele operatorului, reducând în același timp costurile individuale. personalizări.
Sperăm că acest articol evidențiază cât de important este Project Mainline pentru ecosistemul Android Google.