Android 11 wordt geleverd met DSU Loader binnen de ontwikkelaaropties waarmee u compatibele GSI's automatisch kunt downloaden en installeren! Lees verder voor meer!
Een goed app-ecosysteem is een van de belangrijkste pijlers van het succes van een besturingssysteem. Zowel Google als Apple erkennen de waarde van het hebben van goede applicaties op hun platforms, en daarom proberen beide bedrijven de behoeften van hun gebruikers en hun app-ontwikkelaars in evenwicht te brengen. Gebruikers blijven aandringen op veranderingen in de besturingssystemen, en hoewel de meeste mensen over het algemeen nieuwe functies waarderen, zijn deze wijzigingen zijn niet altijd leuk voor app-ontwikkelaars, omdat ze veel van de kernfunctionaliteit kunnen veranderen en gedrag. Voor ontwikkelaars die voortdurend werken om hun apps relevant te houden, voegt het omgaan met deze veranderingen toe aan hun groeiende werklijst. Zelfs als deze wijzigingen niet direct van invloed zijn op hun applicaties, moeten ontwikkelaars er toch voor zorgen dat hun apps werken op de nieuwe OS-update. Google heeft in de loop der jaren veel veranderingen aangebracht om dit proces gemakkelijker te maken voor ontwikkelaars van Android-apps, en nu een nieuwe functie in Android 11, genaamd DSU Loader, zal het voor app-ontwikkelaars nog gemakkelijker maken om hun apps te testen op nieuwe Android versies.
Het begint met Project Treble
Project Treble, geïntroduceerd in Android 8.0, is een major re-architectuur van het Android OS. Het doel van Project Treble was om het Android-besturingssysteem op te splitsen in twee grote delen: het framework en de implementatie door de leverancier ("leverancier" verwijst hier naar de maker van een eigen hardwarecomponent die in een apparaat wordt gevonden, meestal verwijzend naar de silicium). Het Android OS-framework is het besturingssysteem zelf, inclusief alle systeem-apps, de gebruikersinterface en de bijbehorende componenten, en de API's die worden gedeeld op Android-apparaten. De implementatie van de leverancier bevat de HAL's (Hardware Abstraction Layers) van de leverancier en de Linux-kernel en Linux-kernelmodules.
Omdat OEM's smartphones leveren met veel verschillende hardwarecomponenten van veel verschillende leveranciers, moeten ze veel werk verzetten om de hardware op één enkele Android OS-release te laten werken. Vervolgens moeten ze bij elke nieuwe Android OS-update nog meer werk verzetten om ervoor te zorgen dat hun hardware werkt met de nieuwe versie. Maar met Project Treble die de ABI (Application Binary Interface) standaardiseert tussen het Android OS-framework en HAL's voor een bepaalde Android-versie, OEM's van Android kunnen beginnen met het testen van updates voor hun apparaten zonder te hoeven wachten tot siliciumfabrikanten en andere fabrikanten van componenten hun kant van updaten de code. Deze verandering is merkbaar versneld de manier waarop Android-updates worden afgehandeld.
Dat is de kern van wat Project Treble heeft gedaan voor Android-updates, maar wat belangrijker is voor de app ontwikkelaars hier is dat Treble het gebruik van generieke systeemafbeeldingen (GSI's) heeft ingeschakeld voor compatibiliteit testen.
De opkomst van GSI's
Om OEM's te laten testen of ze Project Treble correct hebben geïmplementeerd, schrijft Google voor dat de OEM een schone build van Android vanaf AOSP op het apparaat moet kunnen opstarten. Deze schone build van Android wordt de Generic System Image of GSI genoemd. Als de GSI opstart en de meeste basishardware goed functioneert, weet de OEM dat hun apparaat voldoet aan de eisen van Project Treble. Het oorspronkelijke doel van de GSI's was dus het testen van Treble-compatibiliteit, maar zoals we hebben gezien bij de ontwikkelingsgemeenschap hier bij XDA-Developers, kunnen ze voor andere doeleinden worden gebruikt. We zagen hoe GSI's zou apparaten met zware Android UX's in wezen binnen enkele dagen na een nieuwe release kunnen laten genieten van de nieuwste versie van Android met werkende functies. Maar Google ziet een ander doel achter de GSI: app-ontwikkelaars de mogelijkheid geven om hun apps te testen op een nieuwe Android-versie op een fysiek apparaat dat ze al bezitten.
Met Android 10 heeft Google zijn eigen GSI-builds uitgebracht voor ontwikkelaars. Google bevestigde het idee dat app-ontwikkelaars een GSI zouden moeten gebruiken om een schone build van Android op hun eigen hardware op te starten, waardoor het gemakkelijker wordt om het gedrag van hun applicatie te testen ten opzichte van stock-Android. Deze methode voegde dus toe aan de bestaande opties voor het testen van app-compatibiliteit op standaard Android zonder OEM-gedragsveranderingen, de andere zijn een Pixel-smartphone gebruiken, de officiële Android-emulator in Android Studio gebruiken of app-builds implementeren op een apparaatinstantie in de cloud.
Ondanks al het gemak dat GSI's met zich meebrachten, was hun installatie nog steeds een omslachtig proces. App-ontwikkelaars voelen zich misschien niet op hun gemak bij het handmatig flitsen van een systeemimage op een Android-apparaat, omdat dit iets is dat doorgaans alleen hobbyisten of Android OS-ontwikkelaars kennen. Voor het installeren van een GSI moest een systeemimage worden geflitst via fastboot, waarvoor Android Verified Boot moest worden uitgeschakeld en de bootloader moest worden ontgrendeld. Het ontgrendelen van de bootloader vereist op zijn beurt het volledig wissen van gebruikersgegevens. En zoals we allemaal weten, is er niet precies één proces of gids voor het ontgrendelen van de bootloader van elk Android-apparaat dat er is, dus er is geen consistentie te vinden. Samsung-apparaten hebben bijvoorbeeld geen fastboot, terwijl Xiaomi-apparaten je door een paar hoepels laten springen om de bootloader te ontgrendelen. Het is een handige puinhoop die het potentieel heeft om te worden ontward tot iets eenvoudigers.
Dit is waar dynamische systeemupdates binnenkomen.
Dynamische systeemupdates die eenvoudigweg GSI's installeren
Google realiseerde zich dat de huidige methode om GSI's te installeren geen perfecte oplossing was, dus gingen ze aan de slag met een betere oplossing. In Android 10, Google is begonnen met het testen van dynamische systeemupdates, of DSU. DSU is een nieuwe manier om tijdelijk een GSI te installeren zonder fastboot-commando's te gebruiken om een systeemkopie te flashen, waarbij de oorspronkelijke installatie wordt overschreven. Met DSU kunt u opstarten in een GSI, uw app testen en vervolgens gemakkelijk opnieuw opstarten naar uw oorspronkelijke installatie die onaangeroerd is gebleven.
De reden dat DSU een GSI kan installeren zonder de oorspronkelijke installatie aan te raken, is dat het nieuwe systeem- en gegevenspartitie-images aanmaakt die tijdelijk worden opgeslagen in /data/gsi. Deze afbeeldingen worden vervolgens tijdens het opstarten aangekoppeld in plaats van het originele systeem en de gegevenspartities. Omdat de telefoon extra opslagruimte nodig heeft voor deze nieuwe, tijdelijke afbeeldingen, moet uw telefoon "logische partities" aan boord hebben, dit zijn partities waarvan de grootte dynamisch kan worden aangepast. Logische partities zijn een nieuw partitiesysteem voor gebruikersruimten voor Android, dat verplicht is voor apparaten die starten met Android 10. Als uw apparaat is gelanceerd met Android 10, moet het de installatie van GSI's via DSU ondersteunen.
In Android 10 hoeft u alleen maar te doen installeer een GSI via DSU is om een systeemeigenschap te wijzigen en vervolgens het DynamicSystemUpdatesInstallationService door een intentie met het pad naar de GSI te sturen als extra intentie.
Hoewel dit proces misschien onbekend lijkt, is het veel gemakkelijker en minder opdringerig in vergelijking met het gebruik ervan fastboot-commando's en omgaan met het gedoe van alles, inclusief de originele installatie, zijn gewist. Je hebt wel enige kennis van ADB en intenties nodig om DSU te gebruiken, maar dit zou voor de meeste app-ontwikkelaars geen probleem moeten zijn. Toch is er geen reden waarom het proces niet nog eenvoudiger zou kunnen worden gemaakt. Bovendien moet je voor het installeren van een GSI via DSU nog steeds de bootloader ontgrendelen en daarbij alle gebruikersgegevens wissen. Daartoe heeft Google wijzigingen doorgevoerd om beide aspecten van de GSI-installatie te verbeteren. In Android 11 is het helemaal niet meer nodig om de opdrachtregel te gebruiken om een GSI te installeren. Afzonderlijk hebben ze het ook mogelijk gemaakt om een GSI te installeren zonder de bootloader te ontgrendelen.
DSU-lader in Android 11
DSU Loader is een nieuwe tool die aanwezig is in de ontwikkelaarsopties van Android 11 waarmee u dit kunt doen downloaden En installeren de nieuwste GSI van Google zonder dat u fastboot- of ADB-opdrachten hoeft in te voeren. Tik gewoon op de optie DSU Loader in Instellingen en er verschijnt een dialoogvenster met een lijst met ondersteunde GSI's rechtstreeks van Google. Deze ondersteunde GSI's zijn gebaseerd op uw huidige besturingssysteem en architectuur, dus u kunt alleen GSI's installeren die nieuwer zijn dan uw besturingssysteemversie en die overeenkomen met uw SoC-architectuur. Kies gewoon de GSI die u wilt installeren en deze wordt gedownload van de servers van Google en automatisch op de achtergrond geïnstalleerd.
Met DSU Loader hoeven ontwikkelaars nooit de opdrachtregel aan te raken om een GSI te installeren. Dat is tenminste de droom, want er is nog één probleem dat moet worden opgelost.
De weg vooruit
Momenteel heb je een ontgrendelde bootloader nodig om een GSI via DSU Loader te installeren. Hoewel dit het doel van de hele beproeving kan verslaan, is het niet de bedoeling dat het zo is, en er is ons verteld dat het zal worden opgelost. Google heeft gepland dat gebruikers door Google ondertekende GSI's kunnen opstarten via DSU zonder de bootloader te hoeven ontgrendelen. In feite stelt Google dat verplicht alle Android 10-startapparaten bevatten de openbare Android Verified Boot-sleutels van door Google ondertekende GSI's voor Android 10, Android 11 en Android 12. Door de openbare AVB-sleutels in de ramdisk van het apparaat op te nemen, zorgt u ervoor dat AVB de GSI die u probeert op te starten, niet weigert. Dit is de reden waarom de huidige methode het ontgrendelen van de bootloader inhoudt - door een lege vbmeta-afbeelding naar de vbmeta-partitie te flashen, schakel je AVB uit zodat het de GSI die je gaat flashen niet weigert. Het uitschakelen van AVB is echter een groot beveiligingsrisico, omdat het betekent dat elke gewijzigde systeem/boot/product/vendor-partitie kan op het apparaat worden geladen, en daarom wil Google dat doen weg met die eis.
Dus wanneer kun je verwachten een GSI op te starten via DSU zonder de bootloader te ontgrendelen of opdrachtregelprogramma's te gebruiken? Hopelijk snel, zoals Google tegen ons zei dat ze een paar problemen hadden met de eerste Android 11 Developer Previews voordat ze dit allemaal goed konden laten werken. In de toekomst kan men verwachten toekomstige Developer Preview GSI's via DSU te installeren zonder de bootloader te hoeven ontgrendelen. Misschien kun je, wanneer Android 12 Developer Previews beschikbaar worden gemaakt, het zelfs volledig opstarten door DSU Loader te gebruiken in Android 11's Developer Options. Voor app-ontwikkelaars betekent dit dat er nog een andere manier is waarop u uw applicaties kunt testen op fysieke hardware met een nieuwe Android-versie.