DSU Loader i Android 11 hjelper utviklere med å teste apper på lager Android

Et godt app-økosystem er en av de viktigste pilarene for suksessen til et operativsystem. Både Google og Apple anerkjenner verdien av å ha gode applikasjoner på plattformene sine, og derfor prøver begge selskapene å balansere behovene til brukerne og apputviklerne deres. Brukere fortsetter å presse på for endringer i OS-ene, og mens de fleste generelt setter pris på nye funksjoner, er disse endringer er ikke alltid morsomt for apputviklere, da de kan endre mye av kjernefunksjonaliteten og oppførsel. For utviklere som hele tiden jobber med å holde appene sine relevante, vil håndteringen av disse endringene bidra til deres voksende arbeidsliste. Selv om disse endringene ikke direkte påvirker applikasjonene deres, må utviklerne fortsatt sørge for at appene deres fungerer med den nye OS-oppdateringen. Google har gjort mange endringer i løpet av årene for å gjøre denne prosessen enklere for utviklere av Android-apper, og nå en ny funksjonen i Android 11, kalt DSU Loader, vil gjøre det enda enklere for apputviklere å teste appene sine på nye Android versjoner.

Det starter med Project Treble

Project Treble, introdusert i Android 8.0, er et hovedfag re-arkitektur av Android OS. Målet med Project Treble var å dele Android OS i to store deler: rammeverket og leverandørimplementeringen ("leverandør" refererer her til produsenten av enhver proprietær maskinvarekomponent som finnes i en enhet, vanligvis refererer til silisium). Android OS-rammeverket er selve operativsystemet, inkludert alle systemappene, brukergrensesnittet og dets komponenter, og API-ene som deles mellom Android-enheter. Leverandørimplementeringen inneholder leverandørens HAL-er (Hardware Abstraction Layers) og Linux-kjernen og Linux-kjernemodulene.

Siden OEM-er sender smarttelefoner med mange forskjellige maskinvarekomponenter fra mange forskjellige leverandører, må de gjøre mye arbeid bare for å få maskinvaren i gang på én enkelt Android OS-utgivelse. Så med hver nye Android OS-oppdatering, må de gjøre enda mer arbeid for å sikre at maskinvaren deres fungerer med den nye versjonen. Men med Project Treble som standardiserer ABI (Application Binary Interface) mellom Android OS-rammeverket og HAL-er for en bestemt Android-versjon, Android OEM-er kan begynne å teste oppdateringer til enhetene sine uten å måtte vente på at silisiumprodusenter og andre komponentprodusenter skal oppdatere sin side av koden. Denne endringen gikk merkbart fart måten Android-oppdateringer håndteres på.

Det er kjernen i hva Project Treble har gjort for Android-oppdateringer, men det som er viktigere for appen utviklere her er at Treble har aktivert bruk av generiske systembilder (GSI) for kompatibilitet testing.

Fremveksten av GSI-er

For at OEM-er skal teste om de har implementert Project Treble på riktig måte, gir Google mandat til at OEM-en skal kunne starte opp en ren versjon av Android fra AOSP på enheten. Denne rene versjonen av Android kalles Generic System Image, eller GSI. Hvis GSI starter og den mest grunnleggende maskinvaren fungerer som den skal, vet OEM at enheten deres oppfyller Project Trebles krav. Det opprinnelige formålet med GSI-ene var altså å teste diskantkompatibilitet, men som vi har sett med utviklingsfellesskapet her hos XDA-Developers, kan de brukes til andre formål. Vi så hvordan GSIs kunne i hovedsak tillate enheter med tunge Android-UX-er å nyte den nyeste versjonen av Android med fungerende funksjoner innen dager etter en ny utgivelse. Men Google ser for seg et annet formål bak GSI: å gi apputviklere muligheten til å teste appene sine på en ny Android-versjon på en fysisk enhet de allerede eier.

Med Android 10 ga Google ut sine egne GSI-bygg for utviklere. Google sementerte ideen om at apputviklere bør bruke en GSI for å starte opp en ren Android-konstruksjon på sin egen maskinvare, noe som gjør det enklere å teste applikasjonens oppførsel mot standard Android. Denne metoden ble dermed lagt til de eksisterende alternativene for å teste appkompatibilitet på lager Android uten OEM-adferdsendringer, de andre er ved å bruke en Pixel-smarttelefon, bruke den offisielle Android-emulatoren i Android Studio, eller distribuere appbygg til en enhetsforekomst i skyen.

Til tross for all bekvemmeligheten som GSI-er brakte med seg, var installasjonen deres fortsatt en tungvint prosess. Apputviklere er kanskje ikke komfortable med å blinke et systembilde manuelt på en Android-enhet, da dette er noe vanligvis bare hobbyister eller Android OS-utviklere vil være kjent med. Installasjon av en GSI krevde å blinke et systembilde over fastboot, noe som krever deaktivering av Android Verified Boot og opplåsing av oppstartslasteren. Opplåsing av oppstartslasteren krever på sin side en fullstendig sletting av brukerdata. Og som vi alle vet, er det ikke akkurat en enkelt prosess eller guide for å låse opp bootloaderen til alle Android-enheter der ute, så det er ingen konsistens å finne. For eksempel har ikke Samsung-enheter fastboot mens Xiaomi-enheter får deg til å hoppe gjennom noen få ringer for å låse opp bootloaderen. Det er et praktisk rot som har potensial til å bli løst inn i noe enklere.

