Manifestdateien verwalten

Auf dieser Seite wird beschrieben, wie das Zusammenführen von Manifesten funktioniert und wie Sie Zusammenführungseinstellungen anwenden können, um Zusammenführungskonflikte zu beheben. Eine Einführung in die App-Manifestdatei finden Sie in der Übersicht über das App-Manifest.

Mehrere Manifestdateien zusammenführen

Ihre APK- oder Android App Bundle-Datei kann nur eine AndroidManifest.xml-Datei enthalten. Ihr Android Studio-Projekt kann jedoch mehrere Manifestdateien enthalten, die vom Haupt-Source-Set, von Build-Varianten und von importierten Bibliotheken bereitgestellt werden. Beim Erstellen Ihrer App werden alle Manifestdateien im Gradle-Build zu einer einzigen Manifestdatei zusammengeführt, die in Ihrer App verpackt wird.

Das Manifest-Merger-Tool kombiniert alle XML-Elemente aus jeder Datei. Dabei werden Heuristiken für die Zusammenführung und die von Ihnen mit speziellen XML-Attributen definierten Zusammenführungseinstellungen berücksichtigt.

Prioritäten zusammenführen

Das Merger-Tool kombiniert alle Manifestdateien nacheinander in einer Datei, basierend auf der Priorität der einzelnen Manifestdateien. Wenn Sie beispielsweise drei Manifestdateien haben, wird das Manifest mit der niedrigsten Priorität mit dem Manifest mit der nächsthöheren Priorität zusammengeführt. Dieses wird dann mit dem Manifest mit der höchsten Priorität zusammengeführt, wie in Abbildung 1 dargestellt.

Abbildung 1. Der Prozess zum Zusammenführen von drei Manifestdateien, von der niedrigsten zur höchsten Priorität.

Es gibt drei grundlegende Typen von Manifestdateien, die miteinander zusammengeführt werden können. Ihre Zusammenführungsprioritäten sind wie folgt (höchste Priorität zuerst):

  1. Manifestdatei für Ihre Build-Variante

    Wenn Sie mehrere Source-Sets für Ihre Variante haben, sind die Manifestprioritäten wie folgt:

    • Build-Varianten-Manifest (z. B. src/demoDebug/)
    • Build-Typ-Manifest (z. B. src/debug/)

    • Manifest der Produktvariante (z. B. src/demo/)

      Wenn Sie Flavor-Dimensionen verwenden, entsprechen die Manifestprioritäten der Reihenfolge, in der die einzelnen Dimensionen im Attribut flavorDimensions aufgeführt sind (die erste hat die höchste Priorität).

  2. Hauptmanifestdatei für das App-Modul

  3. Manifestdatei aus einer eingebundenen Bibliothek

    Wenn Sie mehrere Bibliotheken haben, entspricht die Priorität ihrer Manifeste der Reihenfolge, in der sie im Gradle-Block dependencies angezeigt werden.

Beispielsweise wird ein Bibliotheksmanifest mit dem Hauptmanifest zusammengeführt und das Hauptmanifest dann mit dem Build-Variantenmanifest. Beachten Sie, dass dies dieselben Zusammenführungsprioritäten für alle Source-Sets sind, wie unter Mit Source-Sets erstellen beschrieben.

Heuristik für Zusammenführungskonflikte

Das Merger-Tool kann jedes XML-Element aus einem Manifest logisch mit einem entsprechenden Element in einem anderen Manifest abgleichen. Weitere Informationen zur Funktionsweise des Abgleichs finden Sie im vorherigen Abschnitt unter Zusammenführungsprioritäten.

Wenn ein Element aus dem Manifest mit niedrigerer Priorität mit keinem Element im Manifest mit höherer Priorität übereinstimmt, wird es dem zusammengeführten Manifest hinzugefügt. Wenn jedoch ein übereinstimmendes Element vorhanden ist, versucht das Merger-Tool, alle Attribute der einzelnen Elemente im selben Element zu kombinieren. Wenn das Tool feststellt, dass beide Manifeste dasselbe Attribut mit unterschiedlichen Werten enthalten, tritt ein Zusammenführungskonflikt auf.

