Android Manifest: Komponenten, Rechte und Metadaten erklärt

Wenn du eine Android-App baust, ist das Manifest dein erster Berührungspunkt mit dem Betriebssystem. Du erklärst dort, woraus deine App besteht, welche Rechte sie benötigt und wie sie sich gegenüber anderen Apps verhält. Ohne diese Datei weiß Android schlicht nicht, was deine App tun darf und wo es deine Komponenten finden kann.

Was ist das?

Das Android Manifest ist eine XML-Datei mit dem Namen AndroidManifest.xml, die im Wurzelverzeichnis deines App-Moduls liegt. Sie beschreibt deine App formell gegenüber dem Android-System, dem Google Play Store und anderen Apps auf dem Gerät. Konkret meldest du dort drei Dinge an: deine Komponenten (Activities, Services, Broadcast Receiver und Content Provider), deine angeforderten Berechtigungen sowie technische Anforderungen wie minSdk, Hardware-Features oder unterstützte Bildschirmgrößen.

Stell dir das Manifest als Steckbrief deiner App vor. Bevor Android eine Activity startet oder einen Service bindet, wirft das System zunächst einen Blick in diese Datei. Findet sich dort kein passender Eintrag, läuft auch nichts. Diese strikte Anmeldepflicht ist Absicht: Sie schützt Nutzerinnen und Nutzer vor Apps, die heimlich Zugriff auf Kamera, Standort oder andere sensible Bereiche nehmen.

Wie funktioniert es?

Beim Installieren liest der PackageManager dein Manifest und legt einen Datensatz für deine App im System an. Ab diesem Moment kennt Android jede Komponente, die du registriert hast, samt ihren Intent-Filtern. Diese Filter beschreiben, auf welche Aktionen, Datentypen oder Kategorien eine Komponente reagiert. So findet das System zum Beispiel deine MainActivity als Launcher-Eintrag, weil du dort MAIN und LAUNCHER als Intent-Filter hinterlegt hast.

Berechtigungen funktionieren zweistufig. Mit <uses-permission> erklärst du im Manifest, welche Rechte deine App grundsätzlich benötigt. Normale Rechte wie INTERNET werden bei der Installation automatisch gewährt. Gefährliche Rechte wie CAMERA oder ACCESS_FINE_LOCATION musst du zusätzlich zur Laufzeit über die Runtime-Permission-API anfragen. Das Manifest ist also notwendig, aber für sensible Zugriffe nicht ausreichend.

Eine zweite wichtige Mechanik ist der Manifest-Merger. Dein App-Modul, jede eingebundene Bibliothek und auch Build-Varianten dürfen eigene Manifest-Fragmente liefern. Während des Gradle-Builds führt das System alle Einträge zu einer einzigen finalen Datei zusammen. Das ist praktisch, kann aber Rechte oder Komponenten in deine App holen, die du nicht erwartet hast.

In der Praxis

Ein typisches Manifest für eine kleine App sieht so aus:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          xmlns:tools="http://schemas.android.com/tools">

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.CAMERA" />

    <application
        android:name=".MyApp"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/Theme.MyApp">

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

Achte besonders auf das Attribut android:exported. Seit Android 12 musst du es explizit setzen, sobald eine Komponente einen Intent-Filter besitzt. Vergisst du das, schlägt schon der Build fehl. Setze exported="true" nur dann, wenn andere Apps die Komponente wirklich starten dürfen, sonst öffnest du einen unnötigen Angriffsvektor.

Typische Stolperfalle

Eine klassische Falle ist der Manifest-Merger: Eine Werbe- oder Analytics-Bibliothek bringt häufig zusätzliche Berechtigungen mit, etwa ACCESS_NETWORK_STATE oder sogar READ_PHONE_STATE. Im Play Store taucht deine App dann mit Rechten auf, die du nie selbst angefordert hast. Prüfe daher nach jedem Update einer Abhängigkeit das gemergte Manifest unter app/build/intermediates/merged_manifests/ und nutze bei Bedarf tools:remove, um unerwünschte Einträge zu entfernen.

Entscheidungsregel

Frage dich vor jedem neuen Manifest-Eintrag: Brauche ich dieses Recht oder diese Komponente wirklich, oder zieht es nur eine Bibliothek mit? Jedes überflüssige Recht verschlechtert deine Chancen im Play-Store-Review und das Vertrauen deiner Nutzer. Halte das Manifest so klein wie möglich und so groß wie nötig.

Fazit

Das Manifest ist klein, aber kritisch. Wer den Aufbau versteht, spart sich später Stunden in Logcat-Sitzungen, in denen scheinbar registrierte Activities nicht starten oder Berechtigungen ohne ersichtlichen Grund fehlen. Öffne nach dem Lesen das Manifest deiner aktuellen App, gehe jede Zeile durch und beantworte für dich, warum sie dort steht. Ergänze einen tools:remove-Eintrag für ein nicht benötigtes Recht aus einer Bibliothek und prüfe das gemergte Ergebnis im Build-Ordner. Schreibe außerdem einen kleinen UI-Test, der eine Activity per Intent aufruft, um zu sehen, ob deine Filter so wirken wie geplant. So wird aus theoretischem Wissen eine verlässliche Routine in deinem Android-Alltag.