APEX in Android Q: Das Größte seit Project Treble?

Die Implementierung von APEX ist wahrscheinlich das größte Problem, mit dem Google seit der Einführung von Project Treble konfrontiert war. Was ist APEX und wie wird seine Einführung Android verändern?

Die Idee hinter APEX selbst ist in alltäglichen GNU/Linux-Distributionen ziemlich verbreitet: Paketaktualisierungen, die auf bestimmte Abschnitte des Linux-Bibliothekssatzes abzielen. Aber das ist etwas, was Google nie versucht hat, da Android eine RO-Partition (schreibgeschützt) verwendet hat, in der alle Systembibliotheken und Frameworks werden im Gegensatz zu den üblichen RW-Partitionen (Lese-Schreib-Partitionen) gespeichert, die in den meisten Linux-Distributionen verwendet werden, was den Standard-Upgrade-Prozess darstellt ungeeignet.

Bibliotheken sind vorkompilierter Code, der in anderen Programmen verwendet werden kann. Häufig verwendete Methoden können in Bibliotheken umgewandelt werden, die von Android-Apps aufgerufen werden können, wodurch die Größe von APKs reduziert wird, da derselbe Code nicht in mehreren Apps erneut implementiert werden muss. Viele vorinstallierte Systembibliotheken finden Sie in den Verzeichnissen /system/lib und /system/lib64. Android-Systembibliotheken werden normalerweise nicht einzeln aktualisiert, sondern im Rahmen von Android-Plattform-Upgrades über ein OTA-Update. Andererseits können Bibliotheken in Linux-Distributionen einzeln aktualisiert werden. Mit der Einführung von APEX können Systembibliotheken in Android wie Android-Apps individuell aktualisiert werden. Der Hauptvorteil davon besteht darin, dass App-Entwickler aktualisierte Bibliotheken nutzen können, ohne darauf warten zu müssen, dass ein OEM ein vollständiges System-Upgrade einführt. Lassen Sie uns näher auf die technische Funktionsweise von APEX eingehen.

Wie wird APEX die Art und Weise verändern, wie Bibliotheken aktualisiert werden?

APEX ist ein Ökosystem, das Google gezwungen hat (oder vielmehr zwingt), die Art und Weise zu überdenken, wie Android alle Bibliotheken und Dateien von einer nicht standardmäßigen Partition, die sich von /system unterscheidet, lädt.

Zunächst müssen wir den Unterschied zwischen einer gemeinsam genutzten Bibliothek und einer statischen Bibliothek spezifizieren. Eine gemeinsam genutzte Bibliothek ist eine Bibliothek (normalerweise eine Datei mit dem Namen libkind.so), die nicht den gesamten für die Ausführung erforderlichen Code enthält, sondern tatsächlich mit anderen Bibliotheken „verlinkt“ ist Bereitstellung des Codes, während eine statische Bibliothek, wie Sie sich vorstellen können, eine Bibliothek ist, die nicht von anderen Bibliotheken abhängig ist und in der alles statisch enthalten ist Datei.

Android hat in der Vergangenheit den Bibliothekspfad (in der Linux-Welt als LD_LIBRARY_PATH bekannt) mit einer einzigen Datei konfiguriert namens ld.config.txt [0], um die zulässigen Suchpfade für die gemeinsam genutzten Bibliotheken zu konfigurieren, die entweder von der Binärdatei oder einer anderen benötigt werden Bibliothek. Diese Pfade sind in der Konfiguration fest codiert und nicht erweiterbar. Dieses Layout, einschließlich der schreibgeschützten Systempartition, führt zu nicht aktualisierbaren Bibliotheken, es sei denn, der Benutzer installiert ein OTA-Android-Update. Google hat dieses Problem behoben und ermöglichte die Erweiterung des Suchpfads, indem die einzelnen APEX-Pakete ihre eigene ld.config.txt bereitstellen konnten, die die darin enthaltenen zusätzlichen (und aktualisierten) Bibliothekspfade enthielt.

Obwohl mit diesem Schritt eines der Hauptprobleme behoben wurde, gab es noch einige schwerwiegende Probleme, die gelöst werden mussten. Zunächst einmal: ABI-Stabilität (Application Binary Interface). Bibliotheken sollten immer einen stabilen Satz an Schnittstellen exportieren, damit andere Apps und Bibliotheken auch mit der aktualisierten Bibliothek weiterhin mit demselben Protokoll arbeiten können. Google arbeitet aktiv daran, indem es versucht, eine stabile C-Schnittstelle zwischen APEXed-Bibliotheken zu schaffen.

Aber ein APEX ist nicht nur auf Bibliotheken und Binärdateien beschränkt. Tatsächlich kann es Konfigurationsdateien, Zeitzonenaktualisierungen und einige Java-Frameworks (zum Zeitpunkt des Schreibens verschlüsselt) enthalten.

Hier sind einige Beispiele der aktuellen APEX-Pakete, die von AOSP bereitgestellt werden:

• com.android.runtime: ART und Bionic Runtime (Binärdateien und Bibliotheken)
• com.android.tzdata: Zeitzonen- und ICU-Daten (Bibliotheken und Konfigurationsdaten)
• com.android.resolv: Bibliothek, die von Android zum Auflösen netzwerkbezogener Anfragen verwendet wird (Bibliotheken)
• com.android.conscrypt: Ein Java-Sicherheitsanbieter (Java-Framework)

