Heb je ooit een update willen proberen zonder daadwerkelijk te updaten? DSU in Android 10 is daarvoor ontworpen, maar is momenteel beperkt. Dat zou snel kunnen veranderen.
De fragmentatie van het Android-besturingssysteem en het beveiligingsniveau is een enorm probleem en Google investeert veel technische inspanningen om dit te bestrijden. De afgelopen twee jaar heeft Google twee belangrijke initiatieven aangekondigd om de uitrol van updates te versnellen: Project Treble En Project Hoofdlijn. Dit laatste werd pas in mei dit jaar aangekondigd Google I/O 2019en wordt alleen ondersteund op apparaten die worden gestart met Android 10. De eerste bestaat echter sindsdien Google I/O 2017, dus we hebben gezien hoeveel impact het heeft gehad op Android-updates met Android 9 Pie En Android 10.
Naast het verminderen van fragmentatie wil Google ook dat Project Treble nuttig is voor app-ontwikkelaars. Daarom hebben ze het onthuld Dynamische systeemupdates (DSU) in Android 10 om ontwikkelaars een barebones-versie van een nieuwe OS-update te laten proberen zonder de bootloader te ontgrendelen of gegevens te wissen. Google ziet het potentieel voor DSU en stopt daar niet: ze breiden het nut ervan uit door het mogelijk te maken dat OTA-updates van OEM's op dezelfde manier worden geïnstalleerd als GSI's.
Dat is veel jargon, maar stel je voor dat dit in de toekomst gebeurt: een OEM brengt een telefoon uit met Android 10 en start een bètaprogramma voor Android 11. U bent geïnteresseerd in het uitproberen van deze bèta om de nieuwe functies te zien, maar u wilt de stabiliteit van uw huidige dagelijkse driver niet op het spel zetten. In plaats van de bèta-update te flashen en dan te hopen dat deze volkomen stabiel is, waarom installeert u deze dan niet tijdelijk via de DSU-stroom? Als het u niet bevalt, start u gewoon opnieuw op en wordt uw installatie weer normaal. Als het je bevalt, kun je je "committeren" aan de update.
Ik weet niet hoe het met jou zit, maar dit zou een welkome verandering in Android zijn die bètatesten leuker zou maken. U hoeft zich niet langer te binden aan een bèta-update om zelf te zien hoe deze is. Ik weet zeker dat velen van jullie graag een Android 10-bètaversie voor je apparaat willen zien, maar het kan zijn dat je het niet meteen op je gemak vindt om het te installeren. Met de wijzigingen in DSU zou dat geen probleem meer zijn.
Dynamische systeemupdates in Android 10+ - Wat verandert er?
Luca Stefani, een vriend van de XDA Portal en een Erkende ontwikkelaar, informeerde ons over een nieuwe toezegging samengevoegd in AOSP met de titel "mount meerdere DSU-partities indien aanwezig." De commit brengt wijzigingen aan in de bestandssysteemtabel (fstab) en de init-proces om ervoor te zorgen dat andere DSU-partities dan het systeem, voorlopig inclusief product en leverancier, tijdens het opstarten kunnen worden aangekoppeld proces.
Momenteel is DSU ontworpen om u alleen een Generic System Image (GSI) te laten opstarten, een barebones-systeemimage samengesteld uit AOSP, zodat u de nieuwe API's en andere wijzigingen in de nieuwste Android-update kunt testen. Met deze wijziging accepteert DSU echter ook product- en leveranciersafbeeldingen. De eerste bevat apparaatspecifieke apps, bibliotheken en andere bestanden, terwijl de laatste apparaatspecifieke binaire bestanden bevat. Project Treble heeft het zo gemaakt dat je een apparaat kunt opstarten met een systeemimage zonder apparaatspecifieke bestanden, dus het lijkt niet zo logisch om nu het laden van product en leverancier toe te staan.
Een Google-ingenieur zegt echter expliciet dat deze wijziging bedoeld is om "OEM's toe te staan OTA-pakketten te installeren op /data en vervolgens [de] 'DSU'-stroom te gebruiken om product.img te mounten, system.img, [en] vendor.img uit /data." Dit betekent dat, in plaats van de huidige installatie te overschrijven met het nieuwe OTA-pakket, de OTA tijdelijk kan worden geladen via DSU. Na het uitproberen van de OTA-update, "kan de gebruiker beslissen of hij die afbeeldingen wil 'commiteren' naar /super of niet." Dit laatste deel gaat over Het 'doorvoeren' van de wijzigingen is nog in de maak, zoals een Google-ingenieur opmerkt dat 'we momenteel geen plan hebben om DSU-partities te maken permanent onder de DSU-context." Vervolgens stelt hij hoe dit geïmplementeerd zou kunnen worden, maar dat deze implementatie "buiten de reikwijdte" van dit document ligt. huidige pleister.
Er zijn enkele termen en concepten die we hier moeten uitleggen, omdat Google het partitieschema in elke Android-versie graag verandert. Om te beginnen raad ik aan mijn vorige artikel over Dynamische systeemupdates voor een breed overzicht van hoe het werkt, maar kort samengevat profiteert het van het concept van een ‘dynamische partitie’, een echte opslagpartitie (genaamd de "super" partitie) die wordt opgedeeld in aanpasbare logische partities (inclusief systeem, leverancier, product en system_ext), om tijdelijk een GSI. Bij het installeren van een GSI creëert DSU ruimte voor het nieuwe systeem en de userdata-images door de grootte van de bestaande userdata-partitie aan te passen. De bouwstenen voor DSU-ondersteuning (dynamische partities, een ramdisk en controlepunten voor gegevensback-ups) zijn startvereisten voor Android 10, dus elk apparaat dat wordt gelanceerd met de nieuwe Android OS-versie zou DSU moeten ondersteunen. DSU is niet de dual-boot-oplossing voor aangepaste ROM's waar sommigen van jullie naar op zoek zijn, omdat alleen images die overeenkomen met de Android Verified Boot (AVB) -sleutels kunnen worden geïnstalleerd. Met deze nieuwe verandering zou het in de toekomst echter veel nuttiger kunnen zijn.
Naast dynamische partities introduceerde Google ook het concept van ‘virtuele A/B’ in Android 10. Dit is feitelijk een implementatie van de dubbele A/B-partities van vroeger, maar in plaats daarvan met logische partities. Bij A/B-partities zijn kopieën van belangrijke partities betrokken, zodat naadloze en veilige updates mogelijk zijn. Het gebruik van 'virtuele A/B' is hoe een Google-ingenieur zich voorstelt om de DSU-partities 'vast te leggen' op de partities van de huidige installatie; net als bij het huidige A/B OTA-updateproces worden de wijzigingen van de nieuwe images mogelijk aangebracht op de inactieve partitie.
Deze wijzigingen zijn nog in ontwikkeling en het kan enige tijd duren voordat ze door Google of OEM's worden gebruikt. Wij zal waarschijnlijk geen implementaties hiervan zien totdat Android 11 R op zijn vroegst wordt uitgebracht jaar. Toch is er geen garantie dat OEM's deze functie zelfs gebruiken voor hun OTA-updates. Gezien hoe nuttig dit lijkt te zijn voor bètatests, kan ik me echter voorstellen dat Google al samenwerkt met geïnteresseerde OEM's om deze functie in te schakelen voor toekomstige updates. Persoonlijk ben ik enthousiast over het vooruitzicht om nieuwe Android-updates uit te proberen voordat ik ze koop, maar hoe zit het met jou?