Start with the integration you need
If the feature shares a document, opens a URL or launches a known partner app, investigate the narrow intent or package relationship first. Building a complete inventory of installed apps is usually unnecessary for that interaction.
The package-visibility documentation describes scoped <queries> declarations and automatically visible relationships. Use those rules rather than treating a filtered query result as a broken package manager.
Declare a narrow query
An illustrative manifest fragment for a known partner package is:
<queries>
<package android:name="com.example.partner" />
</queries>
The fragment belongs under <manifest>. Use the real package only when it corresponds to a necessary integration. Intent-based queries can be appropriate for broader capability matching, but should still reflect the feature.
Distinguish discovery from launch
A package query returning no result does not always establish that a user cannot complete an action through the platform. Follow the documented intent-handling pattern, resolve where appropriate and handle ActivityNotFoundException or an unavailable target gracefully.
Do not use a visibility workaround to infer sensitive information about installed applications unrelated to the feature.
Treat broad visibility as exceptional
QUERY_ALL_PACKAGES has Google Play policy restrictions. A developer convenience such as populating a generic installed-app dropdown is not automatically an eligible core use case.
Document why scoped queries are insufficient and review current policy before shipping a broad declaration. A successful local test does not establish store approval.
Verify the merged manifest
A dependency can introduce visibility declarations. APKLint's Manifest Checker can help inventory <queries> and broad package access, but it cannot decide whether the feature is proportionate or policy-eligible. Test intended integrations on clean devices and provide a useful fallback when no compatible app is available.
Scope discovery to a real partner-app feature
Suppose an invoice app offers an action that hands a document to one known partner application. Identify the package or intent capability needed by that integration and declare the appropriate narrow visibility relationship. Do not enumerate every installed application just to decide whether the partner action can be offered.
The package visibility declaration guide describes package, intent and provider query forms. The example above uses a placeholder package name; replace it only with a real integration that the app needs. Preserve the queries element's manifest placement and inspect the merged output for declarations introduced by libraries.
Test discovery and the eventual handoff independently
Test with the partner installed, absent and unavailable for the current device profile. Record the query result separately from the outcome of the actual handoff. A package may be visible without supporting the expected action, and a filtered query does not mean every platform-mediated action is impossible.
When the user chooses to share the invoice, pass a narrowly granted content URI through the supported intent flow. Package visibility does not itself grant the receiving app permission to read your private file. Check both the launch and the recipient's ability to open the intended synthetic document.
Then use a second document with distinct contents and repeat the handoff. Confirm that stale pending data from the first operation is not reused. Test an unavailable handler and show a useful fallback, such as saving the file or choosing another supported recipient, without crashing the application.
A dependency update can add queries or broad package visibility to the merged manifest even when your own source manifest is unchanged. Compare the final declarations between releases and trace unexpected additions to their owner. Configure or update the dependency where possible, then test its actual feature before removing a declaration blindly.
Review QUERY_ALL_PACKAGES eligibility separately if a core use case truly requires broad discovery. A local query succeeding does not establish distribution approval. Keep the access rationale tied to necessary product behavior and avoid collecting an installed-app inventory for an unrelated convenience feature. The completed integration should demonstrate a bounded discovery requirement, a correct handoff and a clear unavailable-app state.
Sources and further reading
- Android Developers: Package visibility
- Google Play: Permissions and APIs that access sensitive information
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
