Android 11 kommer med DSU Loader i Developer Options, der lader dig downloade og installere kompatible GSI'er automatisk! Læs videre for mere!
Et godt app-økosystem er en af de vigtigste søjler for et operativsystems succes. Både Google og Apple anerkender værdien af at have gode applikationer på deres platforme, og derfor forsøger begge virksomheder at balancere behovene hos deres brugere og deres app-udviklere. Brugere bliver ved med at presse på for ændringer i OS'erne, og selvom de fleste mennesker generelt sætter pris på nye funktioner, er disse ændringer er ikke altid sjove for app-udviklere, da de kan ændre meget af kernefunktionaliteten og opførsel. For udviklere, der konstant arbejder på at holde deres apps relevante, tilføjer håndteringen af disse ændringer deres voksende arbejdsliste. Selvom disse ændringer ikke direkte påvirker deres applikationer, skal udviklere stadig sikre sig, at deres apps fungerer på den nye OS-opdatering. Google har foretaget mange ændringer gennem årene for at gøre denne proces nemmere for Android-appudviklere, og nu er der en ny funktion i Android 11, kaldet DSU Loader, vil gøre det endnu nemmere for app-udviklere at teste deres apps på ny Android versioner.
Det starter med Project Treble
Project Treble, introduceret i Android 8.0, er en stor ombygning af Android OS. Målet med Project Treble var at opdele Android OS i to store bidder: rammen og leverandørimplementeringen ("leverandør" refererer her til producenten af enhver proprietær hardwarekomponent, der findes i en enhed, normalt med henvisning til silicium). Android OS-rammen er selve operativsystemet, inklusive alle systemapps, brugergrænsefladen og dens komponenter og de API'er, der deles på tværs af Android-enheder. Leverandørimplementeringen indeholder leverandørens HAL'er (Hardware Abstraction Layers) og Linux-kerne- og Linux-kernemodulerne.
Da OEM'er sender smartphones med mange forskellige hardwarekomponenter fra mange forskellige leverandører, skal de gøre en masse arbejde bare for at få hardwaren op at køre på en enkelt Android OS-udgivelse. Så med hver ny Android OS-opdatering skal de gøre endnu mere arbejde for at sikre, at deres hardware fungerer med den nye version. Men med Project Treble standardisering af ABI (Application Binary Interface) mellem Android OS-rammeværket og HAL'er for en bestemt Android-version, Android OEM'er kan begynde at teste opdateringer til deres enheder uden at skulle vente på, at siliciumproducenter og andre komponentproducenter opdaterer deres side af koden. Denne ændring tog mærkbart fart måden Android-opdateringer håndteres på.
Det er kernen i, hvad Project Treble har gjort for Android-opdateringer, men hvad der er vigtigere for app udviklere her er, at Treble har aktiveret brugen af generiske systembilleder (GSI'er) for kompatibilitet afprøvning.
Fremkomsten af GSI'er
For at OEM'er kan teste, om de har implementeret Project Treble korrekt, giver Google mandat til, at OEM'en skal være i stand til at starte en ren build af Android fra AOSP på enheden. Denne rene opbygning af Android kaldes det generiske systembillede eller GSI. Hvis GSI starter og den mest basale hardware fungerer korrekt, så ved OEM, at deres enhed opfylder Project Trebles krav. Det oprindelige formål med GSI'erne var således at teste diskantkompatibilitet, men som vi har set med udviklingsfællesskabet her hos XDA-Developers, kan de bruges til andre formål. Vi så, hvordan GSI'er kunne i det væsentlige tillade enheder med tunge Android UX'er at nyde den nyeste version af Android med fungerende funktioner inden for få dage efter en ny udgivelse. Men Google forestiller sig et andet formål bag GSI: at give app-udviklere muligheden for at teste deres apps på en ny Android-version på en fysisk enhed, som de allerede ejer.
Med Android 10 udgav Google sine egne GSI-builds til udviklere. Google cementerede ideen om, at app-udviklere skulle bruge en GSI til at starte en ren opbygning af Android på deres egen hardware, hvilket gør det nemmere at teste deres applikations adfærd mod standard Android. Denne metode tilføjede således de eksisterende muligheder for at teste app-kompatibilitet på lager Android uden OEM-adfærdsændringer, de andre er ved at bruge en Pixel-smartphone, bruge den officielle Android-emulator i Android Studio eller implementere app-builds til en enhedsforekomst i skyen.
På trods af al den bekvemmelighed, som GSI'er medbragte, var deres installation stadig en besværlig proces. App-udviklere er muligvis ikke komfortable med manuelt at blinke et systembillede på en Android-enhed, da dette typisk er noget, som kun hobbyister eller Android OS-udviklere vil være bekendt med. Installation af en GSI krævede at blinke et systembillede over fastboot, hvilket kræver deaktivering af Android Verified Boot og oplåsning af bootloaderen. Oplåsning af bootloader kræver til gengæld en fuldstændig sletning af brugerdata. Og som vi alle ved, er der ikke ligefrem en enkelt proces eller guide til at låse op for bootloaderen på alle Android-enheder derude, så der er ingen sammenhæng at finde. For eksempel har Samsung-enheder ikke fastboot, mens Xiaomi-enheder får dig til at springe gennem et par bøjler for at låse bootloaderen op. Det er et praktisk rod, der har potentialet til at blive viklet ud i noget enklere.
Det er her, dynamiske systemopdateringer kommer ind.
Dynamiske systemopdateringer installerer ganske enkelt GSI'er
Google indså, at den nuværende metode til at installere GSI'er ikke var en perfekt løsning, så de begyndte at arbejde på en bedre løsning. I Android 10, Google begyndte at teste dynamiske systemopdateringereller DSU. DSU er en ny måde at midlertidigt installere en GSI på uden at skulle bruge fastboot-kommandoer til at flashe et systembillede og overskrive den originale installation. Med DSU kan du starte op i en GSI, teste din app og derefter bekvemt genstarte tilbage til din originale installation, som er forblevet urørt.
Grunden til at DSU kan installere en GSI uden at røre ved den originale installation er, at den opretter nye system- og datapartitionsbilleder, der midlertidigt gemmes i /data/gsi. Disse billeder monteres derefter under opstart i stedet for de originale system- og datapartitioner. Fordi telefonen har brug for ekstra lagerplads til disse nye, midlertidige billeder, skal din telefon have "logiske partitioner" ombord, som er partitioner, der kan ændres dynamisk. Logiske partitioner er et nyt partitioneringssystem for brugerrum til Android, som er obligatorisk for enheder, der starter med Android 10. Hvis din enhed blev lanceret med Android 10, skulle den understøtte installation af GSI'er via DSU.
I Android 10 er alt hvad du skal gøre for at installere en GSI via DSU er at ændre en systemegenskab og derefter starte DynamicSystemUpdatesInstallationService ved at sende en hensigt med stien til GSI'en som en hensigt ekstra.
Selvom denne proces kan virke ukendt, er den langt nemmere og mindre påtrængende sammenlignet med at bruge fastboot-kommandoer og håndtere besværet med alt, inklusive den originale installation, at være aftørret. Du kræver en vis viden om ADB og hensigter for at gøre brug af DSU, men dette burde ikke være et problem for de fleste app-udviklere derude. Alligevel er der ingen grund til, at processen ikke kunne gøres endnu enklere. Plus, der er det faktum, at installation af en GSI gennem DSU stadig kræver, at du låser opstartsindlæseren op, og sletter alle brugerdata i processen. Til det formål har Google implementeret ændringer for at forbedre begge aspekter af GSI-installationen. I Android 11 har de elimineret behovet for overhovedet at bruge kommandolinjen til at installere en GSI. Separat har de også gjort det muligt at installere en GSI uden at låse bootloaderen op.
DSU Loader i Android 11
DSU Loader er et nyt værktøj til stede i Android 11's udviklerindstillinger, der giver dig mulighed for det Hent og installere den nyeste GSI fra Google uden at skulle indtaste nogen fastboot- eller ADB-kommandoer. Tryk blot på indstillingen DSU Loader i Indstillinger, og en dialogboks vises med en liste over understøttede GSI'er direkte fra Google. Disse understøttede GSI'er vil være baseret på dit nuværende OS og din arkitektur, så du kan kun installere GSI'er, der er nyere end din OS-version, og som matcher din SoC-arkitektur. Du skal blot vælge den GSI, du ønsker at installere, og den vil automatisk blive downloadet fra Googles servere og installeret i baggrunden.
Med DSU Loader behøver udviklere aldrig at røre kommandolinjen for at installere en GSI. Det er i hvert fald drømmen, for der er stadig et problem tilbage at løse.
Vejen frem
For at installere en GSI via DSU Loader har du i øjeblikket brug for en ulåst bootloader. Selvom dette kan besejre formålet med hele prøvelsen, er det ikke meningen, at det skal være sådan, og vi får at vide, at det vil blive rettet. Google har planlagt, at brugere skal kunne starte Google-signerede GSI'er gennem DSU uden at skulle låse bootloaderen op. Faktisk påbyder Google det alle Android 10-lanceringsenheder inkluderer de offentlige Android Verified Boot-nøgler af Google-signerede Android 10, Android 11 og Android 12 GSI'er. Inkludering af AVB offentlige nøgler i enhedens ramdisk vil sikre, at AVB ikke vil afvise den GSI, som du forsøger at starte. Dette er grunden til, at den nuværende metode involverer oplåsning af bootloaderen - ved at flashe et tomt vbmeta-billede til vbmeta-partitionen, deaktiverer du AVB, så det ikke vil afvise den GSI, du er ved at flashe. Deaktivering af AVB er dog en stor sikkerhedsrisiko, da det betyder, at enhver modificeret system/boot/produkt/leverandørpartition kan indlæses på enheden, hvilket er grunden til, at Google ønsker at gøre væk med det krav.
Så hvornår kan du forvente at starte en GSI gennem DSU uden at skulle låse bootloaderen op eller bruge nogen kommandolinjeværktøjer? Forhåbentlig snart, som Google nævnte for os, at de havde et par knæk at stryge med de indledende Android 11 Developer Previews, før de kan få det hele til at fungere korrekt. Fremover kan man forvente at installere fremtidige Developer Preview GSI'er via DSU uden at skulle låse bootloaderen op. Måske når Android 12 Developer Previews gøres tilgængelige, vil du endda være i stand til at starte det helt op ved at bruge DSU Loader i Android 11's Developer Options. For app-udviklere betyder det, at der vil være endnu en måde for dig at teste dine applikationer på fysisk hardware, der kører en ny Android-version.