Anforderungen an die Paketsichtbarkeit deklarieren

Wenn Sie Ihre App erstellen, sollten Sie die anderen Apps auf dem Gerät 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 standardmäßig andere Apps heraus. In diesem Leitfaden wird beschrieben, wie Sie diese anderen Apps für Ihre App sichtbar machen.

Wenn Ihre App auf Android 11 oder höher ausgerichtet ist und mit anderen Apps als den automatisch sichtbaren interagieren muss, fügen Sie das Element <queries> in die Manifestdatei Ihrer App ein. Geben Sie die anderen Apps im Element <queries> anhand des Paketnamens, anhand der Intent-Signatur oder anhand der Anbieterautorität an, wie in den folgenden Abschnitten beschrieben.

Bestimmte Paketnamen

Wenn Sie die Apps kennen, die Sie abfragen oder mit denen Sie interagieren möchten, z. B. Apps, die in Ihre App eingebunden sind, oder Apps, deren Dienste Sie verwenden, fügen Sie die 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 Sichtbarkeit des Pakets deklarieren, indem Sie ein <queries>-Element in die Manifestdatei der AAR einfügen. Dieses <queries>-Element hat dieselbe Funktionalität wie das Element, das Apps in ihren eigenen Manifesten deklarieren können.

Wenn Ihre Bibliothek die Kommunikation mit einer Host-App umfasst, z. B. über einen gebundenen Dienst, fügen Sie ein <package>-Element hinzu, 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 mit einer Intent-Filtersignatur übereinstimmen

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

Das folgende Codebeispiel zeigt ein <intent>-Element, mit dem die App andere installierte Apps sehen kann, die die Freigabe 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 hat einige Einschränkungen:

• Sie müssen genau ein <action>-Element angeben.
• Die Attribute path, pathPrefix, pathPattern oder port dürfen nicht in einem <data>-Element verwendet werden. Das System verhält sich so, als hätten Sie für jedes Attribut den generischen Platzhalter (*) festgelegt.
• Sie können das Attribut mimeGroup eines <data>-Elements nicht verwenden.

• Innerhalb der <data>-Elemente 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 einzigen <data>-Element verwenden.

Das Element <intent> unterstützt das generische Platzhalterzeichen (*) als Wert für einige Attribute:

• Das Attribut name des Elements <action>.
• Der Untertyp des mimeType-Attributs eines <data>-Elements (image/*).
• Der Typ und Untertyp des mimeType-Attributs 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, für die eine bestimmte Zertifizierungsstelle verwendet wird

Wenn du einen Inhaltsanbieter abfragen möchtest, aber die spezifischen Paketnamen nicht kennst, kannst du die Anbieterautorität in einem <provider>-Element angeben, wie im folgenden Snippet gezeigt:

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

Sie können Anbieterbehörden in einem einzigen <queries>-Element deklarieren. Innerhalb des Elements <queries> können Sie ein oder mehrere <provider>-Elemente deklarieren. Ein <provider>-Element kann eine einzelne Anbieterautorität oder eine durch Semikolons getrennte Liste von Anbieterbehörden 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 von den darin enthaltenen Komponenten. Damit Ihre App alle anderen installierten Apps sehen kann, stellt das System die Berechtigung QUERY_ALL_PACKAGES bereit.

Beispiele für Anwendungsfälle, in denen die Berechtigung QUERY_ALL_PACKAGES angebracht ist:

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

In der Regel ist es jedoch möglich, die Anwendungsfälle Ihrer App zu 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 minimale Sichtbarkeit des Pakets anfordern, die für die Funktion Ihrer App erforderlich ist.

Diese Richtlinienaktualisierung von Google Play enthält Richtlinien für Apps, für die die Berechtigung QUERY_ALL_PACKAGES erforderlich ist.