Android 11:n mukana tulee kehittäjäasetuksissa oleva DSU Loader, jonka avulla voit ladata ja asentaa yhteensopivat GSI: t automaattisesti! Lue lisää!
Hyvä sovellusekosysteemi on yksi käyttöjärjestelmän menestyksen tärkeimmistä pilareista. Sekä Google että Apple tunnustavat hyvien sovellusten arvon niiden alustoilla, joten molemmat yritykset yrittävät tasapainottaa käyttäjiensä ja sovelluskehittäjiensä tarpeita. Käyttäjät vaativat jatkuvasti muutoksia käyttöjärjestelmiin, ja vaikka useimmat ihmiset yleensä arvostavat uusia ominaisuuksia, näitä muutokset eivät aina ole hauskoja sovellusten kehittäjille, koska ne voivat muuttaa monia ydintoimintoja ja käyttäytymistä. Niiden kehittäjien, jotka työskentelevät jatkuvasti pitääkseen sovelluksensa ajantasaisina, näiden muutosten käsitteleminen lisää heidän kasvavaa työlistaansa. Vaikka nämä muutokset eivät suoraan vaikutakaan heidän sovelluksiinsa, kehittäjien on silti varmistettava, että heidän sovelluksensa toimivat uuden käyttöjärjestelmän päivityksen kanssa. Google on tehnyt monia muutoksia vuosien varrella helpottaakseen tätä prosessia Android-sovelluskehittäjille, ja nyt uusi Android 11:n ominaisuus, nimeltään DSU Loader, tekee sovellusten kehittäjien entistä helpommaksi testata sovelluksiaan uudessa Androidissa versiot.
Se alkaa Project Treblellä
Android 8.0:ssa esitelty Project Treble on merkittävä Android-käyttöjärjestelmän uudelleensuunnittelu. Project Treblen tavoitteena oli jakaa Android-käyttöjärjestelmä kahteen suureen osaan: kehykseen ja toimittajan toteutukseen. ("toimittaja" viittaa tässä minkä tahansa laitteesta löytyvän omistusoikeudellisen laitteistokomponentin valmistajaan, yleensä viitaten pii). Android OS -kehys on itse käyttöjärjestelmä, mukaan lukien kaikki järjestelmäsovellukset, käyttöliittymä ja sen komponentit sekä sovellusliittymät, jotka jaetaan Android-laitteiden kesken. Toimittajatoteutus sisältää toimittajan HAL: t (Hardware Abstraction Layers) ja Linux-ytimen ja Linux-ytimen moduulit.
Koska OEM-valmistajat toimittavat älypuhelimia useilla eri laitteistokomponenteilla useilta eri toimittajilta, heidän on tehtävä paljon työtä saadakseen laitteiston käyttöön yhdellä Android-käyttöjärjestelmäjulkaisulla. Sitten jokaisen uuden Android-käyttöjärjestelmän päivityksen yhteydessä heidän on tehtävä entistä enemmän työtä varmistaakseen, että heidän laitteistonsa toimii uuden version kanssa. Mutta kun Project Treble standardoi ABI: n (Application Binary Interface) Android-käyttöjärjestelmäkehyksen ja HAL: ien välillä tietylle Android-versiolle, Androidin OEM-valmistajat voivat aloittaa laitteidensa päivitysten testaamisen joutumatta odottamaan piin valmistajien ja muiden komponenttien valmistajien päivittämistä koodi. Tämä muutos nopeutui huomattavasti tapa, jolla Android-päivityksiä käsitellään.
Tämä on Project Treblen ytimen tekeminen Android-päivityksille, mutta mikä on tärkeämpää sovelluksille kehittäjät tässä on, että Treble on mahdollistanut yleisten järjestelmäkuvien (GSI) käytön yhteensopivuuden varmistamiseksi testaus.
GSI: n syntyminen
Jotta OEM-valmistajat voivat testata, ovatko he ottaneet Project Treblen asianmukaisesti käyttöön, Google määrää, että OEM: n pitäisi pystyä käynnistämään puhdas Android-versio AOSP: stä laitteelle. Tätä puhdasta Android-versiota kutsutaan nimellä Generic System Image tai GSI. Jos GSI-käynnistys ja useimmat peruslaitteet toimivat oikein, OEM tietää, että heidän laitteensa täyttää Project Treblen vaatimukset. GSI: iden alkuperäinen tarkoitus oli siis testata Treble-yhteensopivuutta, mutta kuten olemme nähneet XDA-Developersin kehitysyhteisön kanssa, niitä voidaan käyttää muihin tarkoituksiin. Näimme kuinka GSI: t voisi käytännössä antaa laitteiden, joissa on raskaat Android UX -käyttöliittymät, nauttia uusimmasta Android-versiosta toimivilla ominaisuuksilla muutaman päivän kuluttua uudesta julkaisusta. Mutta Google näkee GSI: n takana toisen tarkoituksen: antaa sovelluskehittäjille mahdollisuuden testata sovelluksiaan uudella Android-versiolla fyysisellä laitteella, jonka he jo omistavat.
Android 10:llä Google julkaisi omat GSI-koontiversionsa kehittäjille. Google vahvisti ajatuksen siitä, että sovelluskehittäjien tulisi käyttää GSI: tä käynnistääkseen puhtaan Android-version omalla laitteistollaan, mikä helpottaa sovelluksensa toiminnan testaamista Androidin kanssa. Tämä menetelmä lisäsi siis olemassa olevia vaihtoehtoja testata sovellusten yhteensopivuutta varastossa olevalla Androidilla ilman OEM-käyttäytymismuutoksia, muut ovat Pixel-älypuhelimen käyttäminen, Android Studion virallisen Android-emulaattorin käyttäminen tai sovelluskoontiversioiden käyttöönotto pilvessä olevaan laiteesiintymään.
Kaikesta GSI: n mukanaan tuomasta mukavuudesta huolimatta niiden asennus oli silti hankala prosessi. Sovelluskehittäjät eivät välttämättä ole tyytyväisiä järjestelmäkuvan vilkkumiseen manuaalisesti Android-laitteella, koska tämä on asia, jonka yleensä vain harrastajat tai Android-käyttöjärjestelmän kehittäjät tuntevat. GSI: n asentaminen vaati järjestelmäkuvan vilkkumista pikakäynnistyksen kautta, mikä edellyttää Android Verified Bootin poistamista käytöstä ja käynnistyslataimen lukituksen avaamista. Bootloaderin lukituksen avaaminen vaatii puolestaan täydellisen käyttäjätietojen pyyhkimisen. Ja kuten me kaikki tiedämme, jokaisen Android-laitteen käynnistyslataimen avaamiseen ei ole olemassa täsmälleen yhtä prosessia tai opasta, joten johdonmukaisuutta ei löydy. Esimerkiksi Samsung-laitteissa ei ole pikakäynnistystä, kun taas Xiaomi-laitteet saavat sinut hyppäämään muutaman renkaan läpi avataksesi käynnistyslataimen. Se on kätevä sotku, joka voi purkaa johonkin yksinkertaisempaan.
Tässä dynaamiset järjestelmäpäivitykset tulevat käyttöön.
Dynaamiset järjestelmäpäivitykset yksinkertaisesti asentamalla GSI: t
Google ymmärsi, että nykyinen GSI-asennustapa ei ollut täydellinen ratkaisu, joten he alkoivat työstää parempaa ratkaisua. Android 10:ssä Google aloitti dynaamisten järjestelmäpäivitysten testaamisentai DSU. DSU on uusi tapa asentaa GSI tilapäisesti ilman, että sinun tarvitsee käyttää pikakäynnistyskomentoja järjestelmäkuvan flash-muistiin, mikä korvaa alkuperäisen asennuksen. DSU: n avulla voit käynnistää GSI: n, testata sovelluksesi ja käynnistää sen sitten kätevästi uudelleen alkuperäiseen asennukseen, joka on säilynyt koskemattomana.
Syy, miksi DSU voi asentaa GSI: n koskematta alkuperäiseen asennukseen, on se, että se luo uusia järjestelmä- ja dataosiootoksia, jotka tallennetaan väliaikaisesti /data/gsi. Nämä kuvat asennetaan sitten käynnistyksen aikana alkuperäisten järjestelmä- ja tietoosioiden sijaan. Koska puhelin tarvitsee lisää tallennustilaa näille uusille väliaikaisille kuville, puhelimessa on oltava "loogiset osiot", jotka ovat dynaamisesti muutettavia osioita. Loogiset osiot ovat uusi käyttäjätilan osiointijärjestelmä Androidille, joka on pakollinen Android 10 -käyttöjärjestelmää käyttäville laitteille. Jos laitteesi käynnistettiin Android 10:n kanssa, sen pitäisi tukea GSI: n asentamista DSU: n kautta.
Android 10:ssä kaikki mitä sinun tarvitsee tehdä asenna GSI DSU: n kautta on muuttaa järjestelmän ominaisuus ja käynnistää sitten DynamicSystemUpdatesInstallationService lähettämällä intentio, jossa on polku GSI: hen lisätarkoituksena.
Vaikka tämä prosessi saattaa tuntua tuntemattomalta, se on paljon helpompi ja vähemmän häiritsevä verrattuna käyttöön fastboot-komentoja ja kaiken vaivan käsittelemistä, mukaan lukien alkuperäinen asennus pyyhitty. Tarvitset jonkin verran tietoa ADB: stä ja tavoitteista voidaksesi käyttää DSU: ta, mutta tämän ei pitäisi olla ongelma useimmille sovelluskehittäjille. Ei kuitenkaan ole mitään syytä, miksi prosessia ei voitaisi tehdä vieläkin yksinkertaisempaa. Lisäksi GSI: n asentaminen DSU: n kautta edellyttää kuitenkin käynnistyslataimen lukituksen avaamista, jolloin kaikki käyttäjätiedot pyyhitään. Tätä varten Google on toteuttanut muutoksia parantaakseen GSI-asennuksen molempia puolia. Android 11:ssä he ovat poistaneet tarpeen käyttää komentoriviä GSI: n asentamiseen. Erikseen ne ovat myös mahdollistaneet GSI: n asentamisen ilman käynnistyslataimen lukitusta.
DSU Loader Android 11:ssä
DSU Loader on Android 11:n kehittäjäasetuksissa oleva uusi työkalu, jonka avulla voit ladata ja Asentaa Googlen uusin GSI ilman, että sinun tarvitsee syöttää mitään pikakäynnistys- tai ADB-komentoja. Napauta vain DSU Loader -vaihtoehtoa asetuksissa, ja näkyviin tulee valintaikkuna, jossa on luettelo tuetuista GSI: istä suoraan Googlelta. Nämä tuetut GSI: t perustuvat nykyiseen käyttöjärjestelmääsi ja arkkitehtuuriisi, joten voit asentaa vain GSI: itä, jotka ovat uudempia kuin käyttöjärjestelmäversiosi ja jotka vastaavat SoC-arkkitehtuuriasi. Valitse vain GSI, jonka haluat asentaa, ja se ladataan Googlen palvelimilta ja asennetaan taustalle automaattisesti.
DSU Loaderin avulla kehittäjien ei tarvitse koskaan koskettaa komentoriviä asentaakseen GSI: n. Ainakin se on unelma, koska yksi ongelma on vielä ratkaisematta.
Tie eteenpäin
Tällä hetkellä tarvitset lukitsemattoman käynnistyslataimen GSI: n asentamiseen DSU Loaderin kautta. Vaikka tämä voi tehdä tyhjäksi koko koettelemuksen tarkoituksen, sen ei pitäisi olla näin, ja meille kerrotaan, että se korjataan. Google on suunnitellut, että käyttäjät voivat käynnistää Googlen allekirjoittamat GSI: t DSU: n kautta ilman, että heidän tarvitsee avata käynnistyslataimen lukitusta. Itse asiassa Google määrää sen kaikki Android 10 -käynnistyslaitteet sisältävät julkiset Android Verified Boot -avaimet Googlen allekirjoittamia Android 10, Android 11 ja Android 12 GSI: itä. AVB: n julkisten avainten sisällyttäminen laitteen muistilevyyn varmistaa, että AVB ei hylkää GSI: tä, jota yrität käynnistää. Tästä syystä nykyiseen menetelmään kuuluu käynnistyslataimen lukituksen avaaminen - vilkuttamalla tyhjä vbmeta-kuva vbmeta-osioon, poistat AVB: n käytöstä, jotta se ei hylkää GSI: tä, jota aiot vilkkua. AVB: n poistaminen käytöstä on kuitenkin suuri turvallisuusriski, koska se tarkoittaa, että kaikki muutetaan järjestelmä/käynnistys/tuote/toimittaja-osio voidaan ladata laitteeseen, minkä vuoksi Google haluaa pois tuosta vaatimuksesta.
Joten milloin voit odottaa käynnistäväsi GSI: n DSU: n kautta ilman, että sinun tarvitsee avata käynnistyslataimen lukitusta tai käyttää komentorivityökaluja? Toivottavasti pian, kuten Google mainitsi meille, että heillä oli joitain mutkia ratkaista alkuperäisen Android 11 -kehittäjien esikatselun kanssa, ennen kuin he saivat tämän kaiken toimimaan kunnolla. Jatkossa voidaan odottaa asentavan tulevat Developer Preview GSI: t DSU: n kautta ilman, että käynnistyslataimen lukitusta tarvitsee avata. Ehkä, kun Android 12 Developer Previews on saatavilla, voit jopa käynnistää sen kokonaan käyttämällä DSU Loader -sovellusta Android 11:n kehittäjäasetuksissa. Sovelluskehittäjille tämä tarkoittaa, että sinulla on toinen tapa testata sovelluksiasi fyysisellä laitteistolla, jossa on uusi Android-versio.