Android 11 kommer med DSU Loader inom utvecklaralternativen som låter dig ladda ner och installera kompatibla GSI: er automatiskt! Läs vidare för mer!
Ett bra appekosystem är en av de viktigaste pelarna för ett operativsystems framgång. Både Google och Apple inser värdet av att ha bra applikationer på sina plattformar, och därför försöker båda företagen att balansera behoven hos sina användare och sina apputvecklare. Användare fortsätter att trycka på för ändringar i operativsystemen, och även om de flesta människor i allmänhet uppskattar nya funktioner, är dessa förändringar är inte alltid kul för apputvecklare eftersom de kan ändra mycket av kärnfunktionaliteten och beteende. För utvecklare som ständigt arbetar för att hålla sina appar relevanta, läggs hanteringen av dessa förändringar till deras växande arbetslista. Även om dessa ändringar inte direkt påverkar deras applikationer, måste utvecklare fortfarande se till att deras appar fungerar med den nya OS-uppdateringen. Google har gjort många förändringar under åren för att göra denna process enklare för Android-apputvecklare, och nu en ny funktionen i Android 11, kallad DSU Loader, kommer att göra det ännu enklare för apputvecklare att testa sina appar på nya Android versioner.
Det börjar med Project Treble
Project Treble, introducerat i Android 8.0, är en stor omarkitektur av Android OS. Målet med Project Treble var att dela upp Android OS i två stora delar: ramverket och leverantörsimplementeringen ("leverantör" hänvisar här till tillverkaren av alla proprietära hårdvarukomponenter som finns i en enhet, vanligtvis med hänvisning till kisel). Android OS-ramverket är själva operativsystemet, inklusive alla systemappar, användargränssnittet och dess komponenter och API: erna som delas mellan Android-enheter. Leverantörsimplementeringen innehåller leverantörens HALs (Hardware Abstraction Layers) och Linux-kärnan och Linux-kärnmodulerna.
Eftersom OEM-tillverkare skickar smartphones med många olika hårdvarukomponenter från många olika leverantörer, måste de göra mycket arbete bara för att få igång hårdvaran på en enda Android OS-version. Sedan med varje ny Android OS-uppdatering måste de göra ännu mer arbete för att se till att deras hårdvara fungerar med den nya versionen. Men med Project Treble som standardiserar ABI (Application Binary Interface) mellan Android OS-ramverket och HAL: er för en viss Android-version, Android OEM-tillverkare kan börja testa uppdateringar av sina enheter utan att behöva vänta på att kiseltillverkare och andra komponenttillverkare ska uppdatera sin sida av koden. Denna förändring påskyndas märkbart hur Android-uppdateringar hanteras.
Det är kärnan i vad Project Treble har gjort för Android-uppdateringar, men vad som är viktigare för app utvecklare här är att Treble har aktiverat användningen av Generic System Images (GSI) för kompatibilitet testning.
Uppkomsten av GSI
För att OEM-tillverkare ska kunna testa om de har implementerat Project Treble korrekt, kräver Google att OEM-tillverkaren ska kunna starta upp en ren version av Android från AOSP på enheten. Denna rena version av Android kallas Generic System Image, eller GSI. Om GSI startar och den mest grundläggande hårdvaran fungerar korrekt, vet OEM att deras enhet uppfyller Project Trebles krav. Det ursprungliga syftet med GSI: erna var alltså för att testa diskantkompatibilitet, men som vi har sett med utvecklingsgemenskapen här på XDA-Developers kan de användas för andra ändamål. Vi såg hur GSI skulle i princip tillåta enheter med tunga Android UX: er att njuta av den senaste versionen av Android med fungerande funktioner inom några dagar efter en ny release. Men Google föreställer sig ett annat syfte bakom GSI: att ge apputvecklare möjligheten att testa sina appar på en ny Android-version på en fysisk enhet som de redan äger.
Med Android 10 släppte Google sina egna GSI-byggen för utvecklare. Google cementerade idén att apputvecklare skulle använda en GSI för att starta upp en ren version av Android på sin egen hårdvara, vilket gör det lättare att testa deras applikations beteende mot vanliga Android. Denna metod lade alltså till de befintliga alternativen för att testa appkompatibilitet på lager Android utan OEM-beteendeförändringar, de andra använda en Pixel-smarttelefon, använda den officiella Android-emulatorn i Android Studio eller distribuera appbyggen till en enhetsinstans i molnet.
Trots all bekvämlighet som GSI: er förde med sig, var deras installation fortfarande en besvärlig process. Apputvecklare kanske inte är bekväma med att manuellt blinka en systembild på en Android-enhet eftersom detta är något som vanligtvis bara hobbyister eller Android OS-utvecklare är bekanta med. Installation av en GSI krävde att en systemavbildning blinkade över fastboot, vilket kräver att Android Verified Boot inaktiveras och starthanteraren låses upp. Upplåsning av bootloader kräver i sin tur en fullständig radering av användardata. Och som vi alla vet finns det inte exakt en enda process eller guide för att låsa upp starthanteraren för varje Android-enhet där ute, så det finns ingen konsekvens att hitta. Till exempel har Samsung-enheter inte fastboot medan Xiaomi-enheter får dig att hoppa genom några ringar för att låsa upp starthanteraren. Det är en bekväm röra som har potential att lösas in i något enklare.
Det är här dynamiska systemuppdateringar kommer in.
Dynamiska systemuppdateringar installerar helt enkelt GSI: er
Google insåg att den nuvarande metoden att installera GSI inte var en perfekt lösning, så de började arbeta på en bättre lösning. I Android 10, Google började testa dynamiska systemuppdateringar, eller DSU. DSU är ett nytt sätt att tillfälligt installera en GSI utan att behöva använda fastboot-kommandon för att flasha en systemavbildning och skriva över den ursprungliga installationen. Med DSU kan du starta upp i en GSI, testa din app och sedan bekvämt starta om till din ursprungliga installation som har förblivit orörd.
Anledningen till att DSU kan installera en GSI utan att röra den ursprungliga installationen är att den skapar nya system- och datapartitionsbilder som tillfälligt lagras i /data/gsi. Dessa bilder monteras sedan under uppstart istället för det ursprungliga systemet och datapartitionerna. Eftersom telefonen behöver ytterligare lagringsutrymme för dessa nya, tillfälliga bilder måste din telefon ha "logiska partitioner" ombord, som är dynamiskt storleksändringsbara partitioner. Logiska partitioner är ett nytt partitioneringssystem för användarutrymme för Android, som är obligatoriskt för enheter som startar med Android 10. Om din enhet startade med Android 10, bör den stödja installation av GSI: er via DSU.
I Android 10, allt du behöver göra för att installera en GSI via DSU är att ändra en systemegenskap och sedan starta DynamicSystemUpdatesInstallationService genom att skicka en avsikt med sökvägen till GSI som en avsiktsextra.
Även om den här processen kan verka obekant, är den mycket lättare och mindre påträngande jämfört med att använda fastboot-kommandon och ta itu med allt krångel, inklusive den ursprungliga installationen torkas. Du behöver viss kunskap om ADB och avsikter för att använda DSU, men detta borde inte vara ett problem för de flesta apputvecklare där ute. Ändå finns det ingen anledning att processen inte kunde göras ännu enklare. Dessutom finns det faktum att installation av en GSI via DSU fortfarande kräver att du låser upp starthanteraren, och torkar all användardata under processen. För detta ändamål har Google implementerat ändringar för att förbättra båda aspekterna av GSI-installationen. I Android 11 har de eliminerat behovet av att alls använda kommandoraden för att installera en GSI. Separat har de också gjort det möjligt att installera en GSI utan att låsa upp starthanteraren.
DSU Loader i Android 11
DSU Loader är ett nytt verktyg som finns i Android 11:s utvecklaralternativ som låter dig ladda ner och Installera den senaste GSI från Google utan att behöva mata in några fastboot- eller ADB-kommandon. Tryck bara på alternativet DSU Loader i Inställningar så visas en dialogruta med en lista över GSI: er som stöds direkt från Google. Dessa GSI: er som stöds kommer att baseras på ditt nuvarande operativsystem och din arkitektur, så du kan bara installera GSI: er som är nyare än din OS-version och som matchar din SoC-arkitektur. Välj helt enkelt den GSI som du vill installera så laddas den ned från Googles servrar och installeras automatiskt i bakgrunden.
Med DSU Loader behöver utvecklare aldrig röra kommandoraden för att installera en GSI. Åtminstone är det drömmen, för det finns fortfarande ett problem kvar att lösa.
Vägen framåt
För närvarande, för att installera en GSI via DSU Loader, behöver du en olåst bootloader. Även om detta kan besegra syftet med hela prövningen, är det inte meningen att det ska vara så, och vi får veta att det kommer att fixas. Google har planerat att användare ska kunna starta upp Google-signerade GSI: er via DSU utan att behöva låsa upp starthanteraren. Faktum är att Google kräver det alla Android 10 lanseringsenheter inkluderar Android Verified Boot offentliga nycklar av Google-signerade Android 10, Android 11 och Android 12 GSI. Att inkludera AVB publika nycklar i enhetens ramdisk kommer att säkerställa att AVB inte kommer att avvisa GSI som du försöker starta. Det är därför som den nuvarande metoden innebär att låsa upp starthanteraren - genom att flasha en tom vbmeta-bild till vbmeta-partitionen inaktiverar du AVB så att den inte kommer att avvisa den GSI du är på väg att flasha. Att inaktivera AVB är dock en stor säkerhetsrisk, eftersom det innebär att alla modifierade system/boot/produkt/leverantörspartition kan laddas på enheten, vilket är anledningen till att Google vill göra bort med det kravet.
Så när kan du förvänta dig att starta en GSI genom DSU utan att behöva låsa upp starthanteraren eller använda några kommandoradsverktyg? Förhoppningsvis snart, eftersom Google nämnde för oss att de hade några knep att stryka med de första Android 11 Developer Previews innan de kan få allt att fungera korrekt. Framöver kan man förvänta sig att installera framtida Developer Preview GSI: er via DSU utan att behöva låsa upp starthanteraren. Kanske när Android 12 Developer Previews görs tillgängliga, kommer du till och med att kunna starta den helt genom att använda DSU Loader i Android 11:s utvecklaralternativ. För apputvecklare betyder det att det kommer att finnas ytterligare ett sätt för dig att testa dina applikationer på fysisk hårdvara som kör en ny Android-version.