Det er her dynamiske systemoppdateringer kommer inn.

Dynamiske systemoppdateringer installerer ganske enkelt GSI-er

Google innså at den nåværende metoden for å installere GSI-er ikke var en perfekt løsning, så de begynte å jobbe med en bedre løsning. I Android 10, Google begynte å teste dynamiske systemoppdateringer, eller DSU. DSU er en ny måte å midlertidig installere en GSI uten å måtte bruke fastboot-kommandoer for å flashe et systembilde, og overskrive den opprinnelige installasjonen. Med DSU kan du starte opp i en GSI, teste appen din og deretter enkelt starte på nytt til den opprinnelige installasjonen som har forblitt urørt.

Grunnen til at DSU kan installere en GSI uten å berøre den originale installasjonen er at den lager nye system- og datapartisjonsbilder som er midlertidig lagret i /data/gsi. Disse bildene blir deretter montert under oppstart i stedet for det originale systemet og datapartisjonene. Fordi telefonen trenger ekstra lagringsplass for disse nye, midlertidige bildene, må telefonen din ha «logiske partisjoner» ombord, som er partisjoner som kan endres dynamisk. Logiske partisjoner er et nytt partisjoneringssystem for brukerrom for Android, som er obligatorisk for enheter som lanseres med Android 10. Hvis enheten din ble lansert med Android 10, bør den støtte installasjon av GSI-er gjennom DSU.

I Android 10 er alt du trenger å gjøre for å installer en GSI via DSU er å endre en systemegenskap og deretter starte DynamicSystemUpdatesInstallationService ved å sende en intensjon med stien til GSI som en intensjon ekstra.

Selv om denne prosessen kan virke ukjent, er den langt enklere og mindre påtrengende sammenlignet med bruk fastboot-kommandoer og håndtere bryet med alt, inkludert den originale installasjonen tørkes. Du trenger litt kunnskap om ADB og intensjoner for å bruke DSU, men dette burde ikke være et problem for de fleste apputviklere der ute. Likevel er det ingen grunn til at prosessen ikke kunne gjøres enda enklere. I tillegg er det det faktum at installering av en GSI gjennom DSU fortsatt krever at du låser opp bootloaderen, og sletter alle brukerdata i prosessen. For det formål har Google implementert endringer for å forbedre begge aspektene ved GSI-installasjonen. I Android 11 har de eliminert behovet for å bruke kommandolinjen i det hele tatt for å installere en GSI. Separat har de også gjort det mulig å installere en GSI uten å låse opp bootloaderen.

DSU Loader i Android 11

DSU Loader er et nytt verktøy i Android 11s utvikleralternativer som lar deg nedlasting og installere den nyeste GSI fra Google uten å måtte legge inn noen fastboot- eller ADB-kommandoer. Bare trykk på DSU Loader-alternativet i Innstillinger og en dialogboks vil vises med en liste over støttede GSI-er rett fra Google. Disse støttede GSI-ene vil være basert på gjeldende operativsystem og arkitektur, så du kan bare installere GSI-er som er nyere enn OS-versjonen og som samsvarer med SoC-arkitekturen. Bare velg GSI-en du vil installere, så lastes den ned fra Googles servere og installeres automatisk i bakgrunnen.

Med DSU Loader trenger utviklere aldri å berøre kommandolinjen for å installere en GSI. Det er i hvert fall drømmen, for det er fortsatt ett problem igjen å løse.

Veien forover

For øyeblikket, for å installere en GSI via DSU Loader, trenger du en ulåst bootloader. Selv om dette kan beseire hensikten med hele prøvelsen, er det ikke ment å være slik, og vi blir fortalt at det vil bli fikset. Google har planlagt at brukere skal kunne starte opp Google-signerte GSI-er gjennom DSU uten å måtte låse opp bootloaderen. Faktisk pålegger Google det alle Android 10 lanseringsenheter inkluderer Android Verified Boot offentlige nøkler av Google-signerte Android 10, Android 11 og Android 12 GSI-er. Å inkludere AVB offentlige nøkler i enhetens ramdisk vil sikre at AVB ikke vil avvise GSI som du prøver å starte. Dette er grunnen til at den nåværende metoden innebærer å låse opp bootloader - ved å blinke et tomt vbmeta-bilde til vbmeta-partisjonen, deaktiverer du AVB slik at det ikke vil avvise GSI-en du er i ferd med å flashe. Deaktivering av AVB er imidlertid en stor sikkerhetsrisiko, da det betyr at enhver modifisert system/boot/produkt/leverandørpartisjon kan lastes inn på enheten, og det er derfor Google ønsker å gjøre bort med det kravet.

Så når kan du forvente å starte opp en GSI gjennom DSU uten å måtte låse opp bootloaderen eller bruke noen kommandolinjeverktøy? Forhåpentligvis snart, som Google nevnte for oss at de hadde noen knekk å stryke ut med de første Android 11 Developer Previews før de kan få alt til å fungere som det skal. Fremover kan man forvente å installere fremtidige Developer Preview GSI-er via DSU uten å måtte låse opp bootloaderen. Kanskje når Android 12 Developer Previews gjøres tilgjengelig, vil du til og med kunne starte den helt opp ved å bruke DSU Loader i Android 11s utvikleralternativer. For apputviklere betyr dette at det vil være enda en måte for deg å teste applikasjonene dine på fysisk maskinvare som kjører en ny Android-versjon.