App-Manifest – Übersicht

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

Die Manifestdatei ist unter anderem erforderlich, um Folgendes zu deklarieren:

Die Komponenten der App, einschließlich aller Aktivitäten, Dienste, Broadcast-Empfänger und Contentanbieter. Für jede Komponente müssen grundlegende Eigenschaften wie der Name der Kotlin- oder Java-Klasse definiert werden. 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 benötigen, wenn sie auf Inhalte aus dieser App zugreifen möchten. Weitere Informationen zu Berechtigungen finden Sie in einem der folgenden Abschnitte.
Die Hardware- und Softwarefunktionen, die die App benötigt. Dies wirkt sich darauf aus, auf welchen Geräten die App über Google Play installiert werden kann. Weitere Informationen zur Gerätekompatibilität finden Sie in einem der folgenden Abschnitte.

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

Dateifunktionen

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

App-Komponenten

Deklarieren Sie für jede App Komponente, die Sie in Ihrer App 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 Sie eine dieser Komponenten unterklassen, ohne sie in der Manifestdatei zu deklarieren, kann sie vom System nicht gestartet werden.

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

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

Wenn das erste Zeichen im name-Wert jedoch ein Punkt ist, wird dem Namen der Namespace der App aus der build.gradle-Datei auf Modulebene namespace -Property vorangestellt. Wenn der Namespace beispielsweise "com.example.myapp" ist, wird der folgende Aktivitätsname zu 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 dem name Wert die fehlenden Unterpaketnamen hinzufügen, z. B. ".purchases.PayActivity", oder den voll qualifizierten Paketnamen verwenden.

Intent-Filter

App-Aktivitäten, -Dienste und -Broadcast-Empfänger werden durch Intents aktiviert. Ein Intent ist eine Nachricht, die durch ein Intent-Objekt definiert wird und eine auszuführende Aktion beschreibt, 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 jeder App nach einer App-Komponente, die den Intent verarbeiten kann. Das System startet eine Instanz der entsprechenden 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 (definiert mit dem <intent-filter> Element), die jeweils eine andere Funktion dieser Komponente beschreiben.

Weitere Informationen finden Sie im Dokument Intents und Intent-Filter.

Symbole und Labels

Eine Reihe von Manifestelementen haben die Attribute icon und label, um Nutzern ein kleines Symbol bzw. 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 <application> Element festgelegt sind, sind beispielsweise das Standardsymbol und das Standardlabel für jede der Komponenten der App, z. B. alle Aktivitäten.

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

Möglicherweise möchten Sie das Symbol für einen Intent-Filter ändern, wenn er eine eindeutige Aktion bietet, die Sie im Auswahlfenster besser hervorheben möchten. Weitere Informationen finden Sie unter Anderen Apps das Starten einer Aktivität erlauben.

Berechtigungen

Android-Apps müssen die Berechtigung anfordern, 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-Nachrichten senden muss, muss beispielsweise die folgende Zeile im Manifest haben:

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

Ab Android 6.0 (API-Level 23) kann der Nutzer einige App-Berechtigungen zur Laufzeit genehmigen oder ablehnen. Unabhängig davon, welche Android-Version Ihre App unterstützt, müssen Sie alle Berechtigungsanfragen mit einem <uses-permission> Element im Manifest deklarieren. Wenn die Berechtigung erteilt wird, kann die App die geschützten Funktionen verwenden. Andernfalls schlagen die Versuche, auf diese Funktionen zuzugreifen, fehl.

Ihre App kann ihre eigenen Komponenten auch mit Berechtigungen schützen. Sie kann alle von Android definierten Berechtigungen verwenden, die in 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 <permission> Element deklariert.

Weitere Informationen finden Sie unter Berechtigungen unter Android.

Gerätekompatibilität

In der Manifestdatei können Sie auch deklarieren, welche Arten von Hardware- oder Softwarefunktionen Ihre App benötigt und mit welchen Arten von Geräten Ihre App 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 benötigt.

Es gibt mehrere Manifest-Tags, die definieren, mit welchen Geräten Ihre App kompatibel ist. Im Folgenden sind einige der häufigsten aufgeführt.

<uses-feature>

Mit dem <uses-feature> Element können Sie Hardware- und Softwarefunktionen deklarieren, die Ihre App benötigt. Wenn Ihre App beispielsweise auf einem Gerät ohne Kompasssensor keine 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 Sie Ihre App auf Chromebooks verfügbar machen möchten, müssen Sie einige wichtige Einschränkungen für Hardware- und Softwarefunktionen berücksichtigen. Weitere Informationen finden Sie unter App-Manifest-Kompatibilität für Chromebooks.

<uses-sdk>

Mit jeder nachfolgenden Plattformversion werden häufig neue APIs hinzugefügt, die in der vorherigen Version nicht verfügbar sind. Um die Mindestversion anzugeben, mit der Ihre App kompatibel ist, muss Ihr Manifest das <uses-sdk> Tag und das minSdkVersion Attribut enthalten.

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

Groovy

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
        ...
    }
}

Kotlin

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 build.gradle-Datei finden Sie unter Build konfigurieren.

Weitere Informationen zum Deklarieren der Unterstützung Ihrer App für verschiedene Geräte finden Sie unter Gerätekompatibilität – Übersicht.

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 <manifest> und <application> Elemente sind erforderlich. Sie dürfen jeweils nur einmal vorkommen. Die meisten anderen Elemente können null oder mehr Male vorkommen. Einige von ihnen 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 in der Regel nicht sortiert. Die Elemente <activity>, <provider>und <service> können beispielsweise in beliebiger Reihenfolge platziert werden. Es gibt zwei wichtige Ausnahmen von dieser Regel:

Ein <activity-alias> -Element muss auf das <activity> 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 sind in der Referenzdokumentation die Standardwerte angegeben.

Mit Ausnahme einiger Attribute des Stammverzeichnisses <manifest> beginnen alle Attributnamen mit dem Präfix android:, z. B. android:alwaysRetainTaskState. Da das Präfix universell ist, wird es in der Dokumentation in der Regel weggelassen, wenn auf Attribute anhand ihres Namens 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 eine andere Symbolgröße basierend auf der Pixeldichte des Geräts bereitzustellen). Daher sollten die Werte aus einer Ressource oder einem Design festgelegt werden, anstatt sie fest in die Manifestdatei zu codieren. Der tatsächliche Wert kann sich dann basierend auf alternativen Ressourcen ändern, die Sie für verschiedene Gerätekonfigurationen bereitstellen.

Ressourcen werden als Werte im folgenden Format ausgedrückt:

"@[package:]type/name"

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

Der type ist ein Ressourcentyp, z. B. string oder drawable, und der 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 sein anstelle von @:?

"?[package:]type/name"

Stringwerte

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

Referenz zu Manifestelementen

Die folgende Tabelle enthält Links zu den Referenzdokumenten für alle gültigen Elemente in der Datei AndroidManifest.xml.

`<action>`	Fügt einem Intent-Filter eine Aktion hinzu.
`<activity>`	Deklariert eine Aktivitätskomponente.
`<activity-alias>`	Deklariert ein Alias für eine Aktivität.
`<application>`	Deklariert die Anwendung.
`<category>`	Fügt einem Intent-Filter einen Kategorienamen hinzu.
`<compatible-screens>`	Gibt jede Bildschirmkonfiguration an, mit der die Anwendung kompatibel ist.
`<data>`	Fügt einem Intent-Filter eine Datenspezifikation hinzu.
`<grant-uri-permission>`	Gibt die Teilmengen von App-Daten an, auf die der übergeordnete Contentanbieter Zugriff hat.
`<instrumentation>`	Deklariert eine `Instrumentation`-Klasse, mit der Sie die Interaktion einer Anwendung mit dem System überwachen können.
`<intent-filter>`	Gibt die Arten von Intents an, auf die eine Aktivität, ein Dienst oder ein Übertragungsempfänger reagieren kann.
`<manifest>`	Das Stammelement der Datei `AndroidManifest.xml`.
`<meta-data>`	Ein Name/Wert-Paar für ein Element mit zusätzlichen, beliebigen Daten, die der übergeordneten Komponente zur Verfügung gestellt werden können.
`<path-permission>`	Definiert den Pfad und die erforderlichen Berechtigungen für eine bestimmte Teilmenge von Daten in einem Contentanbieter.
`<permission>`	Deklariert eine Sicherheitsberechtigung, mit der der Zugriff auf bestimmte Komponenten oder Funktionen dieser oder anderer Anwendungen eingeschränkt werden kann.
`<permission-group>`	Deklariert einen Namen für eine logische Gruppierung verwandter Berechtigungen.
`<permission-tree>`	Deklariert den Basisnamen für eine Berechtigungsstruktur.
`<provider>`	Deklariert eine Contentanbieterkomponente.
`<queries>`	Deklariert die Gruppe anderer Apps, auf die Ihre App zugreifen möchte. Weitere Informationen finden Sie im Leitfaden zum Filtern der Paketsichtbarkeit.
`<receiver>`	Deklariert eine Übertragungsempfängerkomponente.
`<service>`	Deklariert eine Dienstkomponente.
`<supports-gl-texture>`	Deklariert ein einzelnes GL-Texturkomprimierungsformat, das von der App unterstützt wird.
`<supports-screens>`	Deklariert die Bildschirmgrößen, die Ihre App unterstützt, und aktiviert den Bildschirmkompatibilitätsmodus für Bildschirme, die größer sind als die von Ihrer App unterstützten.
`<uses-configuration>`	Gibt bestimmte Eingabefunktionen an, die die Anwendung benötigt.
`<uses-feature>`	Deklariert eine einzelne Hardware- oder Softwarefunktion, die von der Anwendung verwendet wird.
`<uses-library>`	Gibt eine gemeinsam genutzte Bibliothek an, mit der die Anwendung verknüpft werden muss.
`<uses-native-library>`	Gibt eine vom Anbieter bereitgestellte native gemeinsam genutzte Bibliothek an, mit der die App verknüpft werden muss.
`<uses-permission>`	Gibt eine Systemberechtigung an, die der Nutzer erteilen muss, damit die App ordnungsgemäß funktioniert.
`<uses-permission-sdk-23>`	Gibt an, dass eine App eine bestimmte Berechtigung benötigt, aber nur, wenn die App auf einem Gerät mit Android 6.0 (API-Level 23) oder höher installiert ist.
`<uses-sdk>`	Ermöglicht es Ihnen, die Kompatibilität einer Anwendung mit einer oder mehreren Versionen der Android-Plattform mithilfe einer API-Level-Ganzzahl auszudrücken.

Limits

Für die folgenden Tags gilt ein Limit für die Anzahl der Vorkommen in einer Manifestdatei:

Tag-Name	Limit
`<package>`	`1000`
`<meta-data>`	`1000`
`<uses-library>`	`1000`

Für die folgenden Attribute gilt ein Limit für die maximale Länge:

Attribut	Limit
`name`	`1024`
`versionName`	`1024`
`host`	`255`
`mimeType`	`255`

Beispiel für eine Manifestdatei

Das folgende XML ist ein einfaches Beispiel für eine AndroidManifest.xml-Datei, in der 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>

App-Manifest – Übersicht Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.