Déclarer les besoins en termes de visibilité des packages

Lorsque vous créez votre application, il est important de tenir compte des autres applications installées sur l'appareil avec lesquelles elle doit interagir. Si votre application cible Android 11 (niveau d'API 30) ou version ultérieure, le système rend automatiquement certaines applications visibles par votre application, mais filtre les autres par défaut. Ce guide explique comment rendre ces autres applications visibles pour votre application.

Si votre application cible Android 11 ou version ultérieure et doit interagir avec des applications autres que celles qui sont visibles automatiquement, ajoutez l'élément <queries> dans le fichier manifeste de votre application. Dans l'élément <queries>, spécifiez les autres applications par nom de package, par signature d'intent ou par autorité de fournisseur, tel que décrit dans les sections suivantes.

Noms de packages spécifiques

Si vous connaissez les applications spécifiques que vous souhaitez interroger ou avec lesquelles vous souhaitez interagir, par exemple les applications qui s'intègrent à votre application ou celles dont vous utilisez les services, incluez les noms de leurs packages dans un ensemble d'éléments <package> à l'intérieur de l'élément <queries> :

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

Communiquer avec une application hôte dans une bibliothèque

Si vous développez une bibliothèque Android, vous pouvez afficher les exigences de visibilité de vos packages en ajoutant un élément <queries> à votre fichier manifeste AAR. Cet élément <queries> a la même fonctionnalité que l'élément que les applications peuvent déclarer dans leurs propres fichiers manifestes.

Si votre bibliothèque implique une communication avec une application hôte, par exemple en utilisant un service lié, incluez un élément <package> qui précise le nom de package de l'application hôte :

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

En incluant cette déclaration, vous pouvez vérifier si l'application hôte est installée et interagir avec elle, en appelant par exemple bindService(). L'application appelante qui utilise votre bibliothèque devient automatiquement visible par l'application hôte à la suite de cette interaction.

Packages qui correspondent à une signature de filtre d'intent

Votre application peut avoir besoin d'interroger ou d'interagir avec un ensemble d'applications répondant à un objectif particulier, mais vous pouvez ne pas connaître les noms de package spécifiques à inclure. Dans ce cas, vous pouvez lister les signatures de filtre d'intent dans votre élément <queries>. Votre application peut alors détecter les applications qui correspondent aux éléments <intent-filter>.

L'exemple de code suivant montre un élément <intent> qui permet à l'application de voir d'autres applications installées compatibles avec le partage d'images JPEG :

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

L'élément <intent> comporte quelques restrictions :

• Vous devez inclure un seul élément <action> ;
• Vous ne pouvez pas utiliser les attributs path, pathPrefix, pathPattern ou port dans un élément <data>. Le système se comporte comme si vous définissiez la valeur de chaque attribut selon le caractère générique (*) ;
• Vous ne pouvez pas utiliser l'attribut mimeGroup d'un élément <data>.

• Dans les éléments <data> d'un seul élément <intent>, vous pouvez utiliser chacun des attributs suivants une fois maximum :

  • mimeType
  • scheme
  • host

  Vous pouvez répartir ces attributs sur plusieurs éléments <data> ou les utiliser dans un seul élément <data>.

L'élément <intent> accepte le caractère générique (*) comme valeur pour quelques attributs :

• Attribut name de l'élément <action>.
• Sous-type de l'attribut mimeType d'un élément <data> (image/*).
• Type et sous-type de l'attribut mimeType d'un élément <data> (*/*).
• Attribut scheme d'un élément <data>.
• Attribut host d'un élément <data>.

Sauf indication contraire dans la liste précédente, le système n'accepte pas les combinaisons de texte et de caractères génériques comme prefix*.

Packages utilisant une autorité spécifique

Si vous devez interroger un fournisseur de contenu, mais que vous ne connaissez pas les noms des packages spécifiques, vous pouvez déclarer l'autorité de fournisseur dans un élément <provider>, comme indiqué dans l'extrait de code suivant :

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

Vous pouvez déclarer des autorités du fournisseur dans un seul élément <queries>. Dans l'élément <queries>, vous pouvez déclarer un ou plusieurs éléments <provider>. Un élément <provider> peut inclure une seule autorité de fournisseur ou une liste d'autorités de fournisseur séparées par un point-virgule.

Toutes les applications (non recommandé)

Dans de rares cas, votre application peut avoir besoin d'interroger ou d'interagir avec toutes les applications installées sur un appareil, indépendamment des composants qu'elles contiennent. Pour que votre application puisse voir toutes les autres applications installées, le système fournit l'autorisation QUERY_ALL_PACKAGES.

Voici quelques exemples d'utilisations dans lesquelles l'autorisation QUERY_ALL_PACKAGES est appropriée :

• Applications d'accessibilité
• Navigateurs
• Applications de gestion de l'appareil
• Applications de sécurité
• Applications antivirus

Cependant, il est généralement possible de répondre aux cas d'utilisation de votre application en interagissant avec l'ensemble d'applications visibles automatiquement et en déclarant les autres applications auxquelles votre application doit accéder dans votre fichier manifeste. Pour respecter la confidentialité des utilisateurs, votre application doit demander le moins de visibilité possible sur les packages pour qu'elle fonctionne.

Cette mise à jour des règles de Google Play fournit des consignes pour les applications qui requièrent l'autorisation QUERY_ALL_PACKAGES.