App-Manifest – Übersicht

Jedes App-Projekt muss eine AndroidManifest.xml-Datei mit genau diesem Namen im Stammverzeichnis des Projekt-Source-Sets enthalten. Die Manifestdatei enthält wichtige Informationen zu deiner App für die Android-Build-Tools, das Android-Betriebssystem und Google Play.

In der Manifestdatei muss unter anderem Folgendes deklariert werden:

• Die Komponenten der App, einschließlich aller Aktivitäten, Dienste, Übertragungsempfänger und Contentanbieter. Für jede Komponente müssen grundlegende Attribute definiert werden, z. B. der Name der Kotlin- oder Java-Klasse. Außerdem können Funktionen deklariert werden, z. B. welche Gerätekonfigurationen verarbeitet werden können, und Intent-Filter, die beschreiben, wie die Komponente gestartet werden kann. Weitere Informationen zu App-Komponenten finden Sie in einem der folgenden Abschnitte.
• Die Berechtigungen, die die App benötigt, um auf geschützte Teile des Systems oder andere Apps zuzugreifen. Außerdem werden alle Berechtigungen deklariert, die andere Apps haben müssen, wenn sie auf Inhalte dieser App zugreifen möchten. Weitere Informationen zu Berechtigungen finden Sie in einem der folgenden Abschnitte.
• Die von der App benötigten Hardware- und Softwarefunktionen, die sich darauf auswirken, auf welchen Geräten die App über Google Play installiert werden kann. Weitere Informationen zur Gerätekompatibilität findest du im folgenden Abschnitt.

Wenn Sie Android Studio zum Erstellen Ihrer App verwenden, wird die Manifestdatei für Sie erstellt und die meisten wichtigen Manifestelemente werden beim Erstellen Ihrer App hinzugefügt, insbesondere wenn Sie Codevorlagen verwenden.

Dateifunktionen

In den folgenden Abschnitten wird beschrieben, wie einige der wichtigsten Merkmale Ihrer App in der Manifestdatei widergespiegelt werden.

App-Komponenten

Deklarieren Sie für jede Anwendungskomponente, die Sie in Ihrer Anwendung erstellen, ein entsprechendes XML-Element in der Manifestdatei:

• <activity> für jede Unterklasse von Activity
• <service> für jede Unterklasse von Service
• <receiver> für jede Unterklasse von BroadcastReceiver
• <provider> für jede Unterklasse von ContentProvider

Wenn du eine dieser Komponenten als Unterklasse deklarierst, ohne sie in der Manifestdatei zu deklarieren, kann das System sie nicht starten.

Geben Sie den Namen Ihrer Unterklasse mit dem Attribut name und der vollständigen Paketbezeichnung an. Eine Activity-Unterklasse wird beispielsweise so deklariert:

<manifest ... >
    <application ... >
        <activity android:name="com.example.myapp.MainActivity" ... >
        </activity>
    </application>
</manifest>

Wenn das erste Zeichen im Wert name jedoch ein Punkt ist, wird dem Namen der Namespace der App aus dem Attribut namespace der Datei build.gradle auf Modulebene vorangestellt. Wenn der Namespace beispielsweise "com.example.myapp" lautet, wird der folgende Aktivitätsname in com.example.myapp.MainActivity aufgelöst:

<manifest ... >
    <application ... >
        <activity android:name=".MainActivity" ... >
            ...
        </activity>
    </application>
</manifest>

Weitere Informationen zum Festlegen des Paketnamens oder Namespace finden Sie unter Namespace festlegen.

Wenn Sie App-Komponenten haben, die sich in Unterpaketen befinden, z. B. in com.example.myapp.purchases, müssen Sie im Wert name die fehlenden Unterpaketnamen hinzufügen, z. B. ".purchases.PayActivity", oder den voll qualifizierten Paketnamen verwenden.

Intent-Filter

App-Aktivitäten, Dienste und Übertragungsempfänger werden durch Intents aktiviert. Ein Intent ist eine Nachricht, die durch ein Intent-Objekt definiert wird. Es beschreibt eine auszuführende Aktion, einschließlich der Daten, auf die sich die Aktion bezieht, der Kategorie der Komponente, die die Aktion ausführen soll, und anderer Anweisungen.

Wenn eine App einen Intent an das System sendet, sucht das System anhand der Intent-Filter-Deklarationen in der Manifestdatei der jeweiligen App nach einer App-Komponente, die den Intent verarbeiten kann. Das System startet eine Instanz der übereinstimmenden Komponente und übergibt das Intent-Objekt an diese Komponente. Wenn mehr als eine App den Intent verarbeiten kann, kann der Nutzer auswählen, welche App verwendet werden soll.

Eine App-Komponente kann beliebig viele Intent-Filter haben, die mit dem Element <intent-filter> definiert werden. Jeder Filter beschreibt eine andere Funktion dieser Komponente.

Weitere Informationen finden Sie im Dokument Intents and Intent Filters.

Symbole und Labels