Wie ist ein APEX-Paket installiert und aufgebaut?

Ein APEX-Paket ist ein einfaches Zip-Archiv (wie eine APK), das von unserem praktischen ADB installiert werden kann (zu diesem Zeitpunkt in der Entwicklung). und später durch den Benutzer selbst über einen Paketmanager (wie Google Play oder manuell über das Android-Paket). Installateur).

Das ZIP-Layout ist wie folgt:

Lassen Sie uns darauf eingehen.

Die apex_manifest.json gibt den Paketnamen und die Version an.

Die apex_payload.img ist ein Mikrodateisystem-Image (formatiert als EXT4).

Die anderen Dateien sind Teil des Überprüfungsprozesses, der zur Installation des Pakets verwendet wird. Werfen wir einen Blick.

Das Vorhandensein von AndroidManifest.xmlAuch wenn es hauptsächlich in Anwendungen verwendet wird, hilft es uns zu verstehen, dass der größte Teil der für eine Standard-APK-Installation verwendeten Implementierung auch für diese Pakete wiederverwendet wird. Tatsächlich wird nur die Erweiterung überprüft, um sie zu unterscheiden.

Der META-INF/ Das Verzeichnis verfügt über das Paketzertifikat und verwendet denselben Mechanismus wie normale APKs. Also diese Pakete werden zur Laufzeit durch ein privates/öffentliches Schlüsselpaar überprüft, bevor der Benutzer ein Update installieren darf. Aber das war Google nicht genug, also haben sie zwei weitere Sicherheitsebenen hinzugefügt. Sie verwenden dm-verity, um die Integrität des Bildes zu überprüfen, und AVB-Verifizierungen (Android Verified Boot), um sicherzustellen, dass das Bild von einer vertrauenswürdigen Quelle stammt. Im schlimmsten Fall wird das APEX-Paket abgelehnt.

Wenn alle Überprüfungsschritte erfolgreich sind, wird das Image als gültig markiert und ersetzt die Systemvariante beim nächsten Neustart.

Wie wird ein Image beim Booten installiert?

Werfen wir zunächst einen Blick auf die APEXes, die derzeit auf meinem Gerät (einem Emulator) installiert sind.

Wie Sie sehen, sind die vorinstallierten Pakete in /system/apex/ gespeichert und alle haben derzeit die Versionsnummer 1. Aber was passiert, wenn ein APEX aktiviert wird? Wir werden wieder com.android.tzdata als Beispiel verwenden.

Starten wir das Gerät neu und analysieren den Logcat.

Die ersten beiden Zeilen liefern genügend Informationen, um den Ursprung des Pakets und seinen Verbleib zu verstehen Installiert: /apex/, ein neues Verzeichnis, das in Android Q eingeführt wurde und zum Speichern der aktivierten Dateien verwendet wird Pakete.

Nachdem das Paket erfolgreich mit AVB verifiziert wurde und der öffentliche Schlüssel übereinstimmt, wird der APEX mithilfe eines Loop-Geräts an /dev/block/loop0 gemountet, wodurch das EXT4-Dateisystem für das System zugänglich gemacht wird. Ein Loop-Gerät ist ein Pseudogerät, das eine Datei als Blockgerät zugänglich macht und den Inhalt dieser Datei als Einhängepunkt zugänglich macht.

Zu diesem Zeitpunkt wird APEX aufgrund des Suffixes @1 (das die Paketversion angibt) noch nicht verwendet. Um dem System schließlich mitzuteilen, dass unser Paket erfolgreich aktiviert wurde, wird es an /apex/com.android.tzdata gebunden, wo Android aktiv erwartet, dass tzdata lebt. Ein Bind-Mount überlagert ein vorhandenes Verzeichnis oder eine Datei unter einem anderen Punkt. [1]

Die APEX-Implementierung ist vollständig in einem einzigen Repository unter AOSP enthalten. [2] Im Verzeichnis apexd (APEX-Daemon) wird der Code unter Android ausgeführt. Das Apexer-Verzeichnis enthält den Code, den das Build-System zum Erstellen der APEX-Pakete verwendet.

Was ist der Zweck?

An diesem Punkt kann ich nur spekulieren. Meine beste Vermutung ist, dass Google versucht, einen Kernsatz von APEX-Paketen zu erstellen, die von Google aktualisiert werden können, um möglicherweise etwas zu erstellen Ein einheitlicher Basiskern von Android, der von den Anbietern gemeinsam genutzt wird und nur „System“-Updates ermöglicht, jedoch mit einem einzigen Paket Aktualisierung.

Werden alle Geräte APEX unterstützen?

Nein. Apexd erfordert beispielsweise, dass /data/apex direkt nach dem Booten verfügbar ist, um alle Android-Module zu aktualisieren. Mit FDE (Full-Disk Encryption) wird /data/apex verschlüsselt, bis das Gerät vom Benutzer entsperrt wird, wodurch APEX grundsätzlich unbrauchbar wird, da beim Booten nur die System-APEX-Varianten geladen werden. Ansonsten sollten alle Geräte APEX unterstützen, sie benötigen jedoch einige Kernel-Patches (viele davon sind Korrekturen, die Google beim Spielen mit Loop-Geräten gefunden hat). [3] [4]

---

Quellen [0], [1], [2], [3], [4]