Dynamische Systemaktualisierungen in Android F: Wie Project Treble zukünftige Android-Versionen verbessern wird

Parallel zur Veröffentlichung von Android 8.0 Oreo stellte Google vor Projekt Treble: eine wesentliche Neuarchitektur in der Art und Weise, wie das Android-Betriebssystem-Framework und die Hersteller-HALs und der Linux-Kernel kommunizieren. Treble ist eine große Initiative zur Reduzierung der Android-Plattformversion und Fragmentierung von Sicherheitspatches, und alle Geräte der Marke Android, die mit Android Pie gestartet werden, müssen Project Treble unterstützen. OEMs und Anbieter testen die Treble-Kompatibilität, indem sie ein Generic System Image (GSI) – eine reine Standardversion von Android von AOSP – booten und das übergeben Anbieter-Testsuite (VTS) und Compatibility Test Suite-on-Generic System Image (CTS-on-GSI). Das GSI hat sich nicht nur als nützlich erwiesen, da es Software-Ingenieuren, die für OEMs arbeiten, ermöglicht, die Treble-Kompatibilität zu testen, sondern es hat auch die Tür für eine geöffnet

große Custom-ROM-Community auf XDA. Für die Veröffentlichung von Android Q möchte Google GSIs für eine andere Gruppe nützlich machen: App-Entwickler.

Da normalerweise die erste stabile Version und der Quellcode-Drop einer bestimmten Android-Plattformversion erfolgt im AugustEntwickler, die die nächste Android-Version auf einem echten Gerät testen möchten, benötigen normalerweise Zugriff auf ein Google-Smartphone, wenn sie nicht warten möchten, bis das Update ihre eigene Hardware erreicht. Google arbeitete jedoch mit OEMs zusammen, um eine zu bringen Android P Beta auf mehrere Geräte im letzten Jahr, und dieses Jahr haben sie mit einem nachgelegt Android Q-Beta. Neben einer offiziellen Android Q-Beta veröffentlichte Google dieses Jahr auch eine offizielles Q-Beta-GSI So kann jeder Entwickler mit einem Project Treble-kompatiblen Gerät die neueste Q-Version installieren, ohne Monate warten zu müssen, bis der Build seine Geräte erreicht. Diese neue Art, die nächste Android-Version zu testen, gibt Entwicklern mehr Möglichkeiten und damit mehr Zeit, ihre Apps anhand dieser zu testen große Änderungen in Android.

Leider ist die aktuelle Methode von Installation eines GSI kann schwierig sein. Dazu ist es erforderlich, den Bootloader zu entsperren – was das Löschen aller Benutzerdaten und/oder den Erlöschen der Garantie bedeutet – und ein Image über das Fastboot-Protokoll zu flashen. Es ist kein schneller und einfacher Prozess für einen App-Entwickler, wenn er sein Gerät verwendet Ermöglicht sogar das Entsperren des Bootloaders. Deshalb, für die vergangenen MonatenGoogle hat an einer neuen Möglichkeit zum Booten von GSIs gearbeitet. Geben Sie eine neue Funktion namens Dynamic System Update oder DSU ein.

(Diese Funktion wurde zuvor unter den Namen „Live Image“, „Dynamic Android“ und „Android on Tap“ entwickelt. Seien Sie also nicht überrascht, wenn Google sie in ein paar Wochen oder Monaten anders nennt.)

Dynamische Systemaktualisierungen in Android Q

Das Ziel der DSU-Funktion besteht darin, einem Entwickler das Booten in ein GSI zu ermöglichen, ohne die aktuelle Installation zu beeinträchtigen. Das bedeutet, dass der Bootloader nicht entsperrt werden muss und die Benutzerdaten nicht gelöscht werden müssen. Auch der Installationsprozess wird stark vereinfacht, da Google eine Kommandozeilenschnittstelle über ADB und eine über Intents steuerbare App bereitgestellt hat. So sieht es aus, ein GSI mit DSU zu starten:

In diesem Video* wird ein Google Pixel 3 XL mit Android Q Beta 3 in einem GSI neu gestartet. In dieser Umgebung kann ein App-Entwickler seine App installieren und auf Q-API-Kompatibilität testen. Wenn sie mit dem Testen fertig sind, können sie einfach mit der regulären Q Beta 3-Software auf dem Gerät neu starten. Im Grunde booten Sie ein GSI doppelt, damit Sie Ihre App sicher testen können!

*Wir haben dieses Video auf der Google I/O 2019 aufgenommen, als DSU noch nicht öffentlich verfügbar war. Daher wurde der Q Beta 3-Build auf dem gefilmten Pixel 3 XL von Google leicht modifiziert, um DSU-Unterstützung zu ermöglichen. Geräte mit Q Beta 4 und höher sind zur Unterstützung von DSU berechtigt, wenn sie die folgenden Anforderungen erfüllen.

