Wie die Installation einer Android-App unter der Haube funktioniert

Wenn Sie bei einer APK-Datei auf „Installieren“ tippen oder eine App aus dem Play Store herunterladen, beginnt hinter den Kulissen eine komplexe Abfolge von Vorgängen. Was wie ein einfacher Fortschrittsbalken aussieht, stellt in Wirklichkeit Dutzende von Schritten dar, die Paketanalyse, kryptografische Überprüfung, Berechtigungsverwaltung, Dateiextraktion und Codeoptimierung umfassen. Das Verständnis dieses Prozesses hilft zu erklären, warum Installationen manchmal fehlschlagen und was Sie dagegen tun können.

In diesem Artikel gehen wir alle wichtigen Schritte der Android-Installationspipeline durch, vom Moment, in dem das System ein APK erhält, bis zu dem Punkt, an dem die App startbereit ist.

Schritt 1: Starten der Installation

Der Installationsvorgang beginnt je nach Quelle unterschiedlich:

• Play Store: Die Play Store-App lädt das APK (oder geteilte APKs) herunter und ruft das Paketinstallationsprogramm des Systems mit besonderen Berechtigungen auf, die einige Benutzerbestätigungen umgehen.
• Seitenladen: Wenn Sie eine APK-Datei öffnen, startet Android die Paketinstallationsaktivität. Unter Android 8.0 und höher muss die installierende App über die Berechtigung „Unbekannte Apps installieren“ für ihre spezifische Quelle verfügen.
• ADB: Der Befehl adb install kommuniziert direkt über USB mit dem Paketmanagerdienst und umgeht dabei das grafische Installationsprogramm vollständig.

Unabhängig von der Quelle erreichen alle Installationen letztendlich denselben Systemdienst: den PackageManagerService (PMS). Dies ist die zentrale Autorität für alle Paketvorgänge auf Android.

Schritt 2: Paketanalyse

Vor allem muss das System verstehen, was es installieren wird. Der PackageManagerService ruft PackageParser auf, um die APK-Datei zu lesen und ihre Metadaten zu extrahieren.

Der Parser liest die AndroidManifest.xml-Datei aus dem APK. Diese binäre XML-Datei enthält wichtige Informationen:

• Paketname: Die eindeutige Kennung für die App (z). B. com.example.myapp
• Versionscode und Name: Wird verwendet, um festzustellen, ob es sich um ein Upgrade oder eine Neuinstallation handelt
• Mindest- und Ziel-SDK-Versionen: Bestimmt die Kompatibilität mit dem Gerät
• Deklarierte Berechtigungen: Sowohl Berechtigungen, die die App anfordert, als auch benutzerdefinierte Berechtigungen, die sie definiert
• Komponenten: Aktivitäten, Dienste, Rundfunkempfänger und Inhaltsanbieter, die die App registriert
• Hardware- und Softwarefunktionen: Anforderungen wie Kamera, GPS oder bestimmte OpenGL-Versionen

Wenn das Manifest fehlerhaft ist oder die APK-Struktur ungültig ist, schlägt die Installation in dieser Phase mit der Meldung „Parse-Fehler“ fehl. Dies ist einer der häufigsten Gründe, warum seitlich geladene APKs nicht installiert werden können.

Schritt 3: Kompatibilitätsprüfungen

Sobald das Manifest analysiert wurde, führt das System eine Reihe von Kompatibilitätsprüfungen durch:

• SDK-Version: Wenn der minSdkVersion der App höher ist als der API-Level des Geräts, wird die Installation abgelehnt.
• ABI-Kompatibilität: Wenn das APK native Bibliotheken enthält, prüft das System, ob diese zur CPU-Architektur des Geräts passen. Ein APK nur mit armeabi-v7a-Bibliotheken lässt sich nicht auf einem reinen x86-Gerät installieren.
• Erforderliche Funktionen: Wenn die App erforderliche Hardwarefunktionen deklariert (wie android.hardware.telephony), überprüft das System, ob das Gerät diese unterstützt.
• Verfügbarer Speicherplatz: Das System prüft, ob genügend freier Speicherplatz für die Installation der App vorhanden ist, einschließlich Speicherplatz für die extrahierten nativen Bibliotheken und optimierten DEX-Dateien.

Schritt 4: Signaturüberprüfung

