Har du noen gang ønsket å prøve en oppdatering uten å faktisk oppdatere? DSU i Android 10 er designet for det, men det er for øyeblikket begrenset. Det kan snart endre seg.
Android OS og fragmentering av sikkerhetsnivå er et stort problem som Google investerer mye ingeniørarbeid for å bekjempe. I løpet av de siste to årene har Google annonsert to store initiativer designet for å øke hastigheten på utrullingen av oppdateringer: Prosjekt diskant og Prosjekt hovedlinje. Sistnevnte ble først annonsert i mai i løpet av Google I/O 2019, og det støttes bare på enheter som starter med Android 10. Førstnevnte har imidlertid eksistert siden Google I/O 2017, så vi har sett hvor stor innvirkning det har hatt på Android-oppdateringer med Android 9 Pie og Android 10.
I tillegg til å redusere fragmentering, vil Google også at Project Treble skal være nyttig for apputviklere. Derfor avduket de Dynamiske systemoppdateringer (DSU) i Android 10 for å la utviklere prøve en barebones-versjon av en ny OS-oppdatering uten å låse opp bootloaderen eller tørke data. Ettersom Google ser potensialet for DSU, stopper de ikke der – de utvider verktøyet ved å gjøre det mulig for OTA-oppdateringer fra OEM-er å installeres på samme måte som GSI-er er installert.
Det er mye sjargong, men forestill deg at dette skjer i fremtiden: en OEM slipper en telefon med Android 10 og starter et betaprogram for Android 11. Du er interessert i å prøve denne betaversjonen for å se de nye funksjonene, men du vil ikke risikere stabiliteten til din nåværende daglige sjåfør. I stedet for å blinke betaoppdateringen og så håpe at den er helt stabil, hvorfor ikke installere den midlertidig gjennom DSU-flyten? Hvis du ikke liker det, er det bare å starte på nytt, og oppsettet vil gå tilbake til det normale. Hvis du liker det, kan du "forplikte deg" til oppdateringen.
Jeg vet ikke med deg, men dette ville være en velkommen endring til Android som ville gjøre betatesting morsommere. Du trenger ikke lenger å forplikte deg til en betaoppdatering bare for å se hvordan det er for deg selv. Jeg er sikker på at mange av dere klør etter å se en Android 10 beta for enheten din, men du er kanskje ikke komfortabel med å installere den med en gang. Med endringene som ble gjort i DSU, ville det ikke lenger være en bekymring.
Dynamiske systemoppdateringer i Android 10+ – Hva er i endring
Luca Stefani, en venn av XDA-portalen og en Anerkjent utvikler, informerte oss om en ny forpliktelse slått sammen i AOSP med tittelen "monter flere DSU-partisjoner når de er tilstede." Commit gjør endringer i filsystemtabellen (fstab) og starte prosessen for å gjøre det slik at andre DSU-partisjoner enn systemet, foreløpig inkludert produkt og leverandør, kan monteres under oppstart prosess.
Foreløpig er DSU designet for å bare la deg starte opp et generisk systembilde (GSI), et barebones-systembilde kompilert fra AOSP, slik at du kan teste de nye API-ene og andre endringer i den siste Android-oppdateringen. Men med denne endringen vil DSU også godta produkt- og leverandørbilder. Førstnevnte inneholder enhetsspesifikke apper, biblioteker og andre filer, mens sistnevnte inneholder enhetsspesifikke binærfiler. Project Treble gjorde det slik at du kan starte opp en enhet ved hjelp av et systembilde uten enhetsspesifikke filer, så det ser ikke ut til å være særlig fornuftig å tillate lasting av produkt og leverandør.
En Google-ingeniør sier imidlertid eksplisitt at denne endringen er å "tillate OEM-er å installere OTA-pakker på /data, og deretter bruke ['DSU'-flyten til å montere product.img, system.img, [og] vendor.img fra /data." Dette betyr at i stedet for å overskrive den nåværende installasjonen med den nye OTA-pakken, kan OTA lastes midlertidig inn via DSU. Etter å ha prøvd OTA-oppdateringen, "kan brukeren bestemme om de vil "forplikte" disse bildene til /super eller ikke." Denne siste delen om «å forplikte» endringene er fortsatt i arbeid, ettersom en Google-ingeniør bemerker at «for øyeblikket har vi ingen plan om å lage DSU-partisjoner permanent under DSU-sammenheng." Han uttaler deretter hvordan dette kunne implementeres, men at denne implementeringen er "utenfor omfanget" av dette gjeldende oppdatering.
Det er noen termer og konsepter vi må forklare her fordi Google liker å endre partisjonsskjemaet i hver Android-versjon. For det første anbefaler jeg å lese over min forrige artikkel om Dynamiske systemoppdateringer for en bred oversikt over hvordan det fungerer, men oppsummert drar det nytte av konseptet med en "dynamisk partisjon", en ekte lagringspartisjon (kalt "super"-partisjonen) som blir delt inn i logiske partisjoner som kan endres størrelse (inkludert system, leverandør, produkt og system_ext), for å midlertidig installere en GSI. Når du installerer en GSI, skaper DSU plass for det nye systemet og brukerdatabilder ved å endre størrelsen på den eksisterende brukerdatapartisjonen. Byggesteinene for DSU-støtte (dynamiske partisjoner, en ramdisk og sjekkpunkter for sikkerhetskopiering av data) er lanseringskrav for Android 10, så enhver enhet som lanseres med den nye Android OS-versjonen bør støtte DSU. DSU er ikke dual boot-løsningen for tilpassede ROM-er som noen av dere leter etter, fordi bare bilder som samsvarer med Android Verified Boot-nøklene (AVB) kan installeres. Men med denne nye endringen kan den vise seg å være mye mer nyttig i fremtiden.
På toppen av dynamiske partisjoner introduserte Google også konseptet "virtuell A/B" i Android 10. Dette er i utgangspunktet en implementering av doble A/B-partisjoner fra før, men med logiske partisjoner i stedet. A/B-partisjoner involverer kopier av viktige partisjoner for å tillate sømløse og sikre oppdateringer. Å bruke "virtuell A/B" er hvordan en Google-ingeniør ser for seg å "forplikte" DSU-partisjonene til partisjonene fra den gjeldende installasjonen; som med den nåværende A/B OTA-oppdateringsprosessen, er kanskje endringene fra de nye bildene gjort til den inaktive partisjonen.
Disse endringene er fortsatt under utvikling og kan ta litt tid før de blir brukt av Google eller OEM-er. Vi vil sannsynligvis ikke se noen implementeringer av dette før tidligst Android 11 R blir utgitt neste gang år. Likevel er det ingen garanti for at OEM-er til og med tar i bruk denne funksjonen for sine OTA-oppdateringer. Gitt hvor nyttig dette ser ut til å være for beta-testing, kan jeg imidlertid forestille meg at Google allerede jobber med interesserte OEM-er for å aktivere denne funksjonen for fremtidige oppdateringer. Jeg er personlig begeistret for utsiktene til å prøve-før-kjøpe nye Android-oppdateringer, men hva med deg?