Anforderungen für dynamische Systemaktualisierungen

Für Google war es keine leichte Aufgabe, das, was im Grunde ein Dual-Boot-System ist, zum Laufen zu bringen. Es mussten große Änderungen an der Art und Weise vorgenommen werden, wie Partitionen auf dem Pixel 3, Googles Testumgebung für DSU, verwaltet werden. Daher ist die erste wichtige Voraussetzung für die DSU-Unterstützung, dass das Gerät dies unterstützt dynamische Partitionen. Dynamische Partitionen umfassen eine echte Speicherpartition, die in skalierbare logische Partitionen wie System, Hersteller, ODM, OEM, Produkt usw. unterteilt ist. Während der Installation eines GSI wird Platz für neue System- und Benutzerdatenpartitionen reserviert, indem ungenutzte Blöcke aus der vorhandenen Benutzerdatenpartition übernommen werden. Da diese neuen Partitionen mehrere Gigabyte groß sein können, ist die DSU-Unterstützung nur bei logischen Partitionen sinnvoll Partitionen andernfalls müsste ein Gerät dauerhaft mehrere Gigabyte Speicherplatz für GSI reservieren Installationen.

Zu den weiteren Anforderungen gehören eine Ramdisk, die entscheidet, ob von der Wiederherstellungs-, System- oder einer logischen Partition gebootet werden soll, sowie eine Metadatenpartition zum Speichern der Metadaten des GSI. Im Allgemeinen sind die Bausteine ​​für die DSU-Unterstützung die Startanforderungen für Android Q, so Project Treble-Leiter Iliyan Malchev. Wir sind uns nicht sicher, ob alles Was zur Unterstützung von DSU erforderlich ist, ist eine Startvoraussetzung für Android Q, aber wir können davon ausgehen, dass die meisten, wenn nicht alle Geräte mit Android Q starten dürfen unterstützen DSU, auch wenn Google dies derzeit nicht verlangt. Bisher verfügen nur Pixel 3, Pixel 3 XL, Pixel 3a und Pixel 3a XL über dynamische Partitionen, und von diesen Geräten unterstützen nur Pixel 3 und Pixel 3 XL DSU in Android Q Beta 4. Obwohl keine DSU-Unterstützung erforderlich ist, hofft Google, dass OEMs die Funktion trotzdem aktivieren, da sie das sichere Testen der Treble-Kompatibilität vereinfacht. Beispielsweise kann ein OEM-Softwareentwickler einen GSI erstellen auf einer SD-Karte So können sie schnell auf mehreren Geräten booten, um die Treble-Kompatibilität zu testen.

Sicherheit für dynamische Systemaktualisierungen

Da DSU im Wesentlichen ein zweites Betriebssystem in den Mix einführt, muss Google sicherstellen, dass diese neue Installation nicht manipuliert werden kann, um die Integrität des Geräts zu beeinträchtigen. Und so kam es dass der Für die GSI-Installation gelten dieselben grundlegenden Sicherheitsmaßnahmen wie bei der ursprünglichen Installation: Von Android verifizierte Boot- und SELinux-Richtlinien. Darüber hinaus können nur Apps mit der privilegierten Berechtigung INSTALL_DYNAMIC_SYSTEM-Signatur einen GSI initiieren Installation, während Apps mit der Signaturberechtigung MANAGE_DYNAMIC_SYSTEM ein GSI aktivieren/deaktivieren oder löschen können Installation. Das bedeutet, dass nur vertrauenswürdige Apps auf Systemebene mit DSU funktionieren können.

Um sicherzustellen, dass die ursprünglichen Benutzerdaten geschützt sind, hat Google eine hinzugefügt zusätzlicher Schutzmechanismus in Android Q. Angerufen "Kontrollpunkt„Schützt die Funktion vor der Zerstörung von Benutzerdaten, indem sie Checkpoint-Partitionen in ihren ursprünglichen Zustand zurückversetzt. Kontrollpunkte sind jedoch nicht nur für DSU nützlich. Sie werden auch zum Schutz vor Pfuschereien eingesetzt Projekt Mainline APEX-Modul und A/B OTA-Updates. (Geräte mit A/B-Partitionen verfügen bereits über einen Rollback-Schutz, aber diese Rollbacks erfordern ein Zurücksetzen der Werksdaten, während dies bei Benutzerdaten-Kontrollpunkten nicht der Fall ist.)

Installieren eines GSI