Eine Reihe von Manifestelementen haben die Attribute icon und label, um Nutzern ein kleines Symbol und ein Textlabel für die entsprechende App-Komponente anzuzeigen.

In jedem Fall werden das Symbol und das Label, die in einem übergeordneten Element festgelegt sind, zum Standardwert für icon und label für alle untergeordneten Elemente. Das Symbol und das Label, die im Element <application> festgelegt sind, sind beispielsweise das Standardsymbol und das Standardlabel für jede Komponente der App, z. B. für alle Aktivitäten.

Das Symbol und das Label, die in der <intent-filter> einer Komponente festgelegt sind, werden dem Nutzer immer dann angezeigt, wenn diese Komponente als Option zur Erfüllung eines Intents präsentiert wird. Standardmäßig wird dieses Symbol von dem Symbol übernommen, das für die übergeordnete Komponente deklariert ist, entweder das Element <activity> oder <application>.

Du kannst das Symbol für einen Intent-Filter ändern, wenn er eine eindeutige Aktion bietet, die du im Auswahldialog besser kennzeichnen möchtest. Weitere Informationen finden Sie unter Anderen Apps das Starten einer Aktivität erlauben.

Berechtigungen

Android-Apps müssen eine Berechtigung anfordern, um auf sensible Nutzerdaten wie Kontakte und SMS oder bestimmte Systemfunktionen wie die Kamera und den Internetzugriff zuzugreifen. Jede Berechtigung wird durch ein eindeutiges Label identifiziert. Eine App, die SMS senden muss, muss beispielsweise die folgende Zeile im Manifest enthalten:

<manifest ... >
    <uses-permission android:name="android.permission.SEND_SMS"/>
    ...
</manifest>

Ab Android 6.0 (API-Level 23) können Nutzer einige App-Berechtigungen zur Laufzeit genehmigen oder ablehnen. Unabhängig davon, welche Android-Version deine App unterstützt, musst du alle Berechtigungsanfragen mit einem <uses-permission>-Element im Manifest deklarieren. Wenn die Berechtigung gewährt wird, kann die App die geschützten Funktionen verwenden. Andernfalls schlagen die Zugriffsversuche auf diese Funktionen fehl.

Ihre App kann auch ihre eigenen Komponenten mit Berechtigungen schützen. Sie kann alle von Android definierten Berechtigungen verwenden, die unter android.Manifest.permission aufgeführt sind, oder eine Berechtigung, die in einer anderen App deklariert ist. Ihre App kann auch eigene Berechtigungen definieren. Eine neue Berechtigung wird mit dem Element <permission> deklariert.

Weitere Informationen finden Sie unter Berechtigungen unter Android.

Gerätekompatibilität

In der Manifestdatei kannst du auch deklarieren, welche Arten von Hardware- oder Softwarefunktionen deine App benötigt und mit welchen Gerätetypen sie kompatibel ist. Im Google Play Store können Nutzer Ihre App nicht auf Geräten installieren, die nicht die Funktionen oder die Systemversion bieten, die Ihre App erfordert.

Es gibt mehrere Manifest-Tags, die definieren, mit welchen Geräten Ihre App kompatibel ist. Im Folgenden finden Sie einige der häufigsten Gründe.

<uses-feature>

Mit dem Element <uses-feature> kannst du Hardware- und Softwarefunktionen deklarieren, die deine App benötigt. Wenn Ihre App beispielsweise ohne Kompasssensor auf einem Gerät nicht die grundlegenden Funktionen ausführen kann, können Sie den Kompasssensor mit dem folgenden Manifest-Tag als erforderlich deklarieren:

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

Hinweis: Wenn du deine App auf Chromebooks verfügbar machen möchtest, musst du einige wichtige Einschränkungen bei Hardware- und Softwarefunktionen beachten. Weitere Informationen finden Sie unter App-Manifest-Kompatibilität für Chromebooks.

<uses-sdk>

Mit jeder neuen Plattformversion werden oft neue APIs hinzugefügt, die in der vorherigen Version nicht verfügbar waren. Wenn Sie die Mindestversion angeben möchten, mit der Ihre App kompatibel ist, muss Ihr Manifest das Tag <uses-sdk> und das Attribut minSdkVersion enthalten.

Beachten Sie jedoch, dass Attribute im <uses-sdk>-Element durch entsprechende Properties in der Datei build.gradle überschrieben werden. Wenn Sie Android Studio verwenden, geben Sie die Werte für minSdkVersion und targetSdkVersion stattdessen dort an:

android {
    defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 23

        // Specifies the API level used to test the app.
        targetSdkVersion 36
        ...
    }
}

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(23)

        // Specifies the API level used to test the app.
        targetSdkVersion(36)
        ...
    }
}

Weitere Informationen zur Datei build.gradle finden Sie unter Build konfigurieren.

Weitere Informationen dazu, wie du die Unterstützung deiner App für verschiedene Geräte deklarierst, findest du in der Übersicht zur Gerätekompatibilität.

Dateikonventionen

