Android Intent Filter Package Visibility with Element

Question

Implicit Intent Resolution and Package Visibility

Android 12 (API 31) introduced stricter package visibility requirements to enhance user privacy. Applications targeting this API level or higher must declare the packages, intent filters, or providers they intend to interact with using the <queries> element in the AndroidManifest.xml.

When using implicit Intents to communicate between two separate applications, the sending app must have the appropriate visibility permissions to detect if a matching receiver exists. Without this declaration, methods like PackageManager.resolveActivity()` may return null even if a compatible application is installed on the device.

There is uncertainty regarding the most efficient way to declare visibility when the target application is not known by package name but is identified by a specific custom action string.

Does declaring a specific <intent-filter> within the <queries> block provide the same visibility as declaring a specific package name?
What is the impact on system performance when using broad intent-filter queries versus explicit package declarations?

Wasi · Answer

Answer Yes. Declaring an inside the block gives the sending app the same visibility as an explicit entry for the purpose of resolving implicit intents. Confirmed facts On devices running API 31 (Android 12) or higher, the element is enforced; on lower API levels it is ignored. An entry makes the package manager treat any installed app whose manifest contains a matching as visible to query APIs such as PackageManager.resolveActivity(). An explicit entry results in an O(1) lookup in the package manager’s package list. An intent‑filter entry requires the system to scan all installed apps and evaluate their intent filters, which is O(N) where N is the number of packages. In practice the extra scan adds only a few milliseconds on typical devices (<200 apps) but can become noticeable on low‑end devices or when many apps declare similar generic filters. Likely explanation The visibility mechanism builds a temporary list of apps that satisfy the constraints. When the constraint is a package name, the list is assembled by a direct map lookup. When the constraint is an intent filter, the package manager must iterate over every installed package, parse its manifest intent‑filters, and compare them against the declared filter. This extra work explains the performance difference while preserving functional equivalence. Steps to verify Create a sender app targeting API 31+ with a block that contains only an for a custom action, e.g. . Create a receiver app that exports an activity with an matching that action. Install both apps on a device or emulator. At runtime, call PackageManager.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY) where the intent specifies the custom action. Confirm that a non‑null ResolveInfo is returned when the receiver is present and null after the receiver is uninstalled. Repeat the test with an explicit entry in and verify the behavior is identical. Optional: measure the duration of the resolveActivity call with Debug.startMethodTracing() or Systrace to compare explicit‑package vs intent‑filter queries on a device with a known number of installed apps. When to ask for more detail If you are targeting low‑end hardware or expect the device to have >500 installed apps, let me know the approximate app count so I can advise whether the scanning overhead of an intent‑filter query is acceptable for your use case.

Android Intent Filter Package Visibility with <queries> Element

Implicit Intent Resolution and Package Visibility

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify

When to ask for more detail

Your perspective belongs here.

0 question comments