Android 11 wird mit dem DSU Loader in den Entwickleroptionen geliefert, mit dem Sie kompatible GSIs automatisch herunterladen und installieren können! Lesen Sie weiter für mehr!
Ein gutes App-Ökosystem ist eine der wichtigsten Säulen für den Erfolg eines Betriebssystems. Sowohl Google als auch Apple erkennen den Wert guter Anwendungen auf ihren Plattformen und versuchen daher, die Bedürfnisse ihrer Nutzer und ihrer App-Entwickler in Einklang zu bringen. Benutzer drängen weiterhin auf Änderungen an den Betriebssystemen, und obwohl die meisten Menschen im Allgemeinen neue Funktionen zu schätzen wissen, sind diese Änderungen machen App-Entwicklern nicht immer Spaß, da sie viele Kernfunktionen verändern können Verhalten. Für Entwickler, die ständig daran arbeiten, ihre Apps relevant zu halten, erweitert die Bewältigung dieser Änderungen ihre wachsende Arbeitsliste. Auch wenn sich diese Änderungen nicht direkt auf ihre Anwendungen auswirken, müssen Entwickler dennoch sicherstellen, dass ihre Apps mit dem neuen Betriebssystem-Update funktionieren. Google hat im Laufe der Jahre viele Änderungen vorgenommen, um diesen Prozess für Android-App-Entwickler zu vereinfachen, und jetzt eine neue Die Funktion in Android 11 namens DSU Loader wird es App-Entwicklern noch einfacher machen, ihre Apps auf dem neuen Android zu testen Versionen.
Es beginnt mit Project Treble
Project Treble, eingeführt in Android 8.0, ist ein Major Neuarchitektur des Android-Betriebssystems. Das Ziel von Project Treble bestand darin, das Android-Betriebssystem in zwei große Teile aufzuteilen: das Framework und die Anbieterimplementierung („Anbieter“ bezieht sich hier auf den Hersteller einer proprietären Hardwarekomponente, die sich in einem Gerät befindet, und bezieht sich normalerweise auf die Silizium). Das Android OS-Framework ist das Betriebssystem selbst, einschließlich aller System-Apps, der Benutzeroberfläche und ihrer Komponenten sowie der APIs, die von allen Android-Geräten gemeinsam genutzt werden. Die Anbieterimplementierung enthält die Anbieter-HALs (Hardware Abstraction Layers) sowie den Linux-Kernel und die Linux-Kernel-Module.
Da OEMs Smartphones mit vielen verschiedenen Hardwarekomponenten von vielen verschiedenen Anbietern ausliefern, müssen sie viel Arbeit leisten, um die Hardware auf einer einzigen Android-Betriebssystemversion zum Laufen zu bringen. Dann müssen sie mit jedem neuen Android-Betriebssystem-Update noch mehr Arbeit leisten, um sicherzustellen, dass ihre Hardware mit der neuen Version funktioniert. Aber da Project Treble das ABI (Application Binary Interface) zwischen dem Android-Betriebssystem-Framework und HALs für eine bestimmte Android-Version standardisiert, Android-OEMs können mit dem Testen von Updates für ihre Geräte beginnen, ohne darauf warten zu müssen, dass Siliziumhersteller und andere Komponentenhersteller ihre Seite aktualisieren der Code. Dieser Wandel beschleunigte sich spürbar die Art und Weise, wie Android-Updates gehandhabt werden.
Das ist der Kern dessen, was Project Treble für Android-Updates getan hat, aber was für Apps noch wichtiger ist Der Hauptgrund für die Entwickler ist, dass Treble aus Kompatibilitätsgründen die Verwendung von Generic System Images (GSIs) aktiviert hat testen.
Die Entstehung von GSIs
Damit OEMs testen können, ob sie Project Treble ordnungsgemäß implementiert haben, verlangt Google, dass der OEM in der Lage sein muss, eine saubere Android-Version von AOSP auf dem Gerät zu booten. Dieser saubere Build von Android wird Generic System Image oder GSI genannt. Wenn das GSI startet und die meisten grundlegenden Hardwarefunktionen ordnungsgemäß funktionieren, weiß der OEM, dass sein Gerät die Anforderungen von Project Treble erfüllt. Der ursprüngliche Zweck der GSIs bestand also darin, die Treble-Kompatibilität zu testen, aber wie wir bei der Entwickler-Community hier bei XDA-Developers gesehen haben, können sie für andere Zwecke verwendet werden. Wir haben gesehen, wie GSIs könnte es Geräten mit umfangreichen Android-UXs im Wesentlichen ermöglichen, innerhalb weniger Tage nach einer neuen Veröffentlichung die neueste Version von Android mit funktionierenden Funktionen zu genießen. Aber Google sieht hinter dem GSI noch einen anderen Zweck: App-Entwicklern die Möglichkeit zu geben, ihre Apps auf einer neuen Android-Version auf einem physischen Gerät zu testen, das sie bereits besitzen.
Mit Android 10 hat Google eigene GSI-Builds für Entwickler veröffentlicht. Google hat die Idee gefestigt, dass App-Entwickler einen GSI verwenden sollten, um eine saubere Version von Android auf ihrer eigenen Hardware zu starten, wodurch es einfacher wird, das Verhalten ihrer Anwendung im Vergleich zu Standard-Android zu testen. Diese Methode ergänzt somit die bestehenden Möglichkeiten, die App-Kompatibilität auf Standard-Android zu testen, ohne dass sich das OEM-Verhalten ändert Verwenden eines Pixel-Smartphones, Verwenden des offiziellen Android-Emulators in Android Studio oder Bereitstellen von App-Builds auf einer Geräteinstanz in der Cloud.
Trotz aller Bequemlichkeit, die GSIs mit sich brachten, war ihre Installation immer noch ein umständlicher Prozess. App-Entwickler sind möglicherweise nicht mit dem manuellen Flashen eines Systemabbilds auf einem Android-Gerät vertraut, da dies normalerweise nur Bastlern oder Entwicklern von Android-Betriebssystemen vertraut ist. Die Installation eines GSI erforderte das Flashen eines Systemabbilds über Fastboot, was das Deaktivieren von Android Verified Boot und das Entsperren des Bootloaders erfordert. Das Entsperren des Bootloaders erfordert wiederum eine vollständige Löschung der Benutzerdaten. Und wie wir alle wissen, gibt es nicht genau einen einzigen Prozess oder eine Anleitung zum Entsperren des Bootloaders für jedes Android-Gerät, sodass keine Konsistenz zu finden ist. Samsung-Geräte verfügen beispielsweise nicht über Fastboot, während Sie bei Xiaomi-Geräten ein paar Hürden überwinden müssen, um den Bootloader zu entsperren. Es ist ein praktisches Durcheinander, das das Potenzial hat, in etwas Einfacheres entwirrt zu werden.
Hier kommen dynamische Systemaktualisierungen ins Spiel.
Dynamische Systemaktualisierungen, bei denen einfach GSIs installiert werden
Google erkannte, dass die aktuelle Methode zur Installation von GSIs keine perfekte Lösung war und begann daher, an einer besseren Lösung zu arbeiten. In Android 10, Google hat mit dem Testen dynamischer Systemaktualisierungen begonnen, oder DSU. DSU ist eine neue Möglichkeit, ein GSI vorübergehend zu installieren, ohne Fastboot-Befehle zum Flashen eines Systemabbilds verwenden zu müssen und dabei die ursprüngliche Installation zu überschreiben. Mit DSU können Sie ein GSI starten, Ihre App testen und dann bequem mit Ihrer Originalinstallation neu starten, die unberührt geblieben ist.
Der Grund dafür, dass DSU ein GSI installieren kann, ohne die ursprüngliche Installation zu beeinträchtigen, besteht darin, dass es neue System- und Datenpartitionsabbilder erstellt, die vorübergehend darin gespeichert werden /data/gsi. Diese Images werden dann beim Booten gemountet und nicht die ursprünglichen System- und Datenpartitionen. Da das Telefon zusätzlichen Speicherplatz für diese neuen, temporären Bilder benötigt, muss Ihr Telefon über „logische Partitionen“ verfügen, bei denen es sich um dynamisch in der Größe veränderbare Partitionen handelt. Logische Partitionen sind ein neues Userspace-Partitionierungssystem für Android, das für Geräte mit Android 10 obligatorisch ist. Wenn Ihr Gerät mit Android 10 gestartet wurde, sollte es die Installation von GSIs über DSU unterstützen.
In Android 10 ist alles, was Sie tun müssen Installieren Sie ein GSI über DSU besteht darin, eine Systemeigenschaft zu ändern und dann das zu starten DynamicSystemUpdatesInstallationService durch Senden eines Intents mit dem Pfad zum GSI als Intent-Extra.
Obwohl dieser Vorgang ungewohnt erscheinen mag, ist er im Vergleich zur Verwendung weitaus einfacher und weniger aufdringlich Fastboot-Befehle und der Umgang mit allem, einschließlich der ursprünglichen Installation abgewischt. Sie benötigen zwar einige ADB-Kenntnisse und die Absicht, DSU zu nutzen, aber dies sollte für die meisten App-Entwickler da draußen kein Problem darstellen. Dennoch gibt es keinen Grund, warum der Prozess nicht noch einfacher gestaltet werden könnte. Hinzu kommt, dass Sie bei der Installation eines GSI über DSU immer noch den Bootloader entsperren müssen und dabei alle Benutzerdaten löschen. Zu diesem Zweck hat Google Änderungen vorgenommen, um beide Aspekte der GSI-Installation zu verbessern. In Android 11 ist die Verwendung der Befehlszeile zur Installation eines GSI überhaupt nicht mehr erforderlich. Unabhängig davon haben sie es auch ermöglicht, ein GSI zu installieren, ohne den Bootloader zu entsperren.
DSU Loader in Android 11
DSU Loader ist ein neues Tool in den Entwickleroptionen von Android 11, das Ihnen dies ermöglicht herunterladen Und Installieren das neueste GSI von Google, ohne dass Fastboot- oder ADB-Befehle eingegeben werden müssen. Tippen Sie einfach in den Einstellungen auf die Option „DSU Loader“. Daraufhin wird ein Dialogfeld mit einer Liste der unterstützten GSIs direkt von Google angezeigt. Diese unterstützten GSIs basieren auf Ihrem aktuellen Betriebssystem und Ihrer aktuellen Architektur. Sie können also nur GSIs installieren, die neuer als Ihre Betriebssystemversion sind und zu Ihrer SoC-Architektur passen. Wählen Sie einfach das GSI aus, das Sie installieren möchten. Es wird dann automatisch von den Google-Servern heruntergeladen und im Hintergrund installiert.
Mit DSU Loader müssen Entwickler nie die Befehlszeile berühren, um ein GSI zu installieren. Zumindest ist das der Traum, denn es gibt noch ein Problem zu lösen.
Der Weg nach vorn
Um ein GSI über den DSU Loader zu installieren, benötigen Sie derzeit einen entsperrten Bootloader. Auch wenn dies den Zweck der ganzen Tortur zunichte machen könnte, sollte es nicht so sein, und uns wurde gesagt, dass es behoben wird. Google hat geplant, dass Benutzer von Google signierte GSIs über DSU starten können, ohne den Bootloader entsperren zu müssen. Tatsächlich schreibt Google dies vor Alle Android 10-Startgeräte enthalten die öffentlichen Android Verified Boot-Schlüssel der von Google signierten Android 10-, Android 11- und Android 12-GSIs. Durch das Einfügen der öffentlichen AVB-Schlüssel in die Ramdisk des Geräts wird sichergestellt, dass AVB das GSI, das Sie starten möchten, nicht ablehnt. Aus diesem Grund umfasst die aktuelle Methode das Entsperren des Bootloaders. Indem Sie ein leeres Vbmeta-Image auf die Vbmeta-Partition flashen, deaktivieren Sie AVB, sodass das GSI, das Sie flashen möchten, nicht abgelehnt wird. Das Deaktivieren von AVB stellt jedoch ein großes Sicherheitsrisiko dar, da dadurch Änderungen vorgenommen werden system/boot/product/vendor-Partition kann auf das Gerät geladen werden, weshalb Google dies tun möchte Weg mit dieser Anforderung.
Wann können Sie also damit rechnen, ein GSI über DSU zu starten, ohne den Bootloader entsperren oder Befehlszeilentools verwenden zu müssen? Hoffentlich bald, denn Google hat uns gegenüber erwähnt, dass mit den ersten Entwicklervorschauen für Android 11 noch ein paar Probleme behoben werden müssen, bevor das alles richtig funktioniert. In Zukunft kann man damit rechnen, zukünftige Developer Preview GSIs über DSU zu installieren, ohne den Bootloader entsperren zu müssen. Wenn Entwicklervorschauen für Android 12 verfügbar sind, können Sie es vielleicht sogar vollständig starten, indem Sie den DSU Loader in den Entwickleroptionen von Android 11 verwenden. Für App-Entwickler bedeutet dies, dass es eine weitere Möglichkeit gibt, Ihre Anwendungen auf physischer Hardware mit einer neuen Android-Version zu testen.