Dies ist einer der kritischsten Schritte im Installationsprozess. Android überprüft die kryptografische Signatur des APK, um dessen Integrität und Authentizität sicherzustellen.

Der Verifizierungsprozess hängt davon ab, welche Signaturschemata vorhanden sind:

V1-Signatur (JAR-Signierung)

Das System prüft das Verzeichnis META-INF/ auf Signaturdateien (.SF, .RSA oder .DSA). Jede Datei im APK wird anhand der im Manifest aufgeführten Digests überprüft. Dies ist langsam, da jede Datei einzeln gehasht werden muss.

V2-Signatur (APK Signature Scheme v2)

Dieses in Android 7.0 eingeführte Schema signiert die gesamte APK als binären Blob. Der Signaturblock wird zwischen dem zentralen ZIP-Verzeichnis und dem Datensatz am Ende des zentralen Verzeichnisses eingefügt. Die Überprüfung ist viel schneller, da sie mit den Rohbytes arbeitet, ohne dass einzelne Einträge dekomprimiert werden müssen.

V3-Signatur (Schlüsselrotation)

V3 ist ab Android 9.0 verfügbar und erweitert V2 um Unterstützung für die Tastenrotation. Es umfasst eine Proof-of-Rotation-Struktur, die alte und neue Signaturschlüssel verknüpft und es Entwicklern ermöglicht, ihre Signaturschlüssel zu ändern und gleichzeitig die Update-Kompatibilität aufrechtzuerhalten.

V4-Signatur (inkrementell)

Mit Android 11 wurde V4 für inkrementelle Installationen eingeführt. Es bietet eine Merkle-Baum-basierte Signatur, die die Überprüfung einzelner Blöcke ermöglicht, während diese an das Gerät gestreamt werden.

Sollte die Signaturprüfung aus irgendeinem Grund fehlschlagen, wird die Installation sofort abgebrochen. Sie können die Signatur einer APK vor der Installation mit unserem APK-Verifizierungstool überprüfen.

Signaturabgleich aktualisieren

Wenn bereits eine App mit demselben Paketnamen installiert ist, führt das System eine zusätzliche Prüfung durch: Das Signaturzertifikat des neuen APK muss mit dem Zertifikat der vorhandenen Installation übereinstimmen. Dadurch wird verhindert, dass eine böswillige Partei eine legitime App durch eine manipulierte Version ersetzt. Wenn die Signaturen nicht übereinstimmen, wird die Fehlermeldung „App nicht installiert: Das Paket steht in Konflikt mit einem vorhandenen Paket mit demselben Namen“ angezeigt.

Schritt 5: Benutzerbestätigung

Bei seitlich geladenen Installationen zeigt das System einen Installationsbestätigungsdialog mit folgenden Informationen an:

• Der App-Name und das Symbol (aus den APK-Ressourcen extrahiert)
• Berechtigungen, die die App anfordert (auf älteren Android-Versionen)
• Egal ob es sich um eine Neuinstallation oder ein Update handelt
• Alle Warnungen zur Quelle der App oder zu potenziellen Risiken

Auf Android 12 und höher ist der Bestätigungsbildschirm einfacher, da Laufzeitberechtigungen einzeln erteilt werden, wenn die App sie zum ersten Mal benötigt, und nicht erst bei der Installation.

Schritt 6: Dateiextraktion und -platzierung

Sobald der Benutzer bestätigt (oder bei Play Store-Installationen automatisch), beginnt das System mit dem Extrahieren und Platzieren von Dateien:

APK-Speicher

Die APK-Datei selbst wird nach /data/app/[package-name]-[random]/base.apk kopiert. Bei geteilten APK-Installationen werden zusätzliche Dateien wie split_config.arm64_v8a.apk neben dem Basis-APK platziert. Das Original-APK im Ordner „Downloads“ wird nicht geändert oder gelöscht.

Extraktion nativer Bibliotheken

Wenn das APK native Bibliotheken enthält (im Verzeichnis lib/, werden diese nach /data/app/[package-name]-[random]/lib/[abi]/ extrahiert). Bei neueren Android-Versionen können Apps dafür sorgen, dass die nativen Bibliotheken im APK komprimiert bleiben und sie direkt mit android:extractNativeLibs="false" geladen werden, was Speicherplatz spart.

Erstellung eines Datenverzeichnisses

