Android 12 Developer Preview is here! Try it out, and give us your feedback!

Declaring package visibility needs

As you create your app, it's important to consider the set of other installed apps on the device that your app intends to access. If your app targets Android 11 (API level 30) or higher, the system makes some apps visible to your app automatically, but it filters out other apps by default. This guide describes how to make these other apps visible to your app.

If your app targets Android 11 or higher and needs to interact with apps other than the ones that are visible automatically, add the <queries> element in your app's manifest file. Within the <queries> element, specify the other apps by package name, by intent signature, or by provider authority, as described in the following sections.

Specific package names

If you know the specific set of apps that you want to query or interact with, such as apps that integrate with your app, or apps whose services you use, include their package names in a set of <package> elements inside the <queries> element:

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

Communicate with a host app in a library

If you develop an Android library, you can declare your package visibility needs by adding a <queries> element in your AAR manifest file. This <queries> element has the same functionality as the element that apps can declare in their own manifests.

If your library involves communication with a "host" app, such as using a bound service, include a <package> element that specifies the host app's package name:

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

By including this declaration, you can check if the host app is installed and interact with it, such as by calling bindService(). The calling app that uses your library automatically becomes visible to the host app as a result of this interaction.

Packages that match an intent filter signature

Your app might need to query or interact with a set of apps that serve a particular purpose, but you might not know the specific package names to include. In this situation, you can list intent filter signatures in your <queries> element. Your app can then discover apps that have matching <intent-filter> elements.

The following example allows your app to see installed apps that support JPEG image sharing:

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

The <intent> element has a few restrictions:

  • You must include exactly one <action> element.
  • You cannot use the path, pathPrefix, pathPattern, or port attributes in a <data> element. The system behaves as if you set each attribute's value to the generic wildcard character (*).
  • You cannot use the mimeGroup attribute of a <data> element.
  • Within the <data> elements of a single <intent> element, you can use each of the following attributes at most once:

    • mimeType
    • scheme
    • host

    You can distribute these attributes across multiple <data> elements or use them in a single <data> element.

The <intent> element supports the generic wildcard character (*) as the value for a few attributes:

  • The name attribute of the <action> element.
  • The subtype of the mimeType attribute of a <data> element (image/*).
  • The type and subtype of the mimeType attribute of a <data> element (*/*).
  • The scheme attribute of a <data> element.
  • The host attribute of a <data> element.

Unless otherwise specified in the previous list, the system doesn't support a mix of text and wildcard characters, such as prefix*.

Packages that use a specific authority

In cases where you need to query a content provider but don't know the specific package names, you can declare that provider authority in a <provider> element, as shown in the following snippet:

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

You can declare all provider authorities in a single <queries> element. The format depends on the number of provider authorities that you declare:

Single <provider> element
In the element, declare a semicolon-delimited list of authorities.
Multiple <provider> elements
In each element, declare either a single authority or a semicolon-delimited list of authorities.

All apps (not recommended)

In rare cases, your app might need to query or interact with all installed apps on a device, independent of the components they contain. To allow your app to see all other installed apps, the system provides the QUERY_ALL_PACKAGES permission.

The following list gives some examples of use cases where the QUERY_ALL_PACKAGES permission is appropriate to include:

  • Launcher apps
  • Accessibility apps
  • Browsers
  • Peer-to-peer (P2P) sharing apps
  • Device management apps
  • Security apps

In the vast majority of cases, however, it's possible to fulfill your app's use cases by interacting with the set of apps that are visible automatically and by declaring the other apps that your app needs to access in your manifest file. To respect user privacy, your app should request the smallest amount of package visibility necessary in order for your app to work.

In an upcoming policy update, look for Google Play to provide guidelines for apps that need the QUERY_ALL_PACKAGES permission.