Google on paljastanut dynaamisen järjestelmäpäivityksen, uuden tavan asentaa GSI Android Q: han, joka ei vaadi käynnistyslataimen lukituksen avaamista.
Android 8.0 Oreon julkaisun ohella Google julkisti Projekti Treble: Android OS -kehyksen ja toimittajan HAL: ien ja Linux-ytimen kommunikaatiossa tapahtuva merkittävä uudelleenarkkitehtuuri. Treble on merkittävä aloite, joka on suunniteltu vähentämään Android-alustan versiota ja tietoturvakorjauksen pirstoutuminen, ja kaikkien Android Pien kanssa käynnistyvien Android-merkkisten laitteiden on tuettava Project Trebleä. OEM-valmistajat ja toimittajat testaavat Treble-yhteensopivuutta käynnistämällä Generic System Imagen (GSI) – puhtaan AOSP: n Androidin varastoversion – ja läpäisemällä Vendor Test Suite (VTS) ja Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). GSI on osoittautunut hyödylliseksi sen ansiosta, että OEM-valmistajilla työskentelevät ohjelmistosuunnittelijat voivat testata Treble-yhteensopivuutta, mutta se on myös avannut oven
suuri mukautettu ROM-yhteisö XDA: ssa. Android Q -julkaisua varten Google haluaa tehdä GSI: istä hyödyllisiä toiselle ryhmälle: sovelluskehittäjille.Siitä lähtien, kun minkä tahansa Android-alustan ensimmäinen vakaa julkaisu ja lähdekoodin pudotus tulee yleensä elokuussa, kehittäjät, jotka haluavat testata seuraavaa Android-julkaisua todellisella laitteella, tarvitsevat yleensä pääsyn Google-älypuhelimeen, jos he eivät halua odottaa päivityksen saavuttavan oman laitteistonsa. Google kuitenkin teki yhteistyötä OEM-valmistajien kanssa Android P beta useisiin laitteisiin viime vuonna, ja he ovat seuranneet sitä tänä vuonna Android Q beta. Virallisen Android Q -betaversion lisäksi Google julkaisi tänä vuonna myös virallinen Q beta GSI joten jokainen kehittäjä, jolla on Project Treble -yhteensopiva laite, voi asentaa uusimman Q-julkaisun ilman, että hänen tarvitsee odottaa kuukausia, että versio saavuttaa laitteensa. Tämä uusi tapa testata seuraavaa Android-julkaisua antaa kehittäjille enemmän mahdollisuuksia ja siten enemmän aikaa testata sovelluksiaan suuria muutoksia Androidissa.
Valitettavasti nykyinen menetelmä GSI: n asentaminen voi olla vaikeaa. Se edellyttää käynnistyslataimen lukituksen avaamista – mikä tarkoittaa kaikkien käyttäjätietojen pyyhkimistä ja/tai takuun mitätöimistä – ja kuvan vilkkumista fastboot-protokollan kautta. Se ei ole nopea ja yksinkertainen prosessi sovelluskehittäjälle, jos hänen laitteensa mahdollistaa jopa käynnistyslataimen lukituksen avaamisen. Siksi, varten useiden kuukausien aikana, Google on kehittänyt uutta tapaa käynnistää GSI: t. Anna uusi ominaisuus nimeltä Dynamic System Update tai DSU.
(Tämä ominaisuus on aiemmin kehitetty nimillä "Live Image", "Dynamic Android" ja "Android on Tap", joten älä ihmettele, jos Google kutsuu sitä toisella tavalla muutaman viikon tai kuukauden kuluttua.)
Dynaamiset järjestelmäpäivitykset Android Q: ssa
DSU-ominaisuuden tavoitteena on antaa kehittäjälle mahdollisuus käynnistyä GSI: stä häiritsemättä nykyistä asennusta. Tämä tarkoittaa, että käynnistyslataimen lukitusta ei tarvitse avata eikä käyttäjätietoja tarvitse pyyhkiä. Asennusprosessi on myös yksinkertaistettu huomattavasti, koska Google on tarjonnut komentoriviliittymän ADB: n kautta ja sovelluksen, jota voidaan ohjata intenttien kautta. Tältä näyttää GSI: n käynnistäminen DSU: lla:
Tässä videossa* Google Pixel 3 XL, jossa on Android Q beta 3, käynnistyy uudelleen GSI: ksi. Tässä ympäristössä sovelluksen kehittäjä voi asentaa ja testata sovelluksensa Q API -yhteensopivuuden varalta. Kun he ovat tehneet testauksen, he voivat yksinkertaisesti käynnistää uudelleen laitteen tavalliseen Q beta 3 -ohjelmistoon. Käytät periaatteessa kaksoiskäynnistystä GSI: stä, jotta voit testata sovelluksesi turvallisesti!
*Nauhoitimme tämän videon Google I/O 2019:ssä, kun DSU ei ollut vielä julkisesti saatavilla, joten Google muokkasi hieman DSU-tuen sisältävää Q beta 3 -versiota, joka perustuu kuvattuun Pixel 3 XL: ään. Laitteet, joissa on Q beta 4 tai uudempi, voivat tukea DSU: ta, jos ne täyttävät alla olevat vaatimukset.
Dynaamisten järjestelmäpäivitysten vaatimukset
Pohjimmiltaan kaksoiskäynnistyksen saaminen käyntiin ei ollut helppo tehtävä Googlelle. Osioiden hallintaan piti tehdä suuria muutoksia Pixel 3:ssa, Googlen DSU-testijärjestelmässä. Näin ollen ensimmäinen tärkeä vaatimus DSU-tuelle on, että laite tukee dynaamiset osiot. Dynaamiset osiot sisältävät yhden todellisen tallennusosion, joka on jaettu loogisiin osioihin, joiden kokoa voidaan muuttaa, kuten järjestelmä, toimittaja, odm, oem, tuote jne. GSI: n asennuksen aikana varataan tilaa uusille järjestelmä- ja käyttäjätieto-osiolle ottamalla käyttämättömät lohkot olemassa olevasta userdata-osiosta. Koska nämä uudet osiot voivat olla kooltaan useita gigatavuja, DSU-tuella on järkeä vain loogisella osiot, muuten laitteen olisi varattava pysyvästi useita gigatavuja tallennustilaa GSI: lle asennukset.
Muita vaatimuksia ovat muistilevy, joka päättää käynnistyykö palautus-, järjestelmä- vai loogiselle osiolle, ja metatieto-osio GSI: n metatietojen tallentamiseen. Yleensä DSU-tuen rakennuspalikoita ovat Android Q -käynnistysvaatimukset, Project Treblen johtajan Iliyan Malchevin mukaan. Emme ole varmoja siitä kaikki joka tarvitaan DSU: n tukemiseen, on Android Q -käynnistysvaatimus, mutta voimme olettaa, että useimmat elleivät kaikki laitteet käynnistyvät Android Q: lla voi tukee DSU: ta, vaikka Google ei tällä hetkellä vaadi niitä. Toistaiseksi vain Pixel 3:ssa, Pixel 3 XL: ssä, Pixel 3a: ssa ja Pixel 3a XL: ssä on dynaamiset osiot, ja näistä laitteista vain Pixel 3 ja Pixel 3 XL tukevat DSU: ta Android Q beta 4:ssä. Vaikka DSU-tukea ei vaadita, Google toivoo, että OEM-valmistajat ottavat ominaisuuden joka tapauksessa käyttöön, koska se yksinkertaistaa Treble-yhteensopivuuden turvallista testausta. Esimerkiksi OEM-ohjelmistosuunnittelija voi laittaa GSI: n SD-kortilla joten ne voivat nopeasti käynnistyä useilla laitteilla testatakseen Treble-yhteensopivuutta.
Suojaus dynaamisille järjestelmäpäivityksille
Koska DSU tuo sekoitukseen olennaisesti toisen käyttöjärjestelmän, Googlen on varmistettava, että tätä uutta asennusta ei voida peukaloida laitteen eheyden rikkomiseksi. Siten, GSI-asennuksessa on samat perussuojaukset kuin alkuperäisessä asennuksessa: Android Verified Boot- ja SELinux-käytännöt. Lisäksi vain sovellukset, joilla on INSTALL_DYNAMIC_SYSTEM-allekirjoitus|etuoikeutettu lupa, voivat aloittaa GSI: n asennus, kun taas sovellukset, joilla on MANAGE_DYNAMIC_SYSTEM-allekirjoitusoikeus, voivat ottaa GSI: n käyttöön tai poistaa sen käytöstä tai tyhjentää sen asennus. Tämä tarkoittaa, että vain luotetut järjestelmätason sovellukset voivat toimia DSU: n kanssa.
Varmistaakseen, että alkuperäiset käyttäjätiedot ovat suojattuja, Google on lisännyt ylimääräinen suojamekanismi Android Q: ssa. Nimeltään "Tarkistuspiste", ominaisuus suojaa käyttäjätietojen tuhoamiselta palauttamalla tarkistuspisteet osiot niiden alkuperäiseen tilaan. Tarkistuspisteet ovat kuitenkin hyödyllisiä paitsi DSU: lle. Niitä käytetään myös suojaamaan vaurioilta Projektin päälinja APEX-moduuli ja A/B OTA päivitykset. (Laitteet, joissa on A/B-osiot niillä on jo palautussuojaus, mutta nämä palautukset edellyttävät tehdasasetusten palautusta, kun taas käyttäjätietojen tarkistuspisteet eivät.)
GSI: n asennus
Jos laitteesi tukee DSU: ta, kuten Pixel 3 -sarjaa, GSI: n asentaminen on helppoa. Sinun on ensin varmistettava, että Dynamic System -ominaisuuden lippu on otettu käyttöön jollakin seuraavista tavoista:
- Jos käytät userdebug-koontiversiota, ota asetus settings_dynamic_android käyttöön kohdassa Asetukset > Järjestelmä > Kehittäjäasetukset > Ominaisuusliput.
- Jos käytät käyttäjäversiota, suorita seuraava adb-komento:
setproppersist.sys.fflag.override.settings_dynamic_system 1
Lataa sitten uusin Android Q beta GSI osoitteesta Google tai laitteesi OEM. (DSU sallii vain Googlen tai OEM: n allekirjoittamien GSI: iden asentamisen.) Kun olet ladannut, käytä simg2img muuntaaksesi harvan kuvan raakakuvaksi. Pakkaa raakakuva gzipin avulla ja kopioi sitten saatu arkisto johonkin paikkaan laitteessasi ulkoinen tallennusväline (esim. /data/media/0/Download) tai todellinen ulkoinen tallennusväline (kuten fyysinen SD-kortti kortti). Käynnistä lopuksi DynamicSystemInstallationService-sovellus oikealla aikeella aloittaa asennus:
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 8589934592Kun napsautat Käynnistä uudelleen, käynnistät GSI: n. Laitteen käytettävyys GSI: ssä riippuu siitä, kuinka hyvin laitteesi OEM toteutti Treblen (tai pikemminkin kuinka vähän he rikkoivat Trebleä yhteensopivuus.) Jotkut laitteet toimivat paremmin GSI: n kanssa kuin toiset, mutta yleensä älä odota käyttäväsi tätä asennusta päivittäisenä kuljettaja. Sinun on tarkoitus testata sovelluksesi ja poistua sitten käynnistämällä se uudelleen. Jos haluat pysyä GSI-asennuksessa lisätestausta varten, voit käyttää gsi_tool shell-komento.
DSU: n täydelliset GSI-asennusohjeet löytyvät tässä. Bugeja voi ilmoittaa osoitteessa Google Issue Tracker,Reddit, tai Pinon ylivuoto.
Dynaamisten järjestelmäpäivitysten taustalla oleva syy
Kun puhuin Iliyan Malchevin kanssa Google I/O: ssa, hän toisti sen, mitä Hung-ying Tyan Treble-tiimistä sanoi varhaisesta GSI-pääsystä klo. Marraskuun Android Dev Summit. Google teki DSU: n pyytää palautetta mahdollisimman laajalta yleisöltä. Tavoitteena on parantaa GSI: n laatua, mikä puolestaan parantaa tulevan Android-julkaisun laatua koska GSI on Androidin puhtain muoto. Google on tällä hetkellä ainoa yritys, joka testaa seuraavan version GSI-yhteensopivuutta (esimerkiksi kuinka hyvin Android Q -järjestelmäkuva toimii Android P: n päällä toimittajan toteutus), mutta kun yhä useammat ihmiset käyttävät GSI-tietoja ja antavat palautetta, OEM-valmistajat voivat korjata Treble-yhteensopivuusrikkomukset, jotta GSI: t toimivat entistä paremmin tulevaisuutta. Iliyan sanoo, että OEM-valmistajat ja toimittajat, kuten Qualcomm, ovat erittäin kiinnostuneita käyttämään uudelleen edellisen Android-julkaisun toimittajakuvia seuraavan version järjestelmäkuvan kanssa. DSU: n kaltaiset aloitteet auttavat Googlea ja OEM-valmistajia kuromaan umpeen automaattisten testien, kuten VTS: n ja CTS-on-GSI: n, kattavuuden. Näin ollen Google saa lisää betatestaajia antamaan palautetta seuraavasta Android-julkaisusta ja kuulee samalla myös Treble-yhteensopivuusrikkomuksista, jotta OEM-valmistajat voivat parantaa työtään.
Dynaamisten järjestelmäpäivitysten lisääminen Android Q: han on tervetullut, mutta se ei tule olemaan kaksoiskäynnistysratkaisu, jota jotkut teistä toivovat. Kuten aiemmin mainittiin, vain Googlen tai OEM-valmistajien allekirjoittamat järjestelmäkuvat voidaan asentaa. Kun kysyin Iliyanilta mahdollisuudesta laajentaa DSU: ta tukemaan vaihtoehtoisen Androidin ekosysteemiä Hän sanoi, että se on teknisesti mahdollista tehdä, koska DSU on yksinkertaisesti kanava järjestelmän toimittamiseen kuvia. Jokainen OEM voi käyttää sitä haluamallaan tavalla niin kauan kuin lopputulos on Android-yhteensopiva. Google ei ole luonut tähän vaihtoehtoa OTA-järjestelmälle, eikä DSU: ta ole tarkoitettu käytettäväksi todelliseen kaksoiskäynnistykseen. Siitä huolimatta, Googlen Treblen parissa tekemä työ tekee Androidista modulaarisemman, joten en olisi yllättynyt, jos alkuperäisestä kaksoiskäynnistyksestä tulee todellisuutta.