Anforderungen an die Paketsichtbarkeit deklarieren

Bei der Entwicklung Ihrer App ist es wichtig, die anderen Apps auf dem Gerät zu berücksichtigen, mit denen Ihre App interagieren muss. Wenn Ihre App auf Android 11 (API‑Level 30) oder höher ausgerichtet ist, macht das System einige Apps automatisch für Ihre App sichtbar, filtert aber andere Apps standardmäßig heraus. In diesem Leitfaden wird beschrieben, wie Sie diese anderen Apps für Ihre App sichtbar machen.

Wenn Ihre App für Android 11 oder höher entwickelt wurde und mit anderen Apps als den automatisch sichtbaren interagieren muss, fügen Sie das Element <queries> in die Manifestdatei Ihrer App ein. Geben Sie im <queries>-Element die anderen Apps nach Paketname, nach Intent-Signatur oder nach Provider-Autorität an, wie in den folgenden Abschnitten beschrieben.

Spezifische Paketnamen

Wenn Sie wissen, mit welchen Apps Sie interagieren oder welche Apps Sie abfragen möchten, z. B. Apps, die in Ihre App eingebunden sind oder deren Dienste Sie verwenden, fügen Sie deren Paketnamen in eine Reihe von <package>-Elementen innerhalb des <queries>-Elements ein:

<manifest package="com.example.game">
    <queries>
        <package android:name="com.example.store" />
        <package android:name="com.example.services" />
    </queries>
    ...
</manifest>

Mit einer Host-App in einer Bibliothek kommunizieren

Wenn Sie eine Android-Bibliothek entwickeln, können Sie die Anforderungen an die Paketsichtbarkeit deklarieren, indem Sie ein <queries>-Element in die AAR-Manifestdatei einfügen. Dieses <queries>-Element hat dieselbe Funktion wie das Element, das Apps in ihren eigenen Manifesten deklarieren können.

Wenn Ihre Bibliothek die Kommunikation mit einer Host-App beinhaltet, z. B. die Verwendung eines gebundenen Dienstes, fügen Sie ein <package>-Element ein, das den Paketnamen der Host-App angibt:

<!-- Place inside the <queries> element. -->
<package android:name=PACKAGE_NAME />

Wenn Sie diese Deklaration einfügen, können Sie prüfen, ob die Host-App installiert ist, und mit ihr interagieren, z. B. durch Aufrufen von bindService(). Die aufrufende App, die Ihre Bibliothek verwendet, wird durch diese Interaktion automatisch für die Host-App sichtbar.

Pakete, die einer Intent-Filter-Signatur entsprechen

Ihre App muss möglicherweise eine Reihe von Apps abfragen oder mit ihnen interagieren, die einem bestimmten Zweck dienen. Sie kennen aber möglicherweise nicht die spezifischen Paketnamen, die Sie einfügen müssen. In diesem Fall können Sie Intent-Filtersignaturen in Ihrem <queries>-Element auflisten. Ihre App kann dann Apps mit übereinstimmenden <intent-filter>-Elementen erkennen.

Das folgende Codebeispiel zeigt ein <intent>-Element, mit dem die App andere installierte Apps sehen kann, die das Teilen von JPEG-Bildern unterstützen:

<manifest package="com.example.game">
    <queries>
        <intent>
            <action android:name="android.intent.action.SEND" />
            <data android:mimeType="image/jpeg" />
        </intent>
    </queries>
    ...
</manifest>

Das <intent>-Element unterliegt einigen Einschränkungen:

  • Sie müssen genau ein <action>-Element angeben.
  • Sie können die Attribute path, pathPrefix, pathPattern oder port nicht in einem <data>-Element verwenden. Das System verhält sich so, als hätten Sie den Wert jedes Attributs auf das generische Platzhalterzeichen (*) gesetzt.
  • Sie können das Attribut mimeGroup eines <data>-Elements nicht verwenden.
  • In den <data>-Elementen eines einzelnen <intent>-Elements können Sie jedes der folgenden Attribute höchstens einmal verwenden:

    • mimeType
    • scheme
    • host

    Sie können diese Attribute auf mehrere <data>-Elemente verteilen oder in einem einzelnen <data>-Element verwenden.

Das Element <intent> unterstützt den allgemeinen Platzhalter (*) als Wert für einige Attribute:

  • Das Attribut name des Elements <action>.
  • Der Untertyp des Attributs mimeType eines <data>-Elements (image/*).
  • Der Typ und Untertyp des Attributs mimeType eines <data>-Elements (*/*).
  • Das scheme-Attribut eines <data>-Elements.
  • Das host-Attribut eines <data>-Elements.

Sofern in der vorherigen Liste nicht anders angegeben, unterstützt das System keine Kombination aus Text und Platzhalterzeichen wie prefix*.

Pakete, die eine bestimmte Autorität verwenden

Wenn Sie einen Contentanbieter abfragen müssen, die spezifischen Paketnamen aber nicht kennen, können Sie die Anbieterautorität in einem <provider>-Element deklarieren, wie im folgenden Snippet gezeigt:

<manifest package="com.example.suite.enterprise">
    <queries>
        <provider android:authorities="com.example.settings.files" />
    </queries>
    ...
</manifest>

Sie können Anbieter-Authorities in einem einzelnen <queries>-Element deklarieren. Im <queries>-Element können Sie ein oder mehrere <provider>-Elemente deklarieren. Ein <provider>-Element kann eine einzelne Anbieterautorität oder eine durch Semikolons getrennte Liste von Anbieterautoritäten enthalten.

Alle Apps (nicht empfohlen)

In seltenen Fällen muss Ihre App möglicherweise alle auf einem Gerät installierten Apps abfragen oder mit ihnen interagieren, unabhängig davon, welche Komponenten sie enthalten. Damit Ihre App alle anderen installierten Apps sehen kann, stellt das System die Berechtigung QUERY_ALL_PACKAGES zur Verfügung.

Hier einige Beispiele für Anwendungsfälle, in denen die Berechtigung QUERY_ALL_PACKAGES angemessen ist:

  • Bedienungshilfen-Apps
  • Browser
  • Apps zur Geräteverwaltung
  • Sicherheits-Apps
  • Antiviren-Apps

In der Regel lassen sich die Anwendungsfälle Ihrer App jedoch erfüllen, indem Sie mit den Apps interagieren, die automatisch sichtbar sind, und die anderen Apps, auf die Ihre App zugreifen muss, in Ihrer Manifestdatei deklarieren. Aus Datenschutzgründen sollte Ihre App nur die Mindestmenge an Paketinformationen anfordern, die für ihre Funktion erforderlich ist.

Diese Richtlinienaktualisierung von Google Play enthält Richtlinien für Apps, die die Berechtigung QUERY_ALL_PACKAGES benötigen.