Das System erstellt das private Datenverzeichnis der App unter /data/data/[package-name]/ (oder /data/user/0/[package-name]/ auf Mehrbenutzergeräten). Dieses Verzeichnis gehört einer eindeutigen Linux-UID, die der App zugewiesen ist. Dadurch wird sichergestellt, dass keine andere App ohne Root-Rechte darauf zugreifen kann.

Schritt 7: DEX-Optimierung

In diesem Schritt wandelt Android den Bytecode der App in ein Format um, das für die spezifische Hardware des Geräts optimiert ist. Der Prozess hat sich im Laufe der Android-Geschichte erheblich weiterentwickelt:

Die Dalvik-Ära (Android 4.4 und früher)

Die ursprüngliche virtuelle Maschine von Dalvik nutzte die Just-In-Time-Kompilierung (JIT). Während der Installation wurde die classes.dex-Datei in eine ODEX-Datei optimiert, die verifizierten und optimierten Bytecode enthielt. Dies war relativ schnell, bedeutete jedoch, dass die App zur Laufzeit langsamer lief, da der größte Teil des Codes noch interpretiert wurde.

ART mit AOT (Android 5.0 bis 6.0)

Android Runtime (ART) ersetzte Dalvik und führte die AOT-Kompilierung (Ahead-Of-Time) ein. Während der Installation wurde der gesamte DEX-Bytecode in nativen Maschinencode kompiliert. Dadurch wurden Apps schneller ausgeführt, die Installationszeit und der Speicherverbrauch stiegen jedoch erheblich. Die Installation einiger Apps dauerte mehrere Minuten.

Profilgesteuerte Kompilierung (Android 7.0+)

Modernes Android verwendet einen Hybridansatz. Während der Installation werden nur kritische Startpfade kompiliert. Während der Benutzer die App ausführt, sammelt das System Ausführungsprofile, die häufig verwendete Codepfade identifizieren. Während der Leerlaufwartung (normalerweise während des Ladevorgangs über Nacht) kompiliert das System diese Hot Paths zu nativem Code. Dadurch werden Installationsgeschwindigkeit, Speichernutzung und Laufzeitleistung ausgeglichen.

Der kompilierte Code wird in /data/dalvik-cache/ oder neben dem APK als .odex-, .vdex- und .art-Dateien gespeichert. Die .vdex-Datei enthält verifizierten DEX-Code, die .odex-Datei enthält kompilierten nativen Code und die .art-Datei enthält vorinitialisierte Heap-Images für einen schnelleren Start.

Schritt 8: Berechtigungsregistrierung

Der PackageManagerService registriert die deklarierten Berechtigungen und Komponenten der App beim System:

• Berechtigungen zur Installationszeit (wie INTERNET oder VIBRATE werden automatisch ohne Benutzerinteraktion gewährt).
• Laufzeitberechtigungen (wie CAMERA oder LOCATION werden registriert, aber nicht gewährt). Die App muss sie zur Laufzeit anfordern.
• Absichtsfilter werden registriert, sodass das System weiß, welche Apps welche Aktionen ausführen können (z. B. das Öffnen einer URL oder das Teilen von Inhalten).
• Inhaltsanbieter sind bei ihren Behörden registriert, sodass andere Apps sie abfragen können.

Schritt 9: Systemintegration

Die letzten Schritte integrieren die App in das Android-System:

• Aktualisierung der Paketdatenbank: Die Paketdatenbank des Systems (/data/system/packages.xml wird mit den Informationen der neuen App aktualisiert, einschließlich der zugewiesenen UID, Berechtigungen und Komponentendeklarationen).
• Launcher-Benachrichtigung: Der Startbildschirm-Launcher wird über die neue App benachrichtigt, sodass er das App-Symbol anzeigen kann.
• Übertragen: Das System sendet einen PACKAGE_ADDED-Broadcast, der es anderen Apps ermöglicht, auf die neue Installation zu reagieren (z. B. könnten Backup-Apps ein Backup planen).
• SELinux-Kontext: Die Dateien der App werden basierend auf der Ziel-SDK-Version und den deklarierten Berechtigungen mit dem entsprechenden SELinux-Sicherheitskontext gekennzeichnet.

Warum Installationen fehlschlagen

Das Verständnis der Installationspipeline hilft bei der Diagnose häufiger Fehler:

• „Parse-Fehler“: Das APK ist beschädigt, unvollständig oder weist ein fehlerhaftes Manifest auf. Dies geschieht häufig bei unvollständigen Downloads oder nicht ordnungsgemäß konvertierten Dateien.
• „App nicht installiert“ (Signatur stimmt nicht überein): Sie versuchen, eine App mit einem APK zu aktualisieren, das mit einem anderen Schlüssel signiert ist. Sie müssen zuerst die vorhandene Version deinstallieren.
• „Nicht genügend Speicherplatz“: Nicht genügend Speicherplatz für das APK, die extrahierten Bibliotheken und die DEX-Optimierungsausgabe. Der tatsächlich benötigte Speicherplatz beträgt normalerweise das Zwei- bis Dreifache der APK-Größe.
• „Paketkonflikt mit vorhandenem Paket“: Gleicher Paketname, aber unterschiedliche Signatur. Häufig beim Wechsel zwischen Play Store und seitlich geladenen Versionen.
• Versions-Downgrade blockiert: Standardmäßig verhindert Android die Installation einer älteren Version über einer neueren. ADB kann dies mit adb install -d überschreiben.

Geteilte APK-Installation

Bei der Installation geteilter APKs (von App Bundles) ist der Vorgang etwas anders. Das System verwendet eine Sitzungsbasierte Installation-API:

1. Eine neue Installationssitzung wird erstellt
2. Jede geteilte APK wird in die Sitzung geschrieben
3. Die Sitzung wird festgeschrieben, wodurch die vollständige Verifizierungspipeline ausgelöst wird
4. Alle Splits müssen übereinstimmende Paketnamen, Versionscodes und Signaturzertifikate haben

Dies ist der Mechanismus, den XAPK-Installationsprogramme und Tools wie unser Fusion von APKS zu APK verwenden, um Installationen mit mehreren Dateien durchzuführen.

Installation über ADB

Wenn Sie adb install verwenden, umgeht der Prozess das grafische Installationsprogramm, folgt jedoch derselben internen Pipeline. ADB kommuniziert mit dem Paketmanagerdienst über eine Socket-Verbindung. Es unterstützt zusätzliche Flags, die nicht über die GUI verfügbar sind:

• -r: Vorhandene App ersetzen (Neuinstallation zulassen)
• -d: Versions-Downgrade zulassen
• -g: Erteilen Sie sofort alle Laufzeitberechtigungen
• -t: Installation von Nur-Test-APKs zulassen
• --install-multiple: Geteilte APKs in einer einzigen Sitzung installieren

Was passiert während der Deinstallation?

Der Vollständigkeit halber sehen Sie hier, was passiert, wenn eine App entfernt wird:

1. Die Prozesse der App werden abgebrochen
2. Das APK und die extrahierten Bibliotheken werden aus /data/app/ gelöscht
3. Das private Datenverzeichnis der App wird entfernt (es sei denn, der Benutzer hat sich dafür entschieden, die Daten zu behalten).
4. Kompilierte DEX-Cache-Dateien werden gelöscht
5. Die Paketdatenbank wird aktualisiert
6. Es wird ein PACKAGE_REMOVED-Broadcast gesendet
7. Der Launcher entfernt das App-Symbol

Beachten Sie, dass app-spezifische Dateien im externen Speicher (/Android/data/[package]/ und /Android/obb/[package]/ dank der bereichsbezogenen Speicherdurchsetzung auch auf Android 10 und höher gelöscht werden).

Warum das Verständnis von PackageManager Zeit beim Debuggen spart

Der Android-Installationsprozess ist eine sorgfältig orchestrierte Abfolge von Sicherheitsüberprüfungen, Dateivorgängen und Systemintegrationen. Jeder Schritt dient einem Zweck, vom Schutz der Benutzer vor manipulierten Apps bis hin zur Optimierung der Leistung für die jeweilige Hardware. Wenn Installationen fehlschlagen, weist der Fehler normalerweise auf einen bestimmten Schritt in dieser Pipeline hin. Wenn Sie den Prozess verstehen, können Sie Probleme schnell diagnostizieren und beheben.

Die Installation aus dem Play Store, das manuelle Laden einer APK von der Seite und das Pushen eines Builds mit ADB laufen alle über dieselbe zugrunde liegende Pipeline, die sicherstellt, dass jede App auf Ihrem Gerät überprüft, korrekt platziert und für Ihre Hardware optimiert wurde.