Wenn Ihr Gerät wie die Pixel-3-Serie DSU unterstützt, ist die Installation eines GSI einfach. Sie müssen zunächst auf zwei Arten sicherstellen, dass das Feature-Flag „Dynamisches System“ aktiviert ist:

1. Wenn Sie einen Userdebug-Build verwenden, aktivieren Sie das Flag „settings_dynamic_android“ unter „Einstellungen“ > „System“ > „Entwickleroptionen“ > „Feature-Flags“.
2. Wenn Sie einen Benutzer-Build verwenden, führen Sie den folgenden ADB-Shell-Befehl aus:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

Laden Sie dann die neueste Android Q Beta-GSI von herunter Google oder der OEM Ihres Geräts. (DSU erlaubt nur die Installation von von Google oder einem OEM signierten GSIs.) Nach dem Herunterladen verwenden simg2img um das spärliche Bild in ein Rohbild umzuwandeln. Packen Sie das Rohbild mit gzip und kopieren Sie dann das resultierende Archiv an einen Speicherort auf Ihrem Gerät externer Speicher (z. B. /data/media/0/Download) oder ein tatsächliches externes Speichermedium (wie eine physische SD). Karte). Starten Sie abschließend die DynamicSystemInstallationService-App mit der richtigen Absicht, um mit der Installation zu beginnen:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

Sobald Sie auf „Neustart“ klicken, starten Sie das GSI. Die Verwendbarkeit des Geräts im GSI hängt davon ab, wie gut der OEM Ihres Geräts Treble implementiert hat (oder besser gesagt, wie wenig er Treble verletzt hat). Kompatibilität.) Einige Geräte funktionieren besser mit GSIs als andere, aber im Allgemeinen sollten Sie nicht davon ausgehen, dass Sie diese Installation täglich verwenden Treiber. Sie sollen Ihre App testen und sie dann durch einen Neustart beenden. Wenn Sie für weitere Tests in der GSI-Installation bleiben möchten, können Sie die verwenden gsi_tool Shell-Befehl.

Die vollständigen GSI-Installationsanweisungen für DSU finden Sie hier Hier. Fehler können auf der eingereicht werden Google Issue Tracker,Reddit, oder Paketüberfluss.

Der Grund für dynamische Systemaktualisierungen

Als ich bei Google I/O mit Iliyan Malchev sprach, wiederholte er, was Hung-ying Tyan vom Treble-Team über den frühen GSI-Zugriff gesagt hatte Android Dev Summit im November. Google hat DSU erstellt Bitten Sie ein möglichst breites Publikum um Feedback. Ziel ist es, die Qualität des GSI zu verbessern, was wiederum verbessert die Qualität der zukünftigen Android-Version da ein GSI die reinste Form von Android ist. Google ist derzeit das einzige Unternehmen, das die GSI-Kompatibilität der nächsten Version testet (z. B. wie gut das Android Q-System-Image auf dem Android P funktioniert). Anbieterimplementierung), aber da immer mehr Leute GSIs flashen und Feedback geben, können OEMs Verstöße gegen die Treble-Kompatibilität beheben, sodass GSIs noch besser funktionieren Zukunft. Laut Iliyan besteht großes Interesse von OEMs und Anbietern wie Qualcomm daran, Anbieter-Images aus der vorherigen Android-Version mit dem System-Image der nächsten Version wiederzuverwenden. Initiativen wie DSU helfen Google und OEMs, die Lücke in der Abdeckung automatisierter Tests wie VTS und CTS-on-GSI zu schließen. Dadurch erhält Google mehr Betatester, die Feedback zur nächsten Android-Version geben und gleichzeitig von Verstößen gegen die Treble-Kompatibilität erfahren, damit OEMs ihre Arbeit verbessern können.

Die Hinzufügung dynamischer Systemaktualisierungen in Android Q ist willkommen, aber es wird nicht die Dual-Boot-Lösung sein, auf die einige von Ihnen gehofft haben. Wie bereits erwähnt, können nur von Google oder OEMs signierte Systemabbilder installiert werden. Als ich Iliyan nach der Möglichkeit fragte, DSU zu erweitern, um ein Ökosystem alternativer Android-Geräte zu unterstützen Er sagte, dass dies technisch möglich sei, da DSU lediglich ein Kanal zur Bereitstellung von Systemen sei Bilder. Jeder OEM kann es nutzen, wie er möchte solange das Endergebnis Android-kompatibel ist. Google hat hier keine Alternative zum OTA-System geschaffen und DSU ist nicht für echtes Dual-Booten gedacht. Unabhängig davon macht die Arbeit von Google an Treble Android modularer, sodass ich mich nicht wundern würde, wenn natives Dual-Booten später Realität werden würde.