Android 11 va veni cu DSU Loader în cadrul Opțiunilor pentru dezvoltatori, care vă va permite să descărcați și să instalați automat GSI-uri compatibile! Citiți mai departe pentru mai multe!
Un ecosistem bun de aplicații este unul dintre cei mai importanți piloni ai succesului unui sistem de operare. Atât Google, cât și Apple recunosc valoarea de a avea aplicații bune pe platformele lor, așa că ambele companii încearcă să echilibreze nevoile utilizatorilor lor și ale dezvoltatorilor de aplicații. Utilizatorii continuă să insiste pentru schimbări în sistemele de operare și, deși majoritatea oamenilor apreciază în general funcțiile noi, acestea modificările nu sunt întotdeauna distractive pentru dezvoltatorii de aplicații, deoarece pot modifica multe dintre funcționalitățile de bază și comportament. Pentru dezvoltatorii care lucrează în mod constant pentru a-și menține aplicațiile relevante, gestionarea acestor modificări se adaugă listei de lucru în creștere. Chiar dacă aceste modificări nu le afectează direct aplicațiile, dezvoltatorii trebuie să se asigure că aplicațiile lor vor funcționa pe noua actualizare a sistemului de operare. Google a făcut multe schimbări de-a lungul anilor pentru a face acest proces mai ușor pentru dezvoltatorii de aplicații Android, iar acum, un nou caracteristica din Android 11, numită DSU Loader, va face și mai ușor pentru dezvoltatorii de aplicații să-și testeze aplicațiile pe noul Android versiuni.
Începe cu Project Treble
Proiectul Treble, introdus în Android 8.0, este unul major re-arhitectura sistemului de operare Android. Scopul Project Treble a fost de a împărți sistemul de operare Android în două bucăți mari: cadrul și implementarea furnizorului ("furnizor" aici se referă la producătorul oricărei componente hardware proprietare găsite într-un dispozitiv, de obicei referindu-se la siliciu). Cadrul de operare Android este sistemul de operare în sine, inclusiv toate aplicațiile de sistem, interfața de utilizare și componentele sale, precum și API-urile care sunt partajate pe dispozitivele Android. Implementarea furnizorului conține HAL-urile furnizorului (Hardware Abstraction Layers) și kernel-ul Linux și modulele kernel-ului Linux.
Deoarece OEM-urile livrează smartphone-uri cu multe componente hardware diferite de la mulți furnizori diferiți, ei trebuie să facă multă muncă doar pentru a pune hardware-ul în funcțiune pe o singură versiune a sistemului de operare Android. Apoi, cu fiecare nouă actualizare a sistemului de operare Android, ei trebuie să lucreze și mai mult pentru a se asigura că hardware-ul lor funcționează cu noua versiune. Dar, cu Project Treble care standardizează ABI (Application Binary Interface) între cadrul sistemului de operare Android și HAL-urile pentru o anumită versiune Android, OEM Android pot începe să testeze actualizările dispozitivelor lor fără a fi nevoie să aștepte ca producătorii de siliciu și alți producători de componente să își actualizeze partea de Codul. Această schimbare s-a accelerat vizibil modul în care sunt gestionate actualizările Android.
Acesta este esența a ceea ce a făcut Project Treble pentru actualizările Android, dar ceea ce este mai important pentru aplicație dezvoltatorii aici este că Treble a permis utilizarea imaginilor de sistem generice (GSI) pentru compatibilitate testarea.
Apariția GSI-urilor
Pentru ca OEM-urile să testeze dacă au implementat corect Project Treble, Google impune ca OEM-ul să poată porni o versiune curată a Android de la AOSP pe dispozitiv. Această versiune curată a Androidului se numește Imaginea Sistemului Generic sau GSI. Dacă GSI pornește și majoritatea hardware-ului de bază funcționează corect, atunci OEM știe că dispozitivul lor îndeplinește cerințele Project Treble. Scopul inițial al GSI-urilor a fost astfel testarea compatibilității Treble, dar așa cum am văzut cu comunitatea de dezvoltare de aici, la XDA-Developers, acestea pot fi utilizate în alte scopuri. Am văzut cum sunt GSI ar putea permite, în esență, dispozitivelor cu UX Android grele să se bucure de cea mai recentă versiune de Android cu funcții funcționale în câteva zile de la o nouă lansare. Dar Google prevede un alt scop în spatele GSI: să ofere dezvoltatorilor de aplicații posibilitatea de a-și testa aplicațiile pe o nouă versiune Android pe un dispozitiv fizic pe care îl dețin deja.
Cu Android 10, Google și-a lansat propriile versiuni GSI pentru dezvoltatori. Google a consolidat ideea că dezvoltatorii de aplicații ar trebui să folosească un GSI pentru a porni o versiune curată a Android pe propriul hardware, făcând mai ușor testarea comportamentului aplicației lor față de Android stoc. Această metodă s-a adăugat astfel la opțiunile existente de testare a compatibilității aplicațiilor pe Android stoc fără modificări ale comportamentului OEM, celelalte fiind folosind un smartphone Pixel, folosind emulatorul Android oficial din Android Studio sau implementând versiuni de aplicații pe o instanță de dispozitiv în cloud.
În ciuda tuturor confortului pe care GSI-urile le-au adus, instalarea lor a fost încă un proces greoi. Este posibil ca dezvoltatorii de aplicații să nu se simtă confortabil să afișeze manual o imagine de sistem pe un dispozitiv Android, deoarece acesta este ceva cu care de obicei doar pasionații sau dezvoltatorii sistemului de operare Android vor fi familiarizați. Instalarea unui GSI a necesitat intermiterea unei imagini de sistem prin fastboot, ceea ce necesită dezactivarea Android Verified Boot și deblocarea bootloader-ului. Deblocarea bootloaderului, la rândul său, necesită o ștergere completă a datelor utilizatorului. Și după cum știm cu toții, nu există exact un singur proces sau ghid pentru deblocarea bootloader-ului fiecărui dispozitiv Android, așa că nu există consecvență de găsit. De exemplu, dispozitivele Samsung nu au pornire rapidă, în timp ce dispozitivele Xiaomi te fac să sari prin câteva cercuri pentru a debloca bootloader-ul. Este o mizerie convenabilă care are potențialul de a fi descurcat în ceva mai simplu.
Aici intervin actualizările dinamice ale sistemului.
Actualizări dinamice de sistem instalând pur și simplu GSI-uri
Google și-a dat seama că metoda actuală de instalare a GSI-urilor nu era o soluție perfectă, așa că au început să lucreze la o soluție mai bună. În Android 10, Google a început să testeze actualizările dinamice ale sistemului, sau DSU. DSU este o nouă modalitate de a instala temporar un GSI fără a fi nevoie să utilizați comenzi fastboot pentru a flashiza o imagine de sistem, suprascriind instalarea originală. Cu DSU, puteți să porniți într-un GSI, să vă testați aplicația și apoi să reporniți comod înapoi în instalația originală, care a rămas neatinsă.
Motivul pentru care DSU poate instala un GSI fără a atinge instalarea originală este că creează noi imagini de sistem și partiții de date care sunt stocate temporar în /data/gsi. Aceste imagini sunt apoi montate în timpul pornirii, mai degrabă decât sistemul original și partițiile de date. Deoarece telefonul are nevoie de spațiu de stocare suplimentar pentru aceste imagini noi, temporare, telefonul trebuie să aibă „partiții logice” la bord, care sunt partiții redimensionabile dinamic. Partițiile logice sunt un nou sistem de partiționare a spațiului utilizatorului pentru Android, care este obligatoriu pentru dispozitivele care se lansează cu Android 10. Dacă dispozitivul dvs. s-a lansat cu Android 10, atunci ar trebui să accepte instalarea GSI-urilor prin DSU.
În Android 10, tot ce trebuie să faci instalați un GSI prin DSU este de a modifica o proprietate a sistemului și apoi de a lansa DynamicSystemUpdatesInstallationService prin trimiterea unei intenții cu calea către GSI ca o intenție suplimentară.
Deși acest proces poate părea necunoscut, este mult mai ușor și mai puțin intruziv în comparație cu utilizarea comenzile fastboot și se ocupă de necazul tuturor, inclusiv a instalării originale, fiind şters. Aveți nevoie de anumite cunoștințe despre ADB și intenții de a utiliza DSU, dar aceasta nu ar trebui să fie o problemă pentru majoritatea dezvoltatorilor de aplicații. Cu toate acestea, nu există niciun motiv pentru care procesul nu ar putea fi simplificat. În plus, există faptul că instalarea unui GSI prin DSU necesită încă să deblocați bootloader-ul, ștergând toate datele utilizatorului în acest proces. În acest scop, Google a implementat modificări pentru a îmbunătăți ambele aspecte ale instalării GSI. În Android 11, au eliminat deloc nevoia de a utiliza linia de comandă pentru a instala un GSI. Separat, au făcut posibilă și instalarea unui GSI fără a debloca bootloader-ul.
DSU Loader în Android 11
DSU Loader este un nou instrument prezent în Opțiunile pentru dezvoltatori Android 11 care vă permite Descarca și instalare cel mai recent GSI de la Google fără a fi nevoie să introduceți comenzi fastboot sau ADB. Pur și simplu atingeți opțiunea DSU Loader din Setări și va apărea o casetă de dialog cu o listă de GSI-uri acceptate direct de la Google. Aceste GSI-uri acceptate se vor baza pe sistemul de operare și arhitectura dvs. actuale, așa că puteți instala numai GSI-uri mai noi decât versiunea dvs. de sistem și care se potrivesc cu arhitectura SoC. Pur și simplu alegeți GSI-ul pe care doriți să îl instalați și acesta va fi descărcat de pe serverele Google și instalat automat în fundal.
Cu DSU Loader, dezvoltatorii nu trebuie să atingă niciodată linia de comandă pentru a instala un GSI. Cel puțin, acesta este visul, pentru că mai rămâne o problemă de rezolvat.
Calea de urmat
În prezent, pentru a instala un GSI prin DSU Loader, aveți nevoie de un bootloader deblocat. Deși acest lucru poate învinge scopul întregului calvar, nu ar trebui să fie așa și ni se spune că se va rezolva. Google a planificat ca utilizatorii să poată porni GSI-urile semnate de Google prin DSU fără a fi nevoie să deblocheze bootloader-ul. De fapt, Google impune asta toate dispozitivele de lansare Android 10 includ cheile publice Android Verified Boot de GSI Android 10, Android 11 și Android 12 semnate de Google. Includerea cheilor publice AVB în discul ram al dispozitivului va asigura că AVB nu va respinge GSI-ul pe care încercați să îl porniți. Acesta este motivul pentru care metoda actuală implică deblocarea bootloader-ului - prin afișarea intermitentă a unei imagini vbmeta goale în partiția vbmeta, dezactivați AVB, astfel încât să nu respingă GSI-ul pe care urmează să îl flashați. Dezactivarea AVB este totuși un risc major de securitate, deoarece înseamnă că orice modificare partiția de sistem/boot/produs/furnizor poate fi încărcată pe dispozitiv, motiv pentru care Google dorește să facă departe cu această cerință.
Deci, când vă puteți aștepta să porniți un GSI prin DSU fără a fi nevoie să deblocați bootloader-ul sau să utilizați instrumente din linia de comandă? Sperăm că în curând, după cum Google ne-a menționat că au avut câteva probleme de rezolvat cu previzualizările inițiale pentru dezvoltatori Android 11 înainte de a putea face toate acestea să funcționeze corect. Mergând mai departe, se poate aștepta să instaleze viitoarele GSI-uri de previzualizare pentru dezvoltatori prin DSU fără a fi nevoie să deblochezi bootloader-ul. Poate că atunci când Android 12 Developer Previews vor fi disponibile, veți putea chiar să-l porniți complet folosind DSU Loader în Opțiunile pentru dezvoltatori Android 11. Pentru dezvoltatorii de aplicații, aceasta înseamnă că va exista încă o modalitate de a vă testa aplicațiile pe hardware fizic care rulează o nouă versiune Android.