Diese Seite wurde von der Cloud Translation API übersetzt.

App-Manifest – Übersicht

Jedes Anwendungsprojekt muss eine AndroidManifest.xml-Datei mit genau diesem Namen im Stammverzeichnis des Projektquellsatzes haben. 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 Eigenschaften definiert werden, z. B. der Name ihrer Kotlin- oder Java-Klasse. Außerdem können Funktionen deklariert werden, z. B. welche Gerätekonfigurationen verarbeitet werden können, und Intent-Filter, mit denen beschrieben wird, wie die Komponente gestartet werden kann. Weitere Informationen zu App-Komponenten finden Sie im folgenden Abschnitt.
Die Berechtigungen, die die App für den Zugriff auf geschützte Teile des Systems oder anderer Apps benötigt. 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 im folgenden Abschnitt.
Die für die 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 finden Sie in einem der folgenden Abschnitte.

Wenn du deine App mit Android Studio entwickelst, wird die Manifestdatei automatisch erstellt und die meisten wichtigen Manifestelemente werden beim Erstellen deiner App hinzugefügt. Das gilt insbesondere, wenn du Codevorlagen verwendest.

Dateifunktionen

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

App-Komponenten

Deklariere für jede App-Komponente, die du in deiner Anwendung erstellst, ein entsprechendes XML-Element in der Manifestdatei:

<activity> für jede abgeleitete Klasse von Activity
<service> für jede abgeleitete Klasse von Service
<receiver> für jede abgeleitete Klasse von BroadcastReceiver
<provider> für jede abgeleitete Klasse von ContentProvider

Wenn Sie eine dieser Komponenten ableiten, ohne sie in der Manifestdatei zu deklarieren, kann sie vom System nicht gestartet werden.

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

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

Wenn jedoch das erste Zeichen im Wert name ein Punkt ist, wird der Namespace der Anwendung aus dem Attribut namespace der Datei build.gradle auf Modulebene dem Namen vorangestellt. Wenn der Namespace beispielsweise "com.example.myapp" ist, 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 Anwendungskomponenten haben, die sich in Unterpaketen wie com.example.myapp.purchases befinden, muss der Wert name die fehlenden Namen von Unterpaketen (z. B. ".purchases.PayActivity") hinzufügen 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 von einem Intent-Objekt definiert wird und eine auszuführende Aktion beschreibt. Dazu gehören die Daten, für die eine Aktion ausgeführt werden soll, die Kategorie der Komponente, die die Aktion ausführen soll, sowie weitere Anweisungen.

Wenn eine Anwendung einen Intent an das System ausgibt, sucht das System nach einer Anwendungskomponente, die den Intent anhand von Intent-Filter-Deklarationen in der Manifestdatei jeder Anwendung 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 die zu verwendende App auswählen.

Eine App-Komponente kann eine beliebige Anzahl von Intent-Filtern haben (definiert mit dem Element <intent-filter>), die jeweils eine andere Funktion der 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 für die entsprechende App-Komponente ein kleines Symbol bzw. ein Textlabel anzuzeigen.

In jedem Fall werden das Symbol und das Label, die in einem übergeordneten Element festgelegt sind, zu den standardmäßigen icon- und label-Werten für alle untergeordneten Elemente. Das im Element <application> festgelegte Symbol und Label sind beispielsweise das Standardsymbol und ‐label 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 angezeigt, wenn diese Komponente als Option zum Erfüllen eines Intents präsentiert wird. Standardmäßig wird dieses Symbol von dem Symbol übernommen, das für die übergeordnete Komponente deklariert wurde, also entweder vom <activity>- oder <application>-Element.

Sie können das Symbol für einen Intent-Filter ändern, wenn er eine eindeutige Aktion bietet, die Sie im Auswahldialogfeld besser angeben möchten. Weitere Informationen finden Sie unter Anderen Apps erlauben, Aktivitäten zu starten.

Berechtigungen

Android-Apps müssen die Berechtigung anfordern, um auf sensible Nutzerdaten wie Kontakte und SMS oder auf bestimmte Systemfunktionen wie Kamera und Internet zuzugreifen. Jede Berechtigung ist durch ein eindeutiges Label gekennzeichnet. Beispielsweise muss eine App, die SMS senden muss, die folgende Zeile im Manifest haben:

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

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

Ihre App kann auch ihre eigenen Komponenten mit Berechtigungen schützen. Sie kann jede der von Android definierten Berechtigungen (siehe android.Manifest.permission) oder eine in einer anderen App deklarierte Berechtigung verwenden. Sie können auch eigene Berechtigungen definieren. Mit dem Element <permission> wird eine neue Berechtigung deklariert.