In Tabelle 1 sind die möglichen Ergebnisse aufgeführt, wenn das Merger-Tool versucht, alle Attribute in demselben Element zu kombinieren.

Tabelle 1. Standardmäßiges Zusammenführungsverhalten für Attributwerte

Attribut mit hoher Priorität Attribut mit niedriger Priorität Zusammengeführtes Ergebnis des Attributs
Kein Wert Kein Wert Kein Wert (Standardwert verwenden)
Wert B Wert B
Wert A Kein Wert Wert A
Wert A Wert A
Wert B Konfliktfehler: Sie müssen eine Zusammenführungsregel-Markierung hinzufügen.

In einigen Situationen verhält sich das Merger-Tool jedoch anders, um Zusammenführungskonflikte zu vermeiden:

  • Attribute im <manifest>-Element werden nie zusammengeführt. Es werden nur die Attribute aus dem Manifest mit der höchsten Priorität verwendet.
  • Das Attribut android:required in den Elementen <uses-feature> und <uses-library> verwendet eine OR-Zusammenführung. Bei einem Konflikt wird "true" angewendet und das Feature oder die Bibliothek, die von einem Manifest benötigt wird, wird immer einbezogen.
  • Attribute im <uses-sdk>-Element verwenden immer den Wert aus dem Manifest mit der höheren Priorität, außer in den folgenden Situationen:
    • Wenn das Manifest mit niedrigerer Priorität einen höheren minSdk-Wert hat, tritt ein Fehler auf, es sei denn, Sie wenden die Zusammenführungsregel overrideLibrary an.
    • Wenn das Manifest mit niedrigerer Priorität einen niedrigeren targetSdkVersion-Wert hat, verwendet das Merger-Tool den Wert aus dem Manifest mit höherer Priorität. Außerdem werden alle Systemberechtigungen hinzugefügt, die erforderlich sind, damit die importierte Bibliothek weiterhin ordnungsgemäß funktioniert (für Fälle, in denen die höhere Android-Version strengere Berechtigungseinschränkungen hat). Weitere Informationen zu diesem Verhalten finden Sie im Abschnitt zu impliziten Systemberechtigungen.
  • Das Element <intent-filter> wird nie zwischen Manifesten abgeglichen. Jedes wird als eindeutig behandelt und dem gemeinsamen übergeordneten Element im zusammengeführten Manifest hinzugefügt.

Bei allen anderen Konflikten zwischen Attributen erhalten Sie eine Fehlermeldung und müssen dem Merger-Tool mitteilen, wie der Konflikt behoben werden soll. Dazu fügen Sie der Manifestdatei mit höherer Priorität ein spezielles Attribut hinzu. Weitere Informationen finden Sie im folgenden Abschnitt zu Markierungen für Zusammenführungsregeln.

Regelmarkierungen zusammenführen

Eine Zusammenführungsregel-Markierung ist ein XML-Attribut, mit dem Sie Ihre Präferenz für die Lösung von Zusammenführungskonflikten oder das Entfernen unerwünschter Elemente und Attribute angeben können. Sie können eine Markierung entweder auf ein ganzes Element oder nur auf bestimmte Attribute in einem Element anwenden.

Beim Zusammenführen von zwei Manifestdateien sucht das Merger-Tool in der Manifestdatei mit höherer Priorität nach diesen Markierungen.

Alle Markierungen gehören zum Android-Namespace tools. Sie müssen diesen Namespace daher zuerst im <manifest>-Element deklarieren, wie hier gezeigt:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp"
    xmlns:tools="http://schemas.android.com/tools">

Knotenmarkierungen

Wenn Sie eine Zusammenführungsregel auf ein ganzes XML-Element (auf alle Attribute in einem bestimmten Manifestelement und auf alle untergeordneten Tags) anwenden möchten, verwenden Sie die folgenden Attribute:

