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
Deklariere für jede App-Komponente, die du in deiner Anwendung erstellst, ein entsprechendes XML-Element in der Manifestdatei:
<activity>
für jede Unterklasse vonActivity
<service>
für jede abgeleitete Klasse vonService
<receiver>
für jede Unterklasse vonBroadcastReceiver
<provider>
für jede Unterklasse vonContentProvider
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
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 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"
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 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 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 ausgibt, sucht das System nach einer Anwendungskomponente, die den Intent anhand von Intent-Filter-Deklarationen in der Manifestdatei der jeweiligen App 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 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 für die entsprechende App-Komponente jeweils ein kleines Symbol und ein Textlabel 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 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 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 <activity>
- oder vom <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 Starten einer Aktivität durch andere Apps erlauben.
Berechtigungen
Android-Apps müssen die Berechtigung zum Zugriff auf sensible Nutzerdaten wie Kontakte und SMS oder bestimmte Systemfunktionen wie die Kamera und den Internetzugriff anfordern. Jede Berechtigung ist 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 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 Zugriffsversuche auf diese Funktionen 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.
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, 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 deklarieren, die für Ihre App erforderlich sind. 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 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 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 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 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 im<manifest>
-Element sein.
-
Ein
- 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äfixandroid:
, 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 Ihr 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
oderdrawable
. 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> |
Deklariert die Anwendung. |
<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 Contentanbieter 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 Übertragungsempfä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> |
Deklariert den Basisnamen für eine Baumstruktur von Berechtigungen. |
<provider> |
Deklariert eine Komponente des Contentanbieters. |
<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> |
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. |
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>