Har du någonsin velat testa en uppdatering utan att faktiskt uppdatera? DSU i Android 10 är designad för det, men den är för närvarande begränsad. Det kan snart ändras.
Android OS och fragmentering av säkerhetsnivån är ett stort problem som Google satsar mycket på att bekämpa. Under de senaste två åren tillkännagav Google två stora initiativ för att påskynda lanseringen av uppdateringar: Projekt Treble och Projekt huvudlinje. Det senare tillkännagavs först i maj under Google I/O 2019, och det stöds bara på enheter som startar med Android 10. Den förra har dock funnits sedan dess Google I/O 2017, så vi har sett hur stor inverkan det har haft på Android-uppdateringar med Android 9 Pie och Android 10.
Förutom att minska fragmenteringen vill Google också att Project Treble ska vara användbart för apputvecklare. Det var därför de avslöjade Dynamiska systemuppdateringar (DSU) i Android 10 för att låta utvecklare prova en barebones-version av en ny OS-uppdatering utan att låsa upp starthanteraren eller torka data. Med tanke på potentialen för DSU stannar Google inte där – de utökar dess användbarhet genom att göra det möjligt för OTA-uppdateringar från OEM-tillverkare att installeras på samma sätt som GSI: er är installerade.
Det är mycket jargong, men föreställ dig att det här händer i framtiden: en OEM släpper en telefon med Android 10 och startar ett betaprogram för Android 11. Du är intresserad av att testa denna beta för att se de nya funktionerna, men du vill inte riskera stabiliteten hos din nuvarande dagliga förare. Istället för att flasha betauppdateringen och sedan hoppas att den är helt stabil, varför inte tillfälligt installera den genom DSU-flödet? Om du inte gillar det är det bara att starta om så återgår inställningarna till det normala. Om du gillar det kan du "commit" till uppdateringen.
Jag vet inte hur det är med dig, men det här skulle vara en välkommen förändring av Android som skulle göra betatestningen roligare. Du skulle inte längre behöva förbinda dig till en betauppdatering bara för att själv se hur det är. Jag är säker på att många av er längtar efter att se en Android 10 beta för din enhet, men du kanske inte är bekväm med att installera den direkt. Med de ändringar som gjorts i DSU skulle det inte längre vara ett problem.
Dynamiska systemuppdateringar i Android 10+ - Vad förändras
Luca Stefani, en vän till XDA-portalen och en Erkänd utvecklare, informerade oss om en nytt åtagande slås samman i AOSP med titeln "montera flera DSU-partitioner när de finns." Commit gör ändringar i filsystemtabellen (fstab) och initiera processen för att göra det så att andra DSU-partitioner än systemet, för närvarande inklusive produkt och leverantör, kan monteras under uppstarten bearbeta.
För närvarande är DSU utformad för att endast låta dig starta upp en Generic System Image (GSI), en barebones-systemavbildning kompilerad från AOSP, så att du kan testa de nya API: erna och andra ändringar i den senaste Android-uppdateringen. Men med denna ändring kommer DSU också att acceptera produkt- och leverantörsbilder. Den förra innehåller enhetsspecifika appar, bibliotek och andra filer, medan den senare innehåller enhetsspecifika binärer. Project Treble gjorde det så att du kan starta upp en enhet med hjälp av en systemavbildning utan enhetsspecifika filer, så att nu tillåta laddning av produkt och leverantör verkar inte vara särskilt meningsfullt.
En Google-ingenjör säger dock uttryckligen att denna ändring är att "tillåta OEM-tillverkare att installera OTA-paket på /data, och sedan använda "DSU"-flödet för att montera product.img, system.img, [och] vendor.img från /data." Detta betyder att, istället för att skriva över den nuvarande installationen med det nya OTA-paketet, kan OTA laddas temporärt via DSU. Efter att ha provat OTA-uppdateringen, "kan användaren bestämma om de vill "commitera" dessa bilder till /super eller inte." Denna sista del om "att begå" ändringarna är fortfarande på gång, eftersom en Google-ingenjör noterar att "för närvarande har vi inte en plan att göra DSU-partitioner permanent under DSU-sammanhang." Han anger sedan hur detta skulle kunna genomföras, men att denna implementering ligger "utom räckvidden" för detta nuvarande patch.
Det finns några termer och begrepp vi behöver förklara här eftersom Google gillar att ändra partitionsschemat i varje Android-version. Till att börja med rekommenderar jag att läsa över min tidigare artikel om Dynamiska systemuppdateringar för en bred översikt av hur det fungerar, men sammanfattningsvis drar det fördel av konceptet med en "dynamisk partition", en riktig lagringspartition (kallad "super"-partitionen) som delas upp i logiska partitioner som kan ändras storlek (inklusive system, leverantör, produkt och system_ext), för att tillfälligt installera en GSI. När du installerar en GSI skapar DSU utrymme för det nya systemet och användardataavbildningarna genom att ändra storlek på den befintliga användardatapartitionen. Byggstenarna för DSU-stöd (dynamiska partitioner, en ramdisk och kontrollpunkter för säkerhetskopiering av data) är startkrav för Android 10, så alla enheter som lanseras med den nya Android OS-versionen bör stödja DSU. DSU är inte den dubbelstartslösning för anpassade ROM-skivor som vissa av er letar efter, eftersom endast bilder som matchar Android Verified Boot-nycklarna (AVB) kan installeras. Men med denna nya förändring kan den visa sig vara mycket mer användbar i framtiden.
Utöver dynamiska partitioner introducerade Google också konceptet "virtuell A/B" i Android 10. Detta är i grunden en implementering av dubbla A/B-partitioner sedan tidigare, men med logiska partitioner istället. A/B-partitioner innefattar kopior av viktiga partitioner för att möjliggöra sömlösa och säkra uppdateringar. Att använda "virtuell A/B" är hur en Google-ingenjör föreställer sig att "överlåta" DSU-partitionerna på partitionerna från den aktuella installationen; precis som med den nuvarande A/B OTA-uppdateringsprocessen, kanske ändringarna från de nya bilderna görs till den inaktiva partitionen.
Dessa förändringar är fortfarande under utveckling och kan ta lite tid innan de används av Google eller OEM. Vi kommer förmodligen inte att se några implementeringar av detta förrän Android 11 R tidigast släpps nästa år. Trots det finns det ingen garanti för att OEM-tillverkare ens använder den här funktionen för sina OTA-uppdateringar. Med tanke på hur användbart detta verkar vara för beta-testning, föreställer jag mig dock att Google redan arbetar med intresserade OEM-tillverkare för att aktivera den här funktionen för framtida uppdateringar. Jag är personligen glad över möjligheten att försöka-innan-köpa nya Android-uppdateringar, men hur är det med dig?