tools:node="merge"
Alle Attribute in diesem Tag und alle verschachtelten Elemente zusammenführen, wenn es keine Konflikte gibt, die die Heuristik für Zusammenführungskonflikte verwenden. Das ist das Standardverhalten für Elemente.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:node="merge">
</activity>

Ergebnis des zusammengeführten Manifests:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>
tools:node="mergeOnlyAttributes"
Führen Sie nur Attribute in diesem Tag zusammen, keine verschachtelten Elemente.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <data android:type="image/*" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:node="mergeOnlyAttributes">
</activity>

Ergebnis des zusammengeführten Manifests:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    android:windowSoftInputMode="stateUnchanged">
</activity>
tools:node="remove"
Entfernen Sie dieses Element aus dem zusammengeführten Manifest. Wird verwendet, wenn Sie in Ihrem zusammengeführten Manifest ein Element finden, das Sie nicht benötigen und das von einer Manifestdatei mit niedrigerer Priorität bereitgestellt wurde, die Sie nicht kontrollieren können (z. B. eine importierte Bibliothek).

Manifest mit niedriger Priorität:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="cow"
      android:value="@string/moo"/>
  <meta-data android:name="duck"
      android:value="@string/quack"/>
</activity-alias>

Manifest mit hoher Priorität:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="cow"
      tools:node="remove"/>
</activity-alias>

Ergebnis des zusammengeführten Manifests:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="duck"
      android:value="@string/quack"/>
</activity-alias>
tools:node="removeAll"
Ähnlich wie tools:node="remove", aber es werden alle Elemente entfernt, die diesem Elementtyp entsprechen (innerhalb desselben übergeordneten Elements).

Manifest mit niedriger Priorität:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="cow"
      android:value="@string/moo"/>
  <meta-data android:name="duck"
      android:value="@string/quack"/>
</activity-alias>

Manifest mit hoher Priorität:

<activity-alias android:name="com.example.alias">
  <meta-data tools:node="removeAll"/>
</activity-alias>

Ergebnis des zusammengeführten Manifests:

<activity-alias android:name="com.example.alias">
</activity-alias>
tools:node="replace"
Ersetzen Sie das Element mit niedrigerer Priorität vollständig. Das heißt, wenn es ein übereinstimmendes Element im Manifest mit niedrigerer Priorität gibt, wird es ignoriert und dieses Element wird genau so verwendet, wie es in diesem Manifest erscheint.

Manifest mit niedriger Priorität:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="cow"
      android:value="@string/moo"/>
  <meta-data android:name="duck"
      android:value="@string/quack"/>
</activity-alias>

Manifest mit hoher Priorität:

<activity-alias android:name="com.example.alias"
    tools:node="replace">
  <meta-data android:name="fox"
      android:value="@string/dingeringeding"/>
</activity-alias>

Ergebnis des zusammengeführten Manifests:

<activity-alias android:name="com.example.alias">
  <meta-data android:name="fox"
      android:value="@string/dingeringeding"/>
</activity-alias>
tools:node="strict"
Es wird immer dann ein Build-Fehler generiert, wenn dieses Element im Manifest mit niedrigerer Priorität nicht genau mit dem Element im Manifest mit höherer Priorität übereinstimmt (es sei denn, das Problem wird durch andere Markierungen für Zusammenführungsregeln behoben). Dadurch werden die Heuristiken für Zusammenführungskonflikte überschrieben. Wenn das Manifest mit niedrigerer Priorität beispielsweise ein zusätzliches Attribut enthält, schlägt der Build fehl. Beim Standardverhalten wird das zusätzliche Attribut dagegen dem zusammengeführten Manifest hinzugefügt.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:windowSoftInputMode="stateUnchanged">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:node="strict">
</activity>

Dies führt zu einem Fehler beim Zusammenführen des Manifests. Die beiden Manifestelemente dürfen sich im strikten Modus überhaupt nicht unterscheiden. Sie müssen andere Markierungen für Zusammenführungsregeln anwenden, um diese Unterschiede zu beheben. (Ohne tools:node="strict" können diese beiden Dateien ohne Fehler zusammengeführt werden, wie im Beispiel für tools:node="merge" gezeigt.)

Attributmarkierungen

Wenn Sie eine Zusammenführungsregel stattdessen nur auf bestimmte Attribute in einem Manifest-Tag anwenden möchten, verwenden Sie die folgenden Attribute. Jedes Attribut akzeptiert einen oder mehrere Attributnamen (einschließlich des Attribut-Namespace), die durch Kommas getrennt sind.

tools:remove="attr, ..."
Entfernt die angegebenen Attribute aus dem zusammengeführten Manifest. Wird verwendet, wenn die Manifestdatei mit niedrigerer Priorität diese Attribute enthält und Sie sicherstellen möchten, dass sie nicht in das zusammengeführte Manifest aufgenommen werden.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:windowSoftInputMode="stateUnchanged">

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:remove="android:windowSoftInputMode">

Ergebnis des zusammengeführten Manifests:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait">
tools:replace="attr, ..."
Ersetzt die angegebenen Attribute im Manifest mit niedrigerer Priorität durch die Attribute aus diesem Manifest. Mit anderen Worten: Behalte immer die Werte des Manifests mit der höheren Priorität bei.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:theme="@oldtheme"
    android:exported="false"
    android:windowSoftInputMode="stateUnchanged">

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:theme="@newtheme"
    android:exported="true"
    android:screenOrientation="portrait"
    tools:replace="android:theme,android:exported">

Ergebnis des zusammengeführten Manifests:

<activity android:name="com.example.ActivityOne"
    android:theme="@newtheme"
    android:exported="true"
    android:screenOrientation="portrait"
    android:windowSoftInputMode="stateUnchanged">
tools:strict="attr, ..."
Generiert einen Build-Fehler, wenn diese Attribute im Manifest mit niedrigerer Priorität nicht genau mit den Attributen im Manifest mit höherer Priorität übereinstimmen. Dies ist das Standardverhalten für alle Attribute, mit Ausnahme derer mit speziellem Verhalten, wie in den Heuristiken für Zusammenführungskonflikte beschrieben.

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="landscape">
</activity>

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:screenOrientation="portrait"
    tools:strict="android:screenOrientation">
</activity>

Dies führt zu einem Fehler beim Zusammenführen des Manifests. Sie müssen andere Zusammenführungsregel-Markierungen anwenden, um den Konflikt zu lösen. Dies ist das Standardverhalten. Das gleiche Ergebnis wird also erzielt, wenn Sie tools:strict="screenOrientation" explizit hinzufügen.

Sie können auch mehrere Markierungen auf ein Element anwenden, wie im folgenden Beispiel gezeigt:

Manifest mit niedriger Priorität:

<activity android:name="com.example.ActivityOne"
    android:theme="@oldtheme"
    android:exported="false"
    android:allowTaskReparenting="true"
    android:windowSoftInputMode="stateUnchanged">

Manifest mit hoher Priorität:

<activity android:name="com.example.ActivityOne"
    android:theme="@newtheme"
    android:exported="true"
    android:screenOrientation="portrait"
    tools:replace="android:theme,android:exported"
    tools:remove="android:windowSoftInputMode">

Ergebnis des zusammengeführten Manifests:

<activity android:name="com.example.ActivityOne"
    android:theme="@newtheme"
    android:exported="true"
    android:allowTaskReparenting="true"
    android:screenOrientation="portrait">

Markierungsauswahl

Wenn Sie die Zusammenführungsregel-Markierungen nur auf eine bestimmte importierte Bibliothek anwenden möchten, fügen Sie das Attribut tools:selector mit dem Namen des Bibliothekspakets hinzu.

Im folgenden Manifest wird die Zusammenführungsregel remove beispielsweise nur angewendet, wenn die Manifestdatei mit niedrigerer Priorität aus der Bibliothek com.example.lib1 stammt:

<permission android:name="permissionOne"
    tools:node="remove"
    tools:selector="com.example.lib1">

Wenn das Manifest mit niedrigerer Priorität aus einer anderen Quelle stammt, wird die Zusammenführungsregel remove ignoriert.

<uses-sdk> für importierte Bibliotheken überschreiben

Wenn Sie eine Bibliothek mit einem minSdk-Wert importieren, der höher als der der Hauptmanifestdatei ist, tritt standardmäßig ein Fehler auf und die Bibliothek kann nicht importiert werden.

Wenn Sie möchten, dass das Merger-Tool diesen Konflikt ignoriert und die Bibliothek importiert, während der niedrigere minSdk-Wert Ihrer App beibehalten wird, fügen Sie dem <uses-sdk>-Tag das Attribut overrideLibrary hinzu. Der Attributwert kann ein oder mehrere durch Kommas getrennte Bibliothekspaketnamen sein, die die Bibliotheken angeben, die das minSdk des Hauptmanifests überschreiben können.

Wenn im Hauptmanifest Ihrer App beispielsweise overrideLibrary so angewendet wird:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.app"
          xmlns:tools="http://schemas.android.com/tools">
  <uses-sdk tools:overrideLibrary="com.example.lib1, com.example.lib2"/>
...

Dann kann das folgende Manifest ohne Fehler bezüglich des <uses-sdk>-Tags zusammengeführt werden und das zusammengeführte Manifest behält minSdk="2" aus dem App-Manifest bei.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.lib1">
   <uses-sdk android:minSdk="4" />
...

Implizite Systemberechtigungen

Einige Android APIs, auf die Apps früher frei zugreifen konnten, wurden in neueren Android-Versionen durch Systemberechtigungen eingeschränkt.

Damit Apps, die Zugriff auf diese APIs erwarten, nicht fehlerhaft funktionieren, können Apps in den aktuellen Android-Versionen weiterhin ohne die Berechtigung auf diese APIs zugreifen, wenn die targetSdkVersion auf einen Wert festgelegt ist, der niedriger ist als die Version, in der die Einschränkung hinzugefügt wurde. Dadurch erhält die App eine implizite Berechtigung, die den Zugriff auf die APIs ermöglicht. Die zusammengeführten Manifeste, die unterschiedliche Werte für targetSdkVersion haben, können betroffen sein.

Wenn die Manifestdatei mit niedrigerer Priorität einen niedrigeren Wert für targetSdkVersion hat, der ihr eine implizite Berechtigung gewährt, und das Manifest mit höherer Priorität nicht dieselbe implizite Berechtigung hat (weil sein targetSdkVersion gleich oder höher als die Version ist, in der die Einschränkung hinzugefügt wurde), fügt das Merger-Tool dem zusammengeführten Manifest explizit die Systemberechtigung hinzu.

Wenn deine App beispielsweise targetSdkVersion auf 4 oder höher setzt und eine Bibliothek importiert, bei der targetSdkVersion auf 3 oder niedriger gesetzt ist, fügt das Merger-Tool dem zusammengeführten Manifest die Berechtigung WRITE_EXTERNAL_STORAGE hinzu.

In Tabelle 2 sind alle möglichen Berechtigungen aufgeführt, die Ihrem zusammengeführten Manifest hinzugefügt werden können:

Tabelle 2. Liste der Berechtigungen, die das Merger-Tool dem zusammengeführten Manifest hinzufügen kann

Manifestdeklarationen mit niedrigerer Priorität Dem zusammengeführten Manifest hinzugefügte Berechtigungen
targetSdkVersion ist 3 oder niedriger WRITE_EXTERNAL_STORAGE, READ_PHONE_STATE
targetSdkVersion ist 15 oder niedriger und verwendet READ_CONTACTS READ_CALL_LOG
targetSdkVersion ist 15 oder niedriger und verwendet WRITE_CONTACTS WRITE_CALL_LOG

Zusammengeführtes Manifest prüfen und Konflikte finden

Noch bevor Sie Ihre App erstellen, können Sie sich eine Vorschau des zusammengeführten Manifests ansehen. So rufen Sie eine Vorschau auf:

  1. Öffnen Sie in Android Studio die Datei AndroidManifest.xml.
  2. Klicken Sie unten im Editor auf den Tab Merged Manifest (Zusammengeführtes Manifest).

In der Ansicht „Zusammengeführtes Manifest“ werden links die Ergebnisse des zusammengeführten Manifests und rechts Informationen zu jeder zusammengeführten Manifestdatei angezeigt (siehe Abbildung 2).

Die Elemente, die aus Manifestdateien mit niedrigerer Priorität zusammengeführt wurden, sind links in verschiedenen Farben hervorgehoben. Der Schlüssel für jede Farbe wird unter Manifestquellen angegeben.

Ansicht „Zusammengeführtes Manifest“
Abbildung 2. Die Ansicht „Zusammengeführtes Manifest“.

Manifestdateien, die Teil des Builds waren, aber keine Elemente oder Attribute beigetragen haben, werden unter Andere Manifestdateien aufgeführt.

Wenn Sie Informationen zur Herkunft eines Elements sehen möchten, klicken Sie im linken Bereich darauf. Die Details werden dann unter Zusammenführungsprotokoll angezeigt.

Wenn Konflikte auftreten, werden sie unter Zusammenführungsfehler mit einer Empfehlung zur Lösung des Konflikts mithilfe von Zusammenführungsregel-Markierungen angezeigt.

Die Fehler werden auch im Fenster Ereignisprotokoll angezeigt. Wählen Sie View > Toolfenster > Ereignisprotokoll aus, um sie aufzurufen.

Ein vollständiges Protokoll des Zusammenführungs-Entscheidungsbaums finden Sie im Verzeichnis build/outputs/logs/ Ihres Moduls in der Protokolldatei manifest-merger-buildVariant-report.txt.

Richtlinien zusammenführen

Das Merger-Tool für Manifeste kann jedes XML-Element aus einer Manifestdatei logisch einem entsprechenden Element in einer anderen Datei zuordnen. Die Zusammenführung gleicht jedes Element mithilfe eines Abgleichschlüssels ab, entweder mit einem eindeutigen Attributwert (z. B. android:name) oder mit der natürlichen Eindeutigkeit des Tags selbst (z. B. kann es nur ein <supports-screen>-Element geben).

Wenn zwei Manifeste dasselbe XML-Element enthalten, werden die beiden Elemente mit einer der folgenden drei Zusammenführungsrichtlinien zusammengeführt:

Zusammenführen
Kombinieren Sie alle nicht in Konflikt stehenden Attribute im selben Tag und führen Sie untergeordnete Elemente gemäß der jeweiligen Zusammenführungsrichtlinie zusammen. Wenn Attribute miteinander in Konflikt stehen, führen Sie sie mit den Markierungen für Zusammenführungsregeln zusammen.
Nur untergeordnete Elemente zusammenführen
Die Attribute werden nicht kombiniert oder zusammengeführt. Es werden nur die Attribute aus der Manifestdatei mit der höchsten Priorität beibehalten. Untergeordnete Elemente werden gemäß ihrer Zusammenführungsrichtlinie zusammengeführt.
Notizen
Lassen Sie das Element unverändert und fügen Sie es dem gemeinsamen übergeordneten Element in der zusammengeführten Datei hinzu. Dies wird nur verwendet, wenn es akzeptabel ist, dass mehrere Deklarationen desselben Elements vorhanden sind.

In Tabelle 3 sind die einzelnen Elementtypen, die Art der verwendeten Zusammenführungsrichtlinie und der Schlüssel aufgeführt, mit dem eine Elementübereinstimmung zwischen zwei Manifesten ermittelt wird:

Tabelle 3 Richtlinien für das Zusammenführen von Manifestelementen und Abgleichschlüssel

Element Zusammenführungsrichtlinie Abgleichsschlüssel
<action> Zusammenführen android:name Attribut
<activity> Zusammenführen android:name Attribut
<application> Zusammenführen Es gibt nur einen pro <manifest>.
<category> Zusammenführen android:name Attribut
<data> Zusammenführen Es gibt nur einen pro <intent-filter>.
<grant-uri-permission> Zusammenführen Es gibt nur einen pro <provider>.
<instrumentation> Zusammenführen android:name Attribut
<intent-filter> Notizen Keine Übereinstimmung; mehrere Deklarationen innerhalb des übergeordneten Elements sind zulässig.
<manifest> Nur untergeordnete Elemente zusammenführen Es gibt nur eine pro Datei.
<meta-data> Zusammenführen android:name Attribut
<path-permission> Zusammenführen Es gibt nur einen pro <provider>.
<permission-group> Zusammenführen android:name Attribut
<permission> Zusammenführen android:name Attribut
<permission-tree> Zusammenführen android:name Attribut
<provider> Zusammenführen android:name Attribut
<receiver> Zusammenführen android:name Attribut
<screen> Zusammenführen android:screenSize Attribut
<service> Zusammenführen android:name Attribut
<supports-gl-texture> Zusammenführen android:name Attribut
<supports-screen> Zusammenführen Es gibt nur einen pro <manifest>.
<uses-configuration> Zusammenführen Es gibt nur einen pro <manifest>.
<uses-feature> Zusammenführen Attribut android:name (wenn nicht vorhanden, dann Attribut android:glEsVersion)
<uses-library> Zusammenführen android:name Attribut
<uses-permission> Zusammenführen android:name Attribut
<uses-sdk> Zusammenführen Es gibt nur einen pro <manifest>.
Benutzerdefinierte Elemente Zusammenführen Keine Übereinstimmung; diese sind dem Merger-Tool unbekannt und werden immer in das zusammengeführte Manifest aufgenommen.

Build-Variablen in Manifest einfügen

Wenn Sie Variablen, die in Ihrer build.gradle-Datei definiert sind, in Ihre AndroidManifest.xml-Datei einfügen müssen, können Sie dazu das Attribut manifestPlaceholders verwenden. Diese Property verwendet eine Zuordnung von Schlüssel/Wert-Paaren, wie hier gezeigt:

Groovy

android {
    defaultConfig {
        manifestPlaceholders = [hostName:"www.example.com"]
    }
    ...
}

Kotlin

android {
    defaultConfig {
        manifestPlaceholders["hostName"] = "www.example.com"
    }
    ...
}

Anschließend können Sie einen der Platzhalter als Attributwert in die Manifestdatei einfügen:

<intent-filter ... >
    <data android:scheme="https" android:host="${hostName}" ... />
    ...
</intent-filter>

Standardmäßig stellen die Build-Tools auch die Anwendungs-ID Ihrer App im Platzhalter ${applicationId} bereit. Der Wert entspricht immer der endgültigen Anwendungs-ID für den aktuellen Build, einschließlich Änderungen durch Build-Varianten. Das ist nützlich, wenn Sie einen eindeutigen Namespace für Kennungen wie eine Intent-Aktion verwenden möchten, auch zwischen Ihren Build-Varianten.

Wenn Ihre build.gradle-Datei beispielsweise so aussieht:

Groovy

android {
    defaultConfig {
        applicationId "com.example.myapp"
    }
    flavorDimensions "type"
    productFlavors {
        free {
            applicationIdSuffix ".free"
            dimension "type"
        }
        pro {
            applicationIdSuffix ".pro"
            dimension "type"
        }
    }
}

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"
    }
    flavorDimensions += "type"
    productFlavors {
        create("free") {
            applicationIdSuffix = ".free"
            dimension = "type"
        }
        create("pro") {
            applicationIdSuffix = ".pro"
            dimension = "type"
        }
    }
}

Anschließend können Sie die Anwendungs-ID so in Ihr Manifest einfügen:

<intent-filter ... >
    <action android:name="${applicationId}.TRANSMOGRIFY" />
    ...
</intent-filter>

Das Manifest-Ergebnis beim Erstellen der Produktvariante „free“ sieht so aus:

<intent-filter ... >
   <action android:name="com.example.myapp.free.TRANSMOGRIFY" />
    ...
</intent-filter>

Weitere Informationen finden Sie unter Anwendungs-ID festlegen.