Weitere Informationen finden Sie unter Berechtigungen unter Android.

Eingeschränkte Gerätekompatibilität

In der Manifestdatei kannst du außerdem angeben, welche Arten von Hardware- oder Softwarefunktionen deine App benötigt und mit welchen Gerätetypen deine App kompatibel ist. Nutzer können deine App im Google Play Store nur auf Geräten installieren, die nicht die für deine App erforderlichen Funktionen oder Systemversionen bieten.

Es gibt mehrere Manifest-Tags, mit denen festgelegt wird, mit welchen Geräten deine 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 angeben, die Ihre Anwendung benötigt. Wenn Ihre App beispielsweise auf einem Gerät ohne Kompasssensor die grundlegenden Funktionen nicht 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, sind einige wichtige Einschränkungen bei Hardware- und Softwarefunktionen zu beachten. Weitere Informationen findest du unter Kompatibilität von App-Manifesten für Chromebooks.

<uses-sdk>

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

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

Cool

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 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. Sie dürfen jeweils nur einmal vorkommen. Die meisten anderen Elemente können nicht oder öfter vorkommen. Es müssen jedoch einige von ihnen vorhanden sein, damit die Manifestdatei nützlich ist.

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

Elemente auf derselben Ebene werden in der Regel nicht sortiert. So können beispielsweise die Elemente <activity>, <provider> und <service> 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 innerhalb des <manifest>-Elements sein.

Attribute

Technisch gesehen sind alle Attribute optional. Allerdings müssen viele Attribute 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 namentlich auf Attribute verwiesen wird.

Mehrere Werte

Wenn mehr als ein Wert angegeben werden kann, wird das Element fast immer wiederholt, anstatt mehrere Werte innerhalb eines einzelnen Elements 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 Ihr App-Symbol. Der Wert für diese Attribute kann je nach Sprache des Nutzers oder anderen Gerätekonfigurationen variieren (z. B. um eine unterschiedliche Symbolgröße basierend auf der Pixeldichte des Geräts bereitzustellen). Daher sollten die Werte von einer Ressource oder einem Design festgelegt und nicht in der Manifestdatei hartcodiert werden. Der tatsächliche Wert kann sich dann je nach alternativen Ressourcen ändern, die Sie für unterschiedliche Gerätekonfigurationen angeben.

Ressourcen werden als Werte im folgenden Format ausgedrückt:

"@[package:]type/name"

Sie können den Namen package weglassen, wenn die Ressource von Ihrer Anwendung bereitgestellt wird (z. B. wenn sie durch eine Bibliotheksabhängigkeit bereitgestellt wird, da Bibliotheksressourcen mit Ihren eigenen 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 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 theme definiert ist, muss das erste Zeichen ? und nicht @ sein:

"?[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.

Verweis auf Manifestelemente

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 einen 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 App 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 Contentanbieter zugreifen darf.
`<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 bereitgestellt werden können.
`<path-permission>`	Definiert den Pfad und die erforderlichen Berechtigungen für eine bestimmte Teilmenge von Daten innerhalb eines Contentanbieters.
`<permission>`	Deklariert eine Sicherheitsberechtigung, mit der der Zugriff auf bestimmte Komponenten oder Funktionen dieser oder anderer Apps eingeschränkt werden kann.
`<permission-group>`	Gibt einen Namen für eine logische Gruppierung zusammengehöriger Berechtigungen an.
`<permission-tree>`	Deklariert den Basisnamen für eine Baumstruktur von Berechtigungen.
`<provider>`	Deklariert eine Komponente des Contentanbieters.
`<queries>`	Deklariert die anderen 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 als die von Ihrer App unterstützten Bildschirme sind.
`<uses-configuration>`	Gibt bestimmte Eingabefunktionen an, die die Anwendung benötigt.
`<uses-feature>`	Gibt eine einzelne Hardware- oder Softwarefunktion an, 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 korrekt funktioniert.
`<uses-permission-sdk-23>`	Gibt an, dass eine App eine bestimmte Berechtigung anfordert, aber nur, wenn sie auf einem Gerät mit Android 6.0 (API-Level 23) oder höher installiert ist.
`<uses-sdk>`	Hiermit können Sie die Kompatibilität einer Anwendung mit einer oder mehreren Versionen der Android-Plattform mittels einer Ganzzahl auf API-Ebene zum Ausdruck bringen.

Beispiel für eine Manifestdatei

Die folgende XML-Datei ist ein einfaches AndroidManifest.xml-Beispiel, in dem zwei Aktivitäten für die Anwendung deklariert sind.

<?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>