In diesem Abschnitt werden die Konventionen und Regeln beschrieben, die im Allgemeinen für alle Elemente und Attribute in der Manifestdatei gelten.

Elemente

Nur die Elemente <manifest> und <application> sind erforderlich. Jeder darf nur einmal vorkommen. Die meisten anderen Elemente können null oder mehrmals vorkommen. Einige davon müssen jedoch vorhanden sein, damit die Manifestdatei nützlich ist.

Alle Werte werden über Attribute festgelegt, nicht als Zeichendaten innerhalb eines Elements.

Elemente auf derselben Ebene sind im Allgemeinen nicht geordnet. Die Elemente <activity>, <provider> und <service> können beispielsweise in beliebiger Reihenfolge platziert werden. Für diese Regel gibt es zwei wichtige Ausnahmen:

• Ein <activity-alias>-Element muss auf das <activity>-Element folgen, für das es ein Alias ist.
• Das <application>-Element muss das letzte Element im <manifest>-Element sein.

Attribute

Technisch gesehen sind alle Attribute optional. Viele Attribute müssen jedoch angegeben werden, damit ein Element seinen Zweck erfüllen kann. Für wirklich optionale Attribute werden in der Referenzdokumentation die Standardwerte angegeben.

Mit Ausnahme einiger Attribute des Stammelements <manifest> beginnen alle Attributnamen mit dem Präfix android:, z. B. android:alwaysRetainTaskState. Da das Präfix universell ist, wird es in der Dokumentation im Allgemeinen weggelassen, wenn auf Attribute namentlich verwiesen wird.

Mehrere Werte

Wenn mehr als ein Wert angegeben werden kann, wird das Element fast immer wiederholt, anstatt mehrere Werte in einem einzelnen Element aufzulisten. Ein Intent-Filter kann beispielsweise mehrere Aktionen auflisten:

<intent-filter ... >
    <action android:name="android.intent.action.EDIT" />
    <action android:name="android.intent.action.INSERT" />
    <action android:name="android.intent.action.DELETE" />
    ...
</intent-filter>

Ressourcenwerte

Einige Attribute haben Werte, die Nutzern angezeigt werden, z. B. der Titel einer Aktivität oder das App-Symbol. Der Wert für diese Attribute kann je nach Sprache des Nutzers oder anderen Gerätekonfigurationen variieren (z. B. um je nach Pixeldichte des Geräts eine andere Symbolgröße bereitzustellen). Daher sollten die Werte über eine Ressource oder ein Design festgelegt werden, anstatt sie in der Manifestdatei hartzucodieren. Der tatsächliche Wert kann sich dann je nach den alternativen Ressourcen ändern, die du für verschiedene Gerätekonfigurationen bereitstellst.

Ressourcen werden als Werte im folgenden Format angegeben:

"@[package:]type/name"

Sie können den Namen package weglassen, wenn die Ressource von Ihrer App bereitgestellt wird (auch wenn sie von einer Bibliotheksabhängigkeit bereitgestellt wird, da Bibliotheksressourcen mit Ihren zusammengeführt werden). Der einzige andere gültige Paketname ist android, wenn Sie eine Ressource aus dem Android-Framework verwenden möchten.

type ist ein Ressourcentyp, z. B. string oder drawable, und name ist der Name, der die spezifische Ressource identifiziert. Hier ein Beispiel:

<activity android:icon="@drawable/smallPic" ... >

Weitere Informationen zum Hinzufügen von Ressourcen zu Ihrem Projekt finden Sie unter App-Ressourcen – Übersicht.

Wenn Sie stattdessen einen Wert anwenden möchten, der in einem Design definiert ist, muss das erste Zeichen ? anstelle von @ sein:

"?[package:]type/name"

Stringwerte

Wenn ein Attributwert ein String ist, verwenden Sie doppelte umgekehrte Schrägstriche (\\), um Escape-Zeichen zu verwenden, z. B. \\n für eine neue Zeile oder \\uxxxx für ein Unicode-Zeichen.

Referenz zu Manifestelementen

In der folgenden Tabelle finden Sie Links zu den Referenzdokumenten für alle gültigen Elemente in der Datei AndroidManifest.xml.

Limits

Für die folgenden Tags gilt eine Beschränkung für die Anzahl der Vorkommen in einer Manifestdatei:

Für die folgenden Attribute gilt eine maximale Länge:

Beispiel für eine Manifestdatei

Das folgende XML-Beispiel ist ein einfaches AndroidManifest.xml, in dem zwei Aktivitäten für die App deklariert werden.

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1"
    android:versionName="1.0">

    <!-- Beware that these values are overridden by the build.gradle file -->
    <uses-sdk android:minSdkVersion="15" android:targetSdkVersion="26" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">

        <!-- This name is resolved to com.example.myapp.MainActivity
             based on the namespace property in the build.gradle file -->
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity
            android:name=".DisplayMessageActivity"
            android:parentActivityName=".MainActivity" />
    </application>
</manifest>