Diese Seite wurde von der Cloud Translation API übersetzt.

App-Manifest – Übersicht

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

In der Manifestdatei müssen unter anderem Folgendes angegeben werden:

Die Komponenten der App, einschließlich aller Aktivitäten, Dienste, Übertragungsempfänger und Inhaltsanbieter. Für jede Komponente müssen grundlegende Eigenschaften 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 im nächsten Abschnitt.
Die Berechtigungen, die die App für den Zugriff auf geschützte Teile des Systems oder andere Apps benötigt. Außerdem werden alle Berechtigungen deklariert, die andere Apps benötigen, um auf Inhalte dieser App zugreifen zu können. Weitere Informationen zu Berechtigungen finden Sie im nächsten Abschnitt.
Die von der App erforderlichen 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

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 wenn Sie Codevorlagen verwenden.

Dateifunktionen

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

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 unterordnen, ohne sie in der Manifestdatei zu deklarieren, kann das System sie nicht starten.

Geben Sie den Namen Ihrer Unterklasse mit dem Attribut name an. 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 der Namespace der App aus der namespace-Eigenschaft der build.gradle-Datei 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 Namespaces finden Sie unter Namespace festlegen.

Wenn App-Komponenten in Unterpaketen wie com.example.myapp.purchases vorhanden sind, müssen dem Wert name die fehlenden Unterpaketnamen wie ".purchases.PayActivity" hinzugefügt werden oder der voll qualifizierte Paketname verwendet werden.

Intent-Filter

App-Aktivitäten, Dienste und Broadcastempfänger werden durch Intents aktiviert. Ein Intent ist eine Nachricht, die von einem Intent-Objekt definiert wird und eine durchzuführende Aktion beschreibt, einschließlich der Daten, auf die die Aktion angewendet werden soll, 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-Filterdeklarationen 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 mehrere Apps den Intent verarbeiten können, kann der Nutzer auswählen, welche App verwendet werden soll.

Eine App-Komponente kann beliebig viele Intent-Filter (definiert mit dem Element <intent-filter>) haben, die jeweils eine andere Funktion dieser Komponente beschreiben.

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

Symbole und Labels

Einige Manifestelemente haben die Attribute icon und label, um Nutzern jeweils 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, zu den Standardwerten 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 alle Komponenten 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 angezeigt, wenn diese Komponente als Option zur Erfüllung einer Absicht präsentiert wird. Standardmäßig wird dieses Symbol von dem Symbol übernommen, das für die übergeordnete Komponente deklariert ist, also entweder vom Element <activity> oder <application>.

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

Berechtigungen

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

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

Ab Android 6.0 (API-Ebene 23) können 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 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 eine der von Android definierten Berechtigungen (wie in android.Manifest.permission aufgeführt) oder eine Berechtigung verwenden, die in einer anderen App deklariert wurde. Ihre App kann auch eigene Berechtigungen definieren. Mit dem Element <permission> wird eine neue Berechtigung deklariert.

Weitere Informationen finden Sie unter Berechtigungen unter Android.

Gerätekompatibilität

In der Manifestdatei können Sie auch angeben, welche Arten von Hardware- oder Softwarefunktionen Ihre App benötigt und damit auch, mit welchen Gerätetypen Ihre App kompatibel ist. Im Google Play Store können Nutzer Ihre App nicht auf Geräten installieren, die nicht die für Ihre App erforderlichen Funktionen oder die erforderliche Systemversion bieten.

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 Element <uses-feature> können Sie Hardware- und Softwarefunktionen deklarieren, die für Ihre App erforderlich sind. Wenn Ihre App beispielsweise auf einem Gerät ohne Kompasssensor keine grundlegenden Funktionen bietet, 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 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. Um die Mindestversion anzugeben, mit der Ihre App kompatibel ist, muss Ihr Manifest das <uses-sdk>-Tag und das zugehörige minSdkVersion-Attribut enthalten.

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

Groovy

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

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

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

Kotlin

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

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

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

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

Weitere Informationen dazu, wie Sie die Unterstützung Ihrer App für verschiedene Geräte deklarieren, finden Sie in der Übersicht zur Gerätekompatibilität.

Dateikonventionen

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

Elemente

Nur die Elemente <manifest> und <application> sind erforderlich. Sie dürfen jeweils 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 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 Stammelements <manifest> beginnen alle Attributnamen mit einem android:-Präfix, z. B. android:alwaysRetainTaskState. Da das Präfix universell ist, wird es in der Dokumentation in der Regel weggelassen, wenn auf Attribute per Name verwiesen wird.

Mehrere Werte

Wenn mehrere Werte angegeben werden können, wird das Element fast immer wiederholt, anstatt dass mehrere Werte in einem einzelnen Element aufgeführt werden. Ein Intent-Filter kann beispielsweise mehrere Aktionen enthalten:

<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 in die Manifestdatei hartcodiert zu werden. Der tatsächliche Wert kann sich dann je nach alternativen Ressourcen ändern, die Sie für verschiedene Gerätekonfigurationen angeben.

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. Das gilt auch, wenn sie von einer Bibliotheksabhängigkeit bereitgestellt wird, da Bibliotheksressourcen in Ihre eigenen Ressourcen einfließen. Der einzige andere gültige Paketname ist android, wenn Sie eine Ressource aus dem Android-Framework verwenden möchten.

type ist eine Ressourcenart, z. B. string oder drawable. name ist der Name, der die jeweilige 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 Zeichen zu escapen, z. B. \\n für einen Zeilenvorschub oder \\uxxxx für ein Unicode-Zeichen.

Manifestelemente – Referenz

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

`<action>`	Fügt einem Intent-Filter eine Aktion hinzu.
`<activity>`	Hiermit wird eine Aktivitätskomponente deklariert.
`<activity-alias>`	Hiermit wird ein Alias für eine Aktivität deklariert.
`<application>`	Hier wird die Anwendung deklariert.
`<category>`	Fügen Sie 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 der App-Daten an, auf die der übergeordnete Inhaltsanbieter zugreifen darf.
`<instrumentation>`	Hiermit wird eine `Instrumentation`-Klasse deklariert, 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 Broadcastempfänger reagieren kann.
`<manifest>`	Das Stammelement der `AndroidManifest.xml`-Datei.
`<meta-data>`	Ein Name/Wert-Paar für ein Element mit zusätzlichen, beliebigen Daten, die an die übergeordnete Komponente übergeben werden können.
`<path-permission>`	Hiermit werden der Pfad und die erforderlichen Berechtigungen für eine bestimmte Teilmenge von Daten bei einem Contentanbieter definiert.
`<permission>`	Hiermit wird eine Sicherheitsberechtigung deklariert, mit der der Zugriff auf bestimmte Komponenten oder Funktionen dieser oder anderer Apps eingeschränkt werden kann.
`<permission-group>`	Hier wird ein Name für eine logische Gruppierung ähnlicher Berechtigungen angegeben.
`<permission-tree>`	Hier wird der Basisname für einen Berechtigungsbaum deklariert.
`<provider>`	Hiermit wird eine Contentanbieterkomponente deklariert.
`<queries>`	Hier wird angegeben, auf welche anderen Apps Ihre App zugreifen soll. Weitere Informationen finden Sie im Leitfaden zum Filtern der Sichtbarkeit von Paketen.
`<receiver>`	Hier wird eine Broadcast-Empfängerkomponente deklariert.
`<service>`	Hiermit wird eine Dienstkomponente deklariert.
`<supports-gl-texture>`	Hier wird ein einzelnes GL-Texturkomprimierungsformat deklariert, das von der App unterstützt wird.
`<supports-screens>`	Hiermit werden die Bildschirmgrößen deklariert, die von Ihrer App unterstützt werden, und der Bildschirmkompatibilitätsmodus für Bildschirme aktiviert, die größer sind als die von Ihrer App unterstützten.
`<uses-configuration>`	Gibt an, welche Eingabefunktionen für die Anwendung erforderlich sind.
`<uses-feature>`	Hier wird eine einzelne Hardware- oder Softwarefunktion deklariert, die von der Anwendung verwendet wird.
`<uses-library>`	Gibt eine freigegebene Bibliothek an, mit der die Anwendung verknüpft werden muss.
`<uses-native-library>`	Gibt eine vom Anbieter bereitgestellte native freigegebene Bibliothek an, mit der die App verknüpft werden muss.
`<uses-permission>`	Gibt eine Systemberechtigung an, die der Nutzer gewähren 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>`	Damit können Sie die Kompatibilität einer Anwendung mit einer oder mehreren Versionen der Android-Plattform anhand einer Ganzzahl auf API-Ebene angeben.

Beschränkungen

Für die folgenden Tags ist die Anzahl der Vorkommen in einer Manifestdatei begrenzt:

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

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

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

Beispiel für eine Manifestdatei

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