Ett nytt projekt kallat Dynamic Android kommer att låta utvecklare testa AOSP Android Q GSI på alla enheter som kör Android Q eller senare.
Tack vare Projekt Treble, smartphone-enhetstillverkare har levererat Android Pie-programvaruuppdateringar snabbare än de kunde göra det för Android Oreo-uppdateringen, åtminstone för flaggskeppssmarttelefoner. Google vill dock inte se att endast OEM-tillverkare skördar fördelarna med Project Treble. Bolaget har tidigare uttryckt intresse när du släpper en generisk systembild (GSI) av Android Q för utvecklare så att de inte behöver förlita sig på emulatorer, använd en molntjänst, eller vänta på en uppdatering på sin egen enhet för att testa en app mot den senaste API-nivån. I teorin borde släppa en GSI tillåta alla utvecklare med en Project Treble-kompatibel enhet (ursprungligen Android 8.0 Oreo och uppåt, men anses nu bara vara enheter som lanseras med Android 9 Pie) för att testa den senaste Android version. Allt som utvecklaren behöver göra är att flasha en systemavbildning ovanpå sin befintliga programvaruinstallation – inget behov av en anpassad återställning, start eller leverantörsavbildning.
Det finns dock flera problem med den nuvarande GSI-installationsprocessen. Först behöver du en olåst bootloader, som är inte möjligt på Huawei- eller Honor-enheter (utan att betala en avgift), HMD Globals Nokia-enheter (exklusive Nokia 8), eller enheter från amerikanska operatörer. Nästa, den bearbeta kommer att vara svårt för alla som inte är bekanta med blinkande bilder via fastboot. Slutligen, om du blinkar en GSI nu måste du torka det interna minnet helt, vilket betyder att du förmodligen vill ha en reservenhet att testa på. Just nu är att blinka en GSI bara något som OEM-tillverkare använder för att testa Project Treble-kompatibilitet på sina enheter, och utöver det är det bara tilltalande för inbitna anpassade ROM-entusiaster. Googles nya "Dynamiska Android"-projekt kan se ut att ändra på det.
Dynamisk Android – Testa enkelt AOSP GSI på valfri Android Q-enhet
Under de senaste månaderna har Google arbetat på ett sätt att säkert starta upp en GSI utan att behöva låsa upp starthanteraren. Kort sagt, Google utvecklar en app som har speciella behörigheter som gör att den kan ladda ner en GSI, reservera lagringsutrymme för den och markera GSI som startbar. Det finns flera komponenter i det här projektet, så låt oss diskutera dem en i taget.
Dynamisk Android och Android On Tap
Två nya tjänster läggs till i Android Q: Dynamic Android och Android On Tap-tjänsterna. Medan Dynamic Android hanterar installationen av en GSI, informerar Android On Tap systemappar med återuppringningar och sändningsavsikter. Till exempel, Android On Tap varnar KeyguardManager för att be användaren att bekräfta en installationsförfrågan om enheten är skyddad av en PIN-kod, lösenord eller mönster. AOT varnar också användaren när de startas upp i en GSI.
Enligt beskrivningen för "DynamicAndroidManager" erbjuder tjänsten en mekanism för att använda en ny Android bild tillfälligt." Efter installationen kan enheten starta om till den nyligen installerade bilden med en nyskapad /data. Om du startar om i GSI: n återgår användaren till den ursprungliga systemavbildningen, men den nyinstallerade bilden och dess data inaktiveras bara och raderas inte. Om användaren väljer att göra det, kan GSI och dess data tas bort helt.
Källor: [1], [2], [3], [4]
GSID
GSI-demonen allokerar utrymme i /data-partitionen för att lagra GSI-avbildningen och dess data och för att göra bilden startbar. Metadata för GSI lagras i /metadata, medan GSI själv och dess data lagras i /data/gsi. Som standard allokerar GSID 8 GB användardata för den nyinstallerade GSI. I allmänhet letar GSID efter minst 40 % ledigt utrymme innan en installation påbörjas. Slutligen hindrar demonen användaren från att installera en GSI i en GSI, av uppenbara skäl.
Källor: [1], [2], [3], [4]
säkerhet
Android Verified Boot (AVB) är aktiverat för den nyinstallerade EXT4-systemavbildningen (system_gsi monterad på /system). Google har också implementerat SELinux-policyer för de nya tjänsterna. Slutligen kräver installation av en GSI att en app har den nya behörigheten MANAGE_DYNAMIC_ANDROID. Detta är en behörighet på signaturnivå vilket innebär att appen måste signeras av OEM.
Källor: [1], [2]
ADB- och Fastboot-kommandon
GSI: er kommer också att kunna installeras via nya ADB-kommandon. Det nya ADB gsi_tool-skalkommandot gör det möjligt för användare att inaktivera, återaktivera, installera och bevara användardata, installera och skapa användardata, installera och radera användardata, eller kontrollera statusen för installation.
gsi_tool - command-line tool for installing GSI images.
Usage:
gsi_tool <disable|install|wipe|status> [options]
disable Disable the currently installed GSI.
enable Enable a previously disabled GSI.
installInstall a new GSI. Specify the image sizewith
--gsi-size and the desired userdata size with
--userdata-size (the latter defaults to 8GiB)
--wipe (remove old gsi userdata first)
wipe Completely remove a GSI and its associated data
status Showstatus
Två nya fastboot-kommandon kommer att läggas till för att hantera GSI, även om fastboot-installationen inte stöds eftersom fastboot inte kan montera användardata.
fastboot gsi wipe
fastboot gsi disable
Källor: [1], [2]
Vem kommer detta att gynna?
Jag vill säga att apputvecklare kommer att kunna dra fördel av Dynamic Android och Android On Tap, men jag är inte helt säker. Även om Google har uttryckt intresse för just det, finns det ingen garanti för att den här funktionen kommer att vara tillgänglig i alla Android Q-släpp från OEM-tillverkare som inte tillhör Google. För att dra fördel av detta på enheten behöver programvaran en GSI-väljarapp som är signerad med samma certifikat som ROM. Jag är inte heller säker på att installation av GSI: er från ADB kommer att vara möjlig utan ADB-rot på grund av SELinux-policyer.Uppdatering: En ny begå bekräftar att ADB-rot kommer att krävas för att använda GSI_tool. Om detta inte är avsett för apputvecklare att testa sina appar på en ren version av Android, kommer det troligen bara gynna ingenjörer från OEM-tillverkare som vill testa Compatibility Test Suite (CTS) och Vendor Test Suite (VTS) på sina enheter.
Speciellt tack till XDA Recognized utvecklare luca020400 för hans hjälp i denna artikel.