Har du nogensinde ønsket at prøve en opdatering uden faktisk at opdatere? DSU i Android 10 er designet til det, men det er i øjeblikket begrænset. Det kan snart ændre sig.
Android OS og fragmentering af sikkerhedsniveau er et stort problem, som Google investerer en masse ingeniørarbejde for at bekæmpe. I de seneste to år annoncerede Google to store initiativer designet til at fremskynde udrulningen af opdateringer: Projekt Diskant og Projekt Hovedlinje. Sidstnævnte blev først annonceret i maj i løbet af Google I/O 2019, og det understøttes kun på enheder, der starter med Android 10. Førstnævnte har dog eksisteret siden Google I/O 2017, så vi har set, hvor stor en indflydelse det har haft på Android-opdateringer med Android 9 Pie og Android 10.
Udover at reducere fragmentering, ønsker Google også, at Project Treble skal være nyttigt for app-udviklere. Derfor afslørede de Dynamiske systemopdateringer (DSU) i Android 10 for at lade udviklere prøve en barebones-version af en ny OS-opdatering uden at låse op for bootloaderen eller slette data. Da Google ser potentialet for DSU, stopper de ikke der – de udvider dets nytte ved at gøre det muligt for OTA-opdateringer fra OEM'er at blive installeret på samme måde som GSI'er er installeret.
Det er meget jargon, men forestil dig, at dette sker i fremtiden: en OEM frigiver en telefon med Android 10 og starter et betaprogram til Android 11. Du er interesseret i at prøve denne beta for at se de nye funktioner, men du ønsker ikke at risikere stabiliteten af din nuværende daglige chauffør. I stedet for at flashe betaopdateringen og så håbe, at den er helt stabil, hvorfor ikke midlertidigt installere den gennem DSU-flowet? Hvis du ikke kan lide det, skal du bare genstarte, og din opsætning vender tilbage til normal. Hvis du kan lide det, kan du "forpligte" dig til opdateringen.
Jeg ved ikke med dig, men dette ville være en velkommen ændring til Android, der ville gøre beta-testning mere behagelig. Du behøver ikke længere at forpligte dig til en betaopdatering bare for at se, hvordan det er for dig selv. Jeg er sikker på, at mange af jer klør efter at se en Android 10 beta til din enhed, men du er måske ikke tryg ved at installere den med det samme. Med ændringerne i DSU ville det ikke længere være et problem.
Dynamiske systemopdateringer i Android 10+ - Hvad ændrer sig
Luca Stefani, en ven af XDA-portalen og en Anerkendt udvikler, informeret os om en ny forpligtelse slået sammen i AOSP med titlen "monter flere DSU-partitioner, når de er til stede." Commit foretager ændringer i filsystemtabellen (fstab) og init-proces for at gøre det således, at andre DSU-partitioner end system, for nu inklusive produkt og leverandør, kan monteres under opstart behandle.
I øjeblikket er DSU designet til kun at lade dig starte et generisk systembillede (GSI), et barebones-systembillede kompileret fra AOSP, så du kan teste de nye API'er og andre ændringer i den seneste Android-opdatering. Men med denne ændring vil DSU også acceptere produkt- og leverandørbilleder. Førstnævnte indeholder enhedsspecifikke apps, biblioteker og andre filer, mens sidstnævnte indeholder enhedsspecifikke binære filer. Project Treble gjorde det, så du kan starte en enhed ved hjælp af et systembillede uden enhedsspecifikke filer, så nu at tillade indlæsning af produkt og leverandør, synes det ikke at give meget mening.
En Google-ingeniør siger dog udtrykkeligt, at denne ændring er at "tillade OEM'er [at] installere OTA-pakker på /data og derefter bruge ['DSU'-flowet til at montere product.img, system.img, [og] vendor.img fra /data." Dette betyder, at i stedet for at overskrive den aktuelle installation med den nye OTA-pakke, kan OTA'en midlertidigt indlæses via DSU. Efter at have prøvet OTA-opdateringen, "kan brugeren beslutte, om de vil 'commit' disse billeder til /super eller ej." Denne sidste del om at "forpligte" ændringerne er stadig i gang, da en Google-ingeniør bemærker, at "i øjeblikket har vi ikke en plan om at lave DSU-partitioner permanent under DSU-sammenhæng." Han oplyser derefter, hvordan dette kunne implementeres, men at denne implementering er "udenfor rammerne" af denne nuværende patch.
Der er nogle udtryk og begreber, vi skal forklare her, fordi Google kan lide at ændre partitionsskemaet i hver Android-version. Til at begynde med anbefaler jeg at læse min tidligere artikel om Dynamiske systemopdateringer for at få et bredt overblik over, hvordan det fungerer, men sammenfattende udnytter det konceptet med en "dynamisk partition", en rigtig lagringspartition (kaldet "super" partitionen), der bliver opdelt i logiske partitioner, der kan ændres størrelse (inklusive system, leverandør, produkt og system_ext), for midlertidigt at installere en GSI. Når du installerer en GSI, opretter DSU plads til det nye system og brugerdatabilleder ved at ændre størrelsen på den eksisterende brugerdatapartition. Byggestenene til DSU-understøttelse (dynamiske partitioner, en ramdisk og kontrolpunkter til sikkerhedskopiering af data) er startkrav til Android 10, så enhver enhed, der lanceres med den nye Android OS-version, bør understøtte DSU. DSU er ikke dual boot-løsningen til brugerdefinerede ROM'er, som nogle af jer leder efter, fordi kun billeder, der matcher Android Verified Boot-nøglerne (AVB) kan installeres. Men med denne nye ændring kan den vise sig at være meget mere nyttig i fremtiden.
Ud over dynamiske partitioner introducerede Google også konceptet "virtuel A/B" i Android 10. Dette er grundlæggende en implementering af dobbelte A/B-partitioner fra før, men med logiske partitioner i stedet for. A/B-partitioner involverer kopier af vigtige partitioner for at muliggøre problemfri og sikre opdateringer. Brug af "virtuel A/B" er, hvordan en Google-ingeniør forestiller sig at "committe" DSU-partitionerne til partitionerne fra den aktuelle installation; ligesom med den nuværende A/B OTA-opdateringsproces, er ændringerne fra de nye billeder måske lavet til den inaktive partition.
Disse ændringer er stadig under udvikling og kan tage noget tid, før de bliver brugt af Google eller OEM'er. Vi vil sandsynligvis ikke se nogen implementeringer af dette, før Android 11 R tidligst udkommer næste gang år. Alligevel er der ingen garanti for, at OEM'er overhovedet anvender denne funktion til deres OTA-opdateringer. I betragtning af hvor nyttigt dette ser ud til at være til beta-testning, forestiller jeg mig dog, at Google allerede arbejder med interesserede OEM'er for at aktivere denne funktion til fremtidige opdateringer. Jeg er personligt begejstret for udsigten til at prøve-inden-købe nye Android-opdateringer, men hvad med dig?