AndroidManifest.xml — was ist das, Hauptkomponenten und Manifest-Konfiguration

Was ist AndroidManifest.xml

AndroidManifest.xml ist die Stammkonfigurationsdatei im XML-Format, die jedes Android-Projekt im Verzeichnis app/src/main enthalten muss. Das Android-System analysiert sie, bevor es App-Code ausführt — während der APK-Analyse bei der Installation. Wenn das Manifest einen Syntaxfehler enthält oder eine erforderliche Deklaration fehlt, wird die Installation mit einer Fehlermeldung abgebrochen.

Die Datei enthält eine vollständige Deklaration der App: eine Liste aller Komponenten (Activity, Service, BroadcastReceiver, ContentProvider), angeforderte Berechtigungen, minimale SDK-Version, Hardwareanforderungen sowie Konfiguration von Themes und Stilen. Jede Komponente, die vom System oder anderen Apps aufgerufen werden kann, muss im Manifest explizit deklariert werden. Dies ist eine Sicherheitsanforderung: ohne explizite Deklaration ist die Komponente nicht aufrufbar.

Ohne ein korrekt konfiguriertes Manifest kann die App nicht über Google Play oder Sideloading installiert werden. Das System überprüft das Manifest während der APK-Analyse und lehnt die Installation bei Fehlern ab. Google Play scannt das Manifest auch auf unsichere Konfigurationen: bei exported=true an einer Komponente ohne intent-filter wird eine Warnung ausgegeben und bei fehlenden obligatorischen Berechtigungen für targetSdk 34+ wird die Veröffentlichung blockiert. Daher ist das Verständnis der Manifest-Struktur eine zwingende Fähigkeit für Android-Entwickler.

App-Komponenten im Manifest

Jede Android-App-Komponente muss explizit im Manifest registriert werden. Dies ist eine zwingende Plattformanforderung für alle vier Komponententypen. Ohne Registrierung kann die Komponente vom System nicht erstellt werden, und der Versuch, sie zu starten, führt zu einer ActivityNotFoundException oder einer ähnlichen Ausnahme. Komponenten werden innerhalb des application-Tags in einer Reihenfolge registriert, die ihre Funktion nicht beeinträchtigt.

Activity

Der activity-Tag registriert einen App-Bildschirm. Das Attribut exported legt fest, ob andere Apps diese Activity starten können. Ab Android 12 verursacht das Fehlen von exported bei vorhandenem intent-filter einen Build-Fehler — dies ist eine Sicherheitsanforderung. Der Einstiegspunkt wird über intent-filter mit action MAIN und category LAUNCHER festgelegt. Jede Activity muss einen eindeutigen android:name haben, der dem vollständigen oder relativen Klassennamen entspricht.

<activity
    android:name=".MainActivity"
    android:exported="true"
    android:windowSoftInputMode="adjustResize">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

Service

Der service-Tag definiert einen Hintergrunddienst. Ab Android 8 gelten strenge Einschränkungen für Hintergrunddienste: ein Vordergrunddienst erfordert eine obligatorische für den Benutzer sichtbare Benachrichtigung mit einem Symbol, und ein gebundener Dienst lebt nur, solange ein Client an ihn gebunden ist. Dienste, die im Hintergrund ohne Benachrichtigung ausgeführt werden, werden vom System innerhalb weniger Minuten nach dem Wechsel der App in den Hintergrund automatisch beendet. Für langlaufende Aufgaben verwenden Sie WorkManager anstelle von Service.

<service
    android:name=".SyncService"
    android:exported="false"
    android:foregroundServiceType="dataSync" />

BroadcastReceiver

Der receiver-Tag deklariert einen Empfänger für System- oder benutzerdefinierte Broadcast-Nachrichten. Ab Android 8 werden die meisten impliziten Broadcasts nicht mehr an statisch im Manifest deklarierte Empfänger zugestellt. Stattdessen wird empfohlen, Empfänger dynamisch über Context.registerReceiver im Code zu registrieren. Ausnahmen sind einige System-Broadcasts wie BOOT_COMPLETED, die weiterhin eine statische Registrierung im Manifest erfordern.

<receiver
    android:name=".ConnectivityReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
    </intent-filter>
</receiver>

Berechtigungen in Android

Jede gefährliche Berechtigung in Android erfordert eine Deklaration im Manifest über den Tag uses-permission. Ab Android 6 werden gefährliche Berechtigungen zur Laufzeit über einen Dialog mit dem Benutzer angefordert, aber die Deklaration im Manifest bleibt obligatorisch. Ohne sie wirft die Methode requestPermissions eine SecurityException. Berechtigungen der normalen Stufe wie INTERNET und ACCESS_NETWORK_STATE werden bei der Installation automatisch erteilt.

Der uses-permission-sdk-23-Tag gibt Berechtigungen an, die nur unter Android 6.0+ benötigt werden. Dies ermöglicht die Kompatibilität mit älteren Versionen, ohne nicht existierende Berechtigungen anzufordern. Beispielsweise ist POST_NOTIFICATIONS nur unter Android 13+ verfügbar, daher muss es über uses-permission-sdk-33 angegeben werden, um einen unbekannten Berechtigungsfehler auf älteren Geräten zu vermeiden. Das Attribut maxSdkVersion in uses-permission ermöglicht das automatische Widerrufen unnötiger Berechtigungen beim Aktualisieren der App auf neueren Android-Versionen.

Normale Berechtigungen (INTERNET, ACCESS_NETWORK_STATE) werden bei der Installation automatisch erteilt und erfordern keine Laufzeitanforderung. Sie werden ebenfalls über uses-permission deklariert, aber dem Benutzer nicht in einem Dialog angezeigt. Zur Steuerung des Zugriffs auf App-Komponenten aus anderen Anwendungen wird der Mechanismus der berechtigungsgeschützten Komponenten verwendet: Sie können eine benutzerdefinierte Berechtigung auf Activity- oder Service-Ebene angeben, die vom System überprüft wird, wenn die Komponente von außen aufgerufen wird. Dies bietet eine zusätzliche Sicherheitsebene für die prozessübergreifende Kommunikation.

Intent Filters und Deep Links

Der intent-filter-Tag im Manifest deklariert, welche impliziten Intents eine Komponente verarbeiten kann. Dies ist der Mechanismus, über den Android System- oder benutzerdefinierte Aktionen mit der App verbindet. Ein Intent-Filter besteht aus drei Elementen: Aktion (action), Kategorie (category) und Daten (data). Alle drei können kombiniert werden, um genau zu beschreiben, welche Intents die Komponente erhalten soll. Das System wählt die geeignete Komponente basierend auf dem spezifischsten Filter aus.

<activity android:name=".DeepLinkActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="itsectr.com"
            android:pathPrefix="/app" />
    </intent-filter>
</activity>

Das Attribut autoVerify aktiviert die Überprüfung von Android App Links: Das System kontaktiert den Server, um die Domain-Inhaberschaft zu bestätigen. Ohne Verifizierung funktionieren Deep Links über den Standard-Auswahldialog, in dem der Benutzer auswählt, mit welcher App der Link geöffnet werden soll. Nach erfolgreicher Verifizierung öffnen Links direkt in der App ohne Dialog. Die Google Search Console verwendet autoVerify ebenfalls, um Deep Links zu indizieren und in den Suchergebnissen anzuzeigen.

Filter mit action.VIEW und den Kategorien DEFAULT und BROWSABLE verarbeiten Links aus Browsern, E-Mails und anderen Apps. Dies ist der Hauptmechanismus zur Implementierung von Deep Links in Android. Um benutzerdefinierte URL-Schemata wie myapp:// zu unterstützen, geben Sie einfach das Schema ohne Host an. Google empfiehlt jedoch die Verwendung von HTTPS-Deep-Links anstelle von benutzerdefinierten Schemata, da diese sicherer sind und keine zusätzlichen Berechtigungen erfordern. Benutzerdefinierte Schemata können von jeder App abgefangen werden, die dasselbe Schema registriert.

App-Attribute und Metadaten

Der Stamm-Tag manifest enthält Paket-, Versions- und SDK-Attribute. Der application-Tag speichert globale Einstellungen: Theme, Symbol, Label und Debug-Flags. Manifest-Attribute definieren die Versionierung auf Paketebene, während application-Attribute das allgemeine Erscheinungsbild und Verhalten der App bestimmen. Werte können Ressourcenverweise über die @-Syntax oder Zeichenfolgenliterale sein.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.itsectr.myapp"

    <uses-sdk
        android:minSdkVersion="24"
        android:targetSdkVersion="34" />

    <application
        android:label="MyApp"
        android:icon="@mipmap/ic_launcher"
        android:theme="@style/Theme.MyApp"
        android:supportsRtl="true"
        android:allowBackup="true">
        <!--  App-Komponenten  -->
    </application>
</manifest>

Der meta-data-Tag innerhalb von application ermöglicht das Speichern beliebiger Schlüssel-Wert-Paare. Dies ist praktisch für die Konfiguration von Drittanbieter-Bibliotheken: API-Schlüssel, Endpunkt-URLs und Funktionsflags. Daten aus meta-data sind zur Laufzeit über PackageManager.getApplicationInfo().metaData zugänglich. Beispielsweise verwenden Firebase und Google Maps meta-data, um Zugriffsschlüssel zu übergeben, ohne sie im Quellcode fest zu codieren. Stattdessen werden die Schlüssel im Manifest festgelegt und können für verschiedene Build-Varianten unterschiedlich sein.

Das Attribut android:extractNativeLibs steuert die Extraktion nativer Bibliotheken aus der APK. Für Apps mit targetSdk 34+ muss dieses Attribut explizit angegeben werden, andernfalls kann der Build mit dem Fehler INSTALL_FAILED_INVALID_APK fehlschlagen. Wenn extractNativeLibs=false ist, bleiben native Bibliotheken ohne Entpacken innerhalb der APK, was die installierte App-Größe reduziert, aber die Ladezeit der Bibliotheken erhöht. Für die meisten modernen Apps wird extractNativeLibs=false empfohlen, um den Speicherplatz auf dem Gerät des Benutzers zu reduzieren.

Das Attribut android:networkSecurityConfig ermöglicht die Angabe einer Netzwerksicherheits-Konfigurationsdatei. Dies ist besonders wichtig für Apps mit targetSdk 28+, bei denen HTTP-Verkehr standardmäßig blockiert wird. Die Konfigurationsdatei definiert vertrauenswürdige Zertifikate, Domains für HTTP-Verbindungen und Zertifikats-Pinning-Regeln. Dies ersetzt das veraltete Attribut android:usesCleartextTraffic und bietet einen flexibleren Mechanismus zur Verwaltung der Verbindungssicherheit auf Betriebssystemebene.

Das Attribut android:largeHeap fordert eine vergrößerte Heap-Größe für die App an. Standardmäßig weist Android jeder App eine begrenzte Menge Arbeitsspeicher zu, die vom Gerät und der OS-Version abhängt. Wenn die App mit schweren Bildern, Videos oder großen Datensätzen arbeitet, kann largeHeap OutOfMemoryError verhindern. Der Missbrauch dieses Attributs ist jedoch schädlich: Eine App mit hohem Speicherverbrauch wird vom System bei Ressourcenknappheit schneller beendet. Verwenden Sie largeHeap nur nach Profilerstellung und Bestätigung des Bedarfs.