Dinamične sistemske posodobitve v Androidu Q: Kako bo Project Treble izboljšal prihodnje različice Androida

Poleg izdaje Androida 8.0 Oreo je Google predstavil Projekt Treble: velika prenova arhitekture v načinu komuniciranja ogrodja OS Android ter HAL-ov prodajalca in jedra Linuxa. Treble je velika pobuda za zmanjšanje različice platforme Android in fragmentacija varnostnega popravkain vse naprave z blagovno znamko Android, ki se zaženejo s sistemom Android Pie, morajo podpirati Project Treble. Proizvajalci originalne opreme in prodajalci preizkusijo združljivost visokih tonov tako, da zaženejo Generic System Image (GSI) – čisto osnovno gradnjo Androida iz AOSP – in posredujejo Testna zbirka prodajalca (VTS) in Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI se je izkazal za uporabnega, saj inženirjem programske opreme, ki delajo za proizvajalce originalne opreme, ne omogoča samo testiranja združljivosti visokih tonov, ampak je tudi odprl vrata za

velika skupnost ROM po meri na XDA. Za izdajo Android Q želi Google narediti GSI uporabne za drugo skupino: razvijalce aplikacij.

Ker običajno pride do prve stabilne izdaje in padca izvorne kode katere koli dane izdaje platforme Android v avgustu, razvijalci, ki bi želeli preizkusiti naslednjo izdajo Androida na pravi napravi, običajno potrebujejo dostop do Googlovega pametnega telefona, če ne želijo čakati, da posodobitev doseže njihovo strojno opremo. Vendar je Google sodeloval z proizvajalci originalne opreme, da bi uvedel Android P beta lani na več naprav, letos pa so temu sledili z Android Q beta. Poleg uradne različice Android Q beta je Google letos izdal tudi različico uradni Q beta GSI tako lahko vsak razvijalec z napravo, združljivo s Project Treble, namesti najnovejšo izdajo Q, ne da bi moral več mesecev čakati, da graditev doseže njihove naprave. Ta nov način testiranja naslednje izdaje Androida daje razvijalcem več priložnosti in s tem več časa za testiranje svojih aplikacij velike spremembe v sistemu Android.

Na žalost sedanji način namestitev GSI je lahko težko. Zahteva odklepanje zagonskega nalagalnika - kar pomeni brisanje vseh uporabniških podatkov in/ali razveljavitev garancije - in utripanje slike prek protokola hitrega zagona. To ni hiter in preprost postopek za razvijalca aplikacije, če njegova naprava omogoča celo odklepanje zagonskega nalagalnika. Zato, za zadnjih nekaj mesecev, je Google delal na novem načinu zagona GSI-jev. Vnesite novo funkcijo, imenovano Dynamic System Update ali DSU.

(Ta funkcija je bila prej razvita pod imeni »Live Image«, »Dynamic Android« in »Android on Tap«, zato ne bodite presenečeni, če jo bo Google čez nekaj tednov ali mesecev imenoval drugače.)

Dinamične posodobitve sistema v sistemu Android Q

Cilj funkcije DSU je omogočiti razvijalcu zagon v GSI brez poseganja v trenutno namestitev. To pomeni, da zagonskega nalagalnika ni treba odkleniti in uporabniških podatkov ni treba izbrisati. Postopek namestitve je tudi močno poenostavljen, saj je Google zagotovil vmesnik ukazne vrstice prek ADB in aplikacijo, ki jo je mogoče nadzorovati prek namenov. Takole izgleda zagon GSI z DSU:

V tem videu* se Google Pixel 3 XL z operacijskim sistemom Android Q beta 3 znova zažene v GSI. V tem okolju lahko razvijalec aplikacije namesti in preizkusi svojo aplikacijo za združljivost Q API. Ko končajo s testiranjem, lahko preprosto znova zaženejo nazaj v običajno programsko opremo Q beta 3 v napravi. V bistvu dvojno zaganjate GSI, tako da lahko varno preizkusite svojo aplikacijo!

*Ta videoposnetek smo posneli na Google I/O 2019, ko DSU še ni bil javno dostopen, zato je Google nekoliko spremenil gradnjo Q beta 3 na posnetem telefonu Pixel 3 XL, da vključuje podporo za DSU. Naprave z različico Q beta 4 in novejše so primerne za podporo DSU, če izpolnjujejo spodnje zahteve.

Zahteve za dinamične posodobitve sistema

Za Google ni bila lahka naloga vzpostaviti in zagnati tega, kar je v bistvu dvojni zagon. Treba je bilo narediti velike spremembe v načinu upravljanja particij na Pixel 3, Googlovi preskusni napravi za DSU. Tako je prva glavna zahteva za podporo DSU, da naprava podpira dinamične particije. Dinamične particije vključujejo eno resnično particijo pomnilnika, ki je razdeljena na logične particije, ki jih je mogoče spreminjati, kot so sistem, prodajalec, odm, oem, izdelek itd. Med namestitvijo GSI je prostor rezerviran za nove sistemske particije in particije uporabniških podatkov tako, da se neuporabljeni bloki vzamejo iz obstoječe particije uporabniških podatkov. Ker so te nove particije lahko velike več gigabajtov, je podpora za DSU smiselna le pri logiki particije, sicer bi morala naprava trajno rezervirati več gigabajtov prostora za shranjevanje za GSI instalacije.

Druge zahteve vključujejo pomnilniški disk, ki se odloči, ali se bo zagnal z obnovitvene, sistemske ali logične particije, in metapodatkovno particijo za shranjevanje metapodatkov GSI. Na splošno so gradniki za podporo DSU zahteve za zagon sistema Android Q, po besedah ​​vodje Project Treble Iliyana Malcheva. Nismo prepričani, če vse ki je potreben za podporo DSU, je zahteva za zagon sistema Android Q, vendar lahko domnevamo, da večina, če ne vse naprave, zaženejo sistem Android Q lahko podpirajo DSU, tudi če Google tega trenutno ne zahteva. Doslej imajo samo Pixel 3, Pixel 3 XL, Pixel 3a in Pixel 3a XL dinamične particije, od teh naprav pa samo Pixel 3 in Pixel 3 XL podpirata DSU v Androidu Q beta 4. Čeprav podpora za DSU ni potrebna, Google upa, da bodo proizvajalci originalne opreme to funkcijo vseeno omogočili, ker poenostavlja varno testiranje združljivosti visokih tonov. Na primer, programski inženir OEM lahko postavi GSI na kartici SD tako da se lahko hitro zaženejo na več napravah in preizkusijo združljivost z visokimi toni.

Varnost za dinamične posodobitve sistema

Ker DSU v mešanico v bistvu uvaja drugi operacijski sistem, mora Google zagotoviti, da te nove namestitve ni mogoče posegati, da bi zlomil celovitost naprave. Tako je enake osnovne varnostne zaščite za prvotno namestitev so na voljo za namestitev GSI: Android Verified Boot in pravilniki SELinux. Poleg tega lahko samo aplikacije s podpisom INSTALL_DYNAMIC_SYSTEM|privilegiranim dovoljenjem sprožijo GSI namestitev, medtem ko lahko aplikacije z dovoljenjem za podpis MANAGE_DYNAMIC_SYSTEM omogočijo/onemogočijo ali izbrišejo GSI namestitev. To pomeni, da lahko z DSU delujejo samo zaupanja vredne aplikacije na sistemski ravni.

Da bi zagotovil zaščito izvirnih uporabniških podatkov, je Google dodal dodatni zaščitni mehanizem v sistemu Android Q. imenovan "Kontrolna točka," funkcija ščiti pred uničenjem uporabniških podatkov tako, da obnovi particije s kontrolnimi točkami v prvotno stanje. Kontrolne točke pa niso uporabne le za DSU. Uporabljajo se tudi za zaščito pred poškodbami Projekt Mainline APEX modul in A/B OTA posodobitve. (Naprave z A/B particijami že imajo zaščito pred povrnitvijo, vendar te povrnitve zahtevajo ponastavitev na tovarniške nastavitve, medtem ko kontrolne točke uporabniških podatkov ne.)

Namestitev GSI

Če vaša naprava podpira DSU, kot je serija Pixel 3, je GSI enostavno namestiti. Najprej se morate prepričati, da je zastavica funkcije Dynamic System omogočena na enega od dveh načinov:

1. Če uporabljate gradnjo userdebug, omogočite zastavico settings_dynamic_android v Nastavitve > Sistem > Možnosti razvijalca > Zastavice funkcij.
2. Če uporabljate uporabniško gradnjo, zaženite naslednji ukaz lupine adb:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Nato prenesite najnovejši Android Q beta GSI iz Google ali OEM vaše naprave. (DSU dovoljuje samo namestitev GSI-jev, ki jih je podpisal Google ali OEM.) Ko jih prenesete, uporabite simg2img za pretvorbo redke slike v neobdelano sliko. Uporabite gzip za spakiranje neobdelane slike in nato kopirajte dobljeni arhiv na lokacijo v napravi zunanji pomnilnik (npr. /data/media/0/Download) ali dejanski zunanji pomnilniški medij (kot je fizični SD kartica). Na koncu zaženite aplikacijo DynamicSystemInstallationService s pravim namenom za začetek namestitve:

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

Ko kliknete ponovni zagon, se boste zagnali v GSI. Uporabnost naprave v GSI je odvisna od tega, kako dobro je OEM vaše naprave implementiral Treble (ali bolje rečeno, kako malo je kršil Treble združljivost.) Nekatere naprave bodo bolje delovale z GSI kot druge, vendar na splošno ne pričakujte, da boste to namestitev uporabljali kot vsakodnevno voznik. Namenjeno vam je, da preizkusite svojo aplikacijo, nato pa jo izstopite s ponovnim zagonom. Če želite ostati v namestitvi GSI za nadaljnje testiranje, lahko uporabite gsi_tool lupinski ukaz.

Celotna navodila za namestitev GSI za DSU lahko najdete tukaj. Napake lahko vložite na Google Issue Tracker,Reddit, oz Preobremenitev.

Razlog za dinamične sistemske posodobitve

Ko sem govoril z Iliyanom Malchevom na Google I/O, je ponovil, kar je rekel Hung-ying Tyan iz ekipe Treble o zgodnjem dostopu do GSI na Novembrsko srečanje razvijalcev Androida. Google je naredil DSU za pridobiti povratne informacije od čim širšega občinstva. Cilj je izboljšati kakovost GSI, kar posledično izboljša kakovost prihodnje izdaje Androida saj je GSI najčistejša oblika Androida. Google je trenutno edino podjetje, ki preizkuša združljivost naslednje različice GSI (na primer, kako dobro deluje slika sistema Android Q poleg Androida P implementacija prodajalca), vendar ko več ljudi uporablja GSI in daje povratne informacije, lahko proizvajalci originalne opreme popravijo kršitve združljivosti visokih tonov, tako da bodo GSI delovali še bolje v prihodnost. Iliyan pravi, da proizvajalci originalne opreme in prodajalci, kot je Qualcomm, močno zanimajo ponovno uporabo slik prodajalcev iz prejšnje izdaje Androida s sliko sistema naslednje različice. Pobude, kot je DSU, pomagajo Googlu in proizvajalcem originalne opreme zapolniti vrzel v pokritosti z avtomatiziranimi testi, kot sta VTS in CTS-on-GSI. Tako Google dobi več beta preizkuševalcev, da podajo povratne informacije o naslednji izdaji Androida, hkrati pa izve tudi o kršitvah združljivosti Treble, da lahko proizvajalci originalne opreme izboljšajo svoje delo.

Dodatek dinamičnih sistemskih posodobitev v Androidu Q je dobrodošel, vendar to ne bo rešitev dvojnega zagona, ki jo nekateri od vas pričakujete. Kot je bilo že omenjeno, je mogoče namestiti samo slike sistema, ki jih je podpisal Google ali proizvajalci originalne opreme. Ko sem Iliyana vprašal o možnosti razširitve DSU za podporo ekosistema alternativnega Androida sistemov, je dejal, da je to tehnično mogoče storiti, saj je DSU preprosto kanal za dostavo sistema slike. Vsak OEM ga lahko uporablja, kakor hoče dokler je končni rezultat skladen s sistemom Android. Google tukaj ni ustvaril alternative sistemu OTA in DSU ni namenjen uporabi za pravi dvojni zagon. Ne glede na to delo, ki ga je Google opravil na Trebleju, naredi Android bolj modularen, zato me ne bi presenetilo, če bo izvorni dvojni zagon kmalu postal resničnost.