DSU za Android 10 vam lahko omogočajo, da preizkusite posodobitve OTA, ne da bi se zavezali

click fraud protection

Ste kdaj želeli preizkusiti posodobitev brez dejanske posodobitve? DSU v Androidu 10 je zasnovan za to, vendar je trenutno omejen. To bi se lahko kmalu spremenilo.

Razdrobljenost operacijskega sistema Android in ravni varnosti je velik problem, v boj proti kateremu Google vlaga veliko inženirskih naporov. V zadnjih dveh letih je Google napovedal dve veliki pobudi za pospešitev uvajanja posodobitev: Projekt Treble in Projekt Mainline. Slednji je bil objavljen šele letos maja med Google I/O 2019, in je podprt samo v napravah, ki se zaženejo z Androidom 10. Prvi pa obstaja že od takrat Google I/O 2017, tako da smo videli, kakšen vpliv ima na posodobitve Androida z Androidom 9 Pie in Android 10.

Poleg zmanjšanja razdrobljenosti Google želi tudi, da bi bil Project Treble uporaben za razvijalce aplikacij. Zato so razkrili Dinamične posodobitve sistema (DSU) v sistemu Android 10, da bi razvijalcem omogočili preizkusiti različico nove posodobitve OS brez odklepanja zagonskega nalagalnika ali brisanja podatkov. Ker vidi potencial za DSU, se Google ne ustavi pri tem – širijo njegovo uporabnost tako, da omogočajo namestitev posodobitev OTA proizvajalcev originalne opreme na enak način, kot se namestijo GSI.

To je veliko žargona, a predstavljajte si, da se bo to zgodilo v prihodnosti: proizvajalec originalne opreme izda telefon z Androidom 10 in začne program beta za Android 11. Zanima vas, da preizkusite to različico beta, da vidite nove funkcije, vendar ne želite tvegati stabilnosti trenutnega dnevnega gonilnika. Namesto da bi utripali posodobitev beta in potem upali, da je popolnoma stabilna, zakaj je ne bi začasno namestili prek toka DSU? Če vam ni všeč, preprosto znova zaženite in vaše nastavitve se bodo vrnile v normalno stanje. Če vam je všeč, se lahko "zavežete" posodobitvi.

Ne vem za vas, toda to bi bila dobrodošla sprememba Androida, ki bi naredila beta testiranje bolj prijetno. Ne bi se vam več bilo treba zavezati k posodobitvi beta samo zato, da bi sami videli, kako je. Prepričan sem, da mnogi od vas komaj čakate na beta različico Androida 10 za svojo napravo, vendar vam morda ne bo všeč, da jo namestite takoj. S spremembami DSU to ne bi več povzročalo skrbi.

Dinamične sistemske posodobitve v sistemu Android 10+ – kaj se spreminja

Luca Stefani, prijatelj portala XDA in a Priznan razvijalec, nas je obvestil o a nova potrditev združeno v AOSP z naslovom "vpetje več particij DSU, ko so prisotne." Potrditev spremeni tabelo datotečnega sistema (fstab) in datoteko init proces, da bo tako, da bo med zagonom mogoče namestiti particije DSU, ki niso sistemske, zaenkrat vključno z izdelkom in prodajalcem postopek.

Nova koda v fstab za dodajanje podpore za nalaganje slik product_gsi in vendor_gsi namesto obstoječih particij izdelka oziroma prodajalca. Komentar ugotavlja, da lahko DSU podpiše proizvajalec originalne opreme, sicer pa podpira Googlove uradne GSI.

Trenutno je DSU zasnovan tako, da vam omogoča samo zagon Generic System Image (GSI), barebone sistemske slike, prevedene iz AOSP, tako da lahko preizkusite nove API-je in druge spremembe v najnovejši posodobitvi za Android. Vendar pa bo s to spremembo DSU sprejel tudi slike izdelkov in prodajalcev. Prva vsebuje aplikacije, knjižnice in druge datoteke, specifične za napravo, medtem ko druga vsebuje dvojiške datoteke, specifične za napravo. Projekt Treble je naredil tako, da lahko zaženete napravo s sistemsko sliko brez datotek, specifičnih za napravo, zato se zdi, da zdaj dovolite nalaganje izdelka in prodajalca, nima velikega smisla.

Vendar Googlov inženir izrecno pravi, da je ta sprememba namenjena "proizvajalcem originalne opreme [da] namestijo pakete OTA na /data, nato pa uporabijo [] tok 'DSU' za namestitev product.img, system.img, [in] vendor.img iz /data." To pomeni, da lahko OTA začasno naložite, namesto da bi prepisali trenutno namestitev z novim paketom OTA preko DSU. Po preizkusu posodobitve OTA se "uporabnik lahko odloči, ali želi te slike 'zavezati' v /super ali ne." Ta zadnji del o "obvezovanje" sprememb še vedno poteka, saj en Googlov inženir ugotavlja, da "trenutno nimamo načrta za izdelavo particij DSU trajno v kontekstu DSU." Nato navaja, kako bi se to lahko izvajalo, vendar je to izvajanje "zunaj obsega" tega trenutni popravek.

Obstaja nekaj izrazov in konceptov, ki jih moramo razložiti tukaj, ker Google rad spremeni particijsko shemo v vsaki različici Androida. Za začetek priporočam branje mojega prejšnjega članka o Dinamične posodobitve sistema za širok pregled nad tem, kako deluje, vendar če povzamemo, izkorišča koncept "dinamične particije", ene prave particije za shranjevanje (imenovane "super" particija), ki se razdeli na logične particije, ki jih je mogoče spreminjati (vključno s sistemom, prodajalcem, izdelkom in sistemsko_razdaljino), za začasno namestitev GSI. Ko namešča GSI, DSU ustvari prostor za nov sistem in slike uporabniških podatkov tako, da spremeni velikost obstoječe particije uporabniških podatkov. Gradniki za podporo DSU (dinamične particije, pomnilniški disk in kontrolne točke za varnostne kopije podatkov) so zahteve za zagon za Android 10, zato mora vsaka naprava, ki se zažene z novo različico OS Android, podpirati DSU. DSU ni rešitev dvojnega zagona za prilagojene ROM-e, ki jih nekateri iščete, ker je mogoče namestiti samo slike, ki se ujemajo s ključi Android Verified Boot (AVB). Vendar pa bi se lahko s to novo spremembo v prihodnosti izkazalo za veliko bolj uporabno.

Poleg dinamičnih particij je Google v Androidu 10 predstavil tudi koncept "virtualnega A/B". To je v bistvu izvedba dvojne A/B particije od prej, vendar z logičnimi particijami. Particije A/B vključujejo kopije pomembnih particij, ki omogočajo brezhibne in varne posodobitve. Uporaba "virtualnega A/B" je način, na katerega si en Googlov inženir predstavlja "zavezanost" particij DSU na particije iz trenutne namestitve; Tako kot pri trenutnem postopku posodabljanja A/B OTA, so morda spremembe iz novih slik narejene na neaktivni particiji.

Te spremembe so še v razvoju in lahko traja nekaj časa, preden jih Google ali proizvajalci originalne opreme začnejo uporabljati. mi verjetno ne bo videl nobene implementacije tega, dokler Android 11 R ne bo izdan naslednjič leto. Kljub temu ni zagotovila, da bodo proizvajalci originalne opreme sploh sprejeli to funkcijo za svoje posodobitve OTA. Glede na to, kako uporabno se zdi to za testiranje beta, si predstavljam, da Google že sodeluje z zainteresiranimi proizvajalci originalne opreme, da omogoči to funkcijo za prihodnje posodobitve. Osebno sem navdušen nad možnostjo preizkusa novih posodobitev za Android pred nakupom, kaj pa vi?