Actualizări dinamice ale sistemului în Android Î: Cum va îmbunătăți Project Treble versiunile viitoare de Android

Google a dezvăluit Dynamic System Update, o nouă modalitate de a instala un GSI în Android Q care nu necesită deblocarea bootloader-ului.

Odată cu lansarea Android 8.0 Oreo, Google a dezvăluit Proiect Treble: o rearhitecturare majoră a modului în care sistemul de operare Android și HAL-urile furnizorului și kernel-ul Linux comunică. Treble este o inițiativă majoră concepută pentru a reduce versiunea platformei Android și fragmentarea patch-urilor de securitateși toate dispozitivele cu marcă Android care se lansează cu Android Pie sunt necesare pentru a accepta Project Treble. OEM și vânzătorii testează compatibilitatea Treble pornind o imagine de sistem generică (GSI) — o versiune de stoc pur a Android de la AOSP — și trecând Suita de testare a furnizorilor (VTS) și Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI s-a dovedit util nu numai pentru a permite inginerilor de software care lucrează pentru OEM să testeze compatibilitatea Treble, dar a deschis și ușa pentru un

mare comunitate ROM personalizată pe XDA. Pentru lansarea Android Q, Google vrea să facă GSI-urile utile pentru un alt grup: dezvoltatorii de aplicații.

De când vine de obicei prima lansare stabilă și scăderea codului sursă a oricărei platforme Android in august, dezvoltatorii care ar dori să testeze următoarea versiune Android pe un dispozitiv real au de obicei nevoie de acces la un smartphone Google dacă nu doresc să aștepte ca actualizarea să ajungă la propriul hardware. Cu toate acestea, Google a colaborat cu OEM pentru a aduce un Android P beta pe mai multe dispozitive anul trecut și au continuat anul acesta cu un Android Q beta. Pe lângă o versiune beta oficială a Android Q, Google a lansat anul acesta și un oficial Q beta GSI astfel încât orice dezvoltator cu un dispozitiv compatibil Project Treble poate instala cea mai recentă versiune Q fără a fi nevoie să aștepte luni întregi pentru ca versiunea să ajungă pe dispozitivele lor. Acest nou mod de a testa următoarea versiune Android oferă dezvoltatorilor mai multe oportunități și, prin urmare, mai mult timp, pentru a-și testa aplicațiile schimbări majore în Android.

Din păcate, metoda actuală de instalarea unui GSI poate fi dificil. Necesită deblocarea bootloader-ului - ceea ce înseamnă ștergerea tuturor datelor utilizatorului și/sau anularea garanției - și afișarea intermitentă a unei imagini prin protocolul fastboot. Nu este un proces rapid și simplu de făcut pentru un dezvoltator de aplicații, dacă dispozitivul său permite chiar deblocarea bootloader-ului. De aceea, pentru ultimele câteva luni, Google a lucrat la o nouă modalitate de a porni GSI-urile. Introduceți o nouă funcție numită Actualizare dinamică a sistemului sau DSU.

(Această funcție a fost dezvoltată anterior sub denumirile „Imagine live”, „Android dinamic” și „Android la atingere”, așa că nu fi surprins dacă Google o numește altfel în câteva săptămâni sau luni.)

Actualizări dinamice de sistem în Android Q

Scopul caracteristicii DSU este de a permite unui dezvoltator să pornească într-un GSI fără a interfera cu instalarea curentă. Aceasta înseamnă că bootloader-ul nu trebuie să fie deblocat și că datele utilizatorului nu trebuie să fie șterse. Procesul de instalare este, de asemenea, foarte simplificat, deoarece Google a furnizat o interfață de linie de comandă prin ADB și o aplicație care poate fi controlată prin intentii. Iată cum arată să pornești un GSI folosind DSU:

În acest videoclip*, un Google Pixel 3 XL care rulează Android Q beta 3 repornește într-un GSI. În acest mediu, un dezvoltator de aplicații își poate instala și testa aplicația pentru compatibilitatea Q API. Când au terminat testarea, pot pur și simplu să repornească din nou în software-ul obișnuit Q beta 3 de pe dispozitiv. Practic, porniți dublă un GSI, astfel încât să vă puteți testa aplicația în siguranță!

*Am înregistrat acest videoclip la Google I/O 2019 când DSU nu era încă disponibil public, așa că versiunea Q beta 3 pe Pixel 3 XL filmat a fost ușor modificată de Google pentru a include suport DSU. Dispozitivele care rulează Q beta 4 și versiunile ulterioare sunt eligibile să accepte DSU dacă îndeplinesc cerințele de mai jos.

Cerințe pentru actualizări dinamice de sistem

Punerea în funcțiune a ceea ce este în esență pornire dublă nu a fost o sarcină ușoară pentru Google. Au trebuit făcute modificări majore în modul în care sunt gestionate partițiile pe Pixel 3, bancul de testare Google pentru DSU. Astfel, prima cerință majoră pentru suportul DSU este ca dispozitivul să accepte partiții dinamice. Partițiile dinamice implică o partiție reală de stocare care este împărțită în partiții logice redimensionabile, cum ar fi sistem, furnizor, odm, OEM, produs etc. În timpul instalării unui GSI, spațiul este rezervat pentru noi partiții de sistem și de date utilizator prin preluarea blocurilor neutilizate din partiția de date utilizator existentă. Deoarece aceste noi partiții pot avea o dimensiune de câțiva gigaocteți, suportul DSU are sens doar cu logica partiții, altfel un dispozitiv ar trebui să rezerve permanent câțiva gigaocteți de spațiu de stocare pentru GSI instalatii.

Alte cerințe includ un disc ram, care decide dacă să pornească pentru recuperare, sistem sau o partiție logică și o partiție de metadate pentru a stoca metadatele GSI. În general, elementele de bază pentru suportul DSU sunt cerințele de lansare Android Q, potrivit liderului proiectului Treble, Iliyan Malchev. Nu suntem siguri dacă Tot care este necesar pentru a suporta DSU este o cerință de lansare a Android Q, dar putem presupune că majoritatea, dacă nu toate dispozitivele care se lansează cu Android Q poate sa acceptă DSU chiar dacă Google nu le solicită în prezent. Până acum, doar Pixel 3, Pixel 3 XL, Pixel 3a și Pixel 3a XL au partiții dinamice, iar dintre aceste dispozitive, doar Pixel 3 și Pixel 3 XL acceptă DSU în Android Q beta 4. Deși nu este necesar suportul DSU, Google speră că OEM-urile să activeze funcția oricum, deoarece simplifică testarea în siguranță pentru compatibilitatea Treble. De exemplu, un inginer de software OEM poate pune un GSI pe un card SD astfel încât să poată porni rapid pe mai multe dispozitive pentru a testa compatibilitatea Treble.

Securitate pentru actualizări dinamice de sistem

Deoarece DSU introduce în esență un al doilea sistem de operare în combinație, Google trebuie să se asigure că această nouă instalare nu poate fi modificată pentru a distruge integritatea dispozitivului. Astfel, cel aceleași protecții de securitate de bază pentru instalația originală sunt aplicate pentru instalația GSI: Android Verified Boot și politici SELinux. În plus, numai aplicațiile cu semnătura INSTALL_DYNAMIC_SYSTEM|permisiunea privilegiată pot iniția un GSI instalare, în timp ce aplicațiile cu permisiunea de semnătură MANAGE_DYNAMIC_SYSTEM pot activa/dezactiva sau șterge un GSI instalare. Aceasta înseamnă că numai aplicațiile de încredere, la nivel de sistem, pot funcționa cu DSU.

Pentru a se asigura că datele originale ale utilizatorului sunt protejate, Google a adăugat un mecanism de protecție suplimentară în Android Q. numit "Punct de control," caracteristica protejează împotriva distrugerii datelor utilizatorului prin restabilirea partițiilor cu puncte de control la starea lor inițială. Punctele de control sunt utile nu doar pentru DSU. De asemenea, sunt folosite pentru a proteja împotriva erorilor Linia principală a proiectului modulul APEX și A/B Actualizări OTA. (Dispozitive cu partiții A/B au deja protecție împotriva derulării înapoi, dar aceste rollback necesită resetarea datelor din fabrică, în timp ce punctele de control ale datelor utilizatorului nu.)

Instalarea unui GSI

Dacă dispozitivul dvs. acceptă DSU precum seria Pixel 3, atunci este ușor să instalați un GSI. Mai întâi trebuie să vă asigurați că marcajul caracteristicii Sistem dinamic este activat printr-unul din două moduri:

  1. Dacă sunteți pe o versiune userdebug, activați indicatorul settings_dynamic_android în Setări > Sistem > Opțiuni pentru dezvoltatori > Indicatori pentru caracteristici.
  2. Dacă sunteți pe o versiune de utilizator, rulați următoarea comandă adb shell:
    setproppersist.sys.fflag.override.settings_dynamic_system 1

Apoi, descărcați cel mai recent Android Q beta GSI de la Google sau OEM-ul dispozitivului dvs. (DSU permite numai instalarea GSI-urilor semnate de Google sau de un OEM.) Odată descărcat, utilizați simg2img pentru a converti imaginea rară într-o imagine brută. Utilizați gzip pentru a împacheta imaginea brută, apoi copiați arhiva rezultată într-o locație de pe dispozitivul dvs. stocare externă (de exemplu, /data/media/0/Download) sau un mediu de stocare extern real (cum ar fi un SD fizic card). În cele din urmă, lansați aplicația DynamicSystemInstallationService cu intenția corectă de a începe instalarea:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

După ce faceți clic pe repornire, veți porni în GSI. Utilizabilitatea dispozitivului în GSI depinde de cât de bine a implementat echipamentul OEM al dispozitivului dvs. Treble (sau, mai degrabă, cât de puțin a încălcat Treble). compatibilitate.) Unele dispozitive vor funcționa mai bine cu GSI decât altele, dar, în general, nu vă așteptați să utilizați această instalare zilnic. conducător auto. Sunteți menit să vă testați aplicația, apoi să reporniți repornirea. Dacă doriți să rămâneți în instalația GSI pentru teste ulterioare, atunci puteți utiliza gsi_tool comanda shell.

Puteți găsi instrucțiunile complete de instalare GSI pentru DSU Aici. Bug-urile pot fi depuse pe Google Issue Tracker,Reddit, sau Depășirea stivei.

Motivul din spatele actualizărilor de sistem dinamice

Când am vorbit cu Iliyan Malchev la Google I/O, el a reiterat ceea ce Hung-ying Tyan din echipa Treble a spus despre accesul GSI timpuriu la Summit-ul Android Dev din noiembrie. Google a făcut DSU să solicita feedback de la un public cât mai larg posibil. Scopul este de a îmbunătăți calitatea GSI, care la rândul său îmbunătățește calitatea viitoarei versiuni Android deoarece un GSI este cea mai pură formă de Android. Google este în prezent singura companie care testează compatibilitatea GSI cu versiunea următoare (de exemplu, cât de bine funcționează imaginea sistemului Android Q peste Android P implementarea furnizorului), dar pe măsură ce mai mulți oameni flash-uri GSI-uri și oferă feedback, OEM-urile pot remedia încălcările de compatibilitate Treble, astfel încât GSI-urile să funcționeze și mai bine în viitor. Iliyan spune că există un interes puternic din partea OEM-urilor și a vânzătorilor precum Qualcomm în reutilizarea imaginilor furnizorilor din versiunea anterioară a Android cu imaginea de sistem din următoarea versiune. Inițiative precum DSU îi ajută pe Google și pe producătorii de echipamente originale să completeze decalajul de acoperire din testele automate precum VTS și CTS-on-GSI. Astfel, Google primește mai mulți testeri beta pentru a oferi feedback cu privire la următoarea lansare Android, auzind în același timp despre încălcările compatibilității Treble, astfel încât OEM-urile să își poată îmbunătăți munca.

Adăugarea de actualizări dinamice de sistem în Android Q este binevenită, dar nu va fi soluția dual boot la care unii dintre voi o sperați. După cum am menționat anterior, pot fi instalate numai imagini de sistem semnate de Google sau OEM. Când l-am întrebat pe Iliyan despre posibilitatea extinderii DSU pentru a sprijini un ecosistem de Android alternativ sisteme, el a spus că este posibil din punct de vedere tehnic să faceți acest lucru, deoarece DSU este pur și simplu un canal de livrare a sistemului imagini. Orice OEM îl poate folosi cum dorește atâta timp cât rezultatul final este compatibil cu Android. Google nu a creat aici o alternativă la sistemul OTA, iar DSU nu este destinat să fie utilizat pentru o pornire duală reală. Indiferent, munca pe care Google a făcut-o pe Treble face ca Androidul să fie mai modular, așa că nu m-aș mira dacă dual booting nativ devine realitate pe viitor.