How to Fix Google Play QUERY_ALL_PACKAGES Permission Rejection
Audit the shipped manifest, replace broad app visibility when possible, or prove why complete installed-app inventory is indispensable to the app's core purpose.
Direct answer
Start with the exact signed Android App Bundle and release track Google reviewed, not only your source manifest. If the app needs to discover a finite set of packages, intent handlers, or providers, remove QUERY_ALL_PACKAGES and use Android's targeted <queries> visibility instead. Keep the broad permission only when searching all installed apps is indispensable to a prominent core feature, the app would be broken or unusable without it, your use fits Google Play's permitted cases, and a narrower method is genuinely insufficient. After any manifest or behavior change, submit a new compliant build. Appeal only when the reviewed artifact and declaration already satisfy those conditions, or when Google evaluated the wrong artifact or release facts.
Match the wording in your rejection
“The permission is not directly related to the core purpose of the app”
Google expects the all-app inventory to be necessary for a main, prominently described user-facing function—not an optional convenience, analytics input, advertising signal, or background enhancement.
Google still detects QUERY_ALL_PACKAGES after you removed it
Inspect the merged manifest inside every relevant signed AAB. A library, product flavor, dynamic feature, manifest placeholder, or different active artifact can retain the permission even when the main source manifest no longer shows it.
Google says a less privacy-invasive method is available
Map every package lookup to a concrete need. A known package list, intent signature, provider authority, or another targeted <queries> entry usually requires selective visibility rather than access to the complete installed-app inventory.
The declaration does not match the app's behavior or listing
The Play Console declaration, store listing, shipped code, and actual data use must describe the same core functionality. A declaration cannot make an ineligible implementation acceptable.
What this rejection usually means
On Android 11 and later, package visibility filtering limits which installed apps your app can see. Android provides targeted visibility through <queries>; QUERY_ALL_PACKAGES is the exceptional path for rare cases that truly need visibility into any or all installed apps. Google Play treats the installed-app inventory as personal and sensitive data. Its policy therefore asks two separate questions: is broad visibility indispensable to the app's core purpose, and does the declared data use comply with the User Data and permissions rules? Passing a declaration form does not replace either test.
Likely rejection signals
- QUERY_ALL_PACKAGES appears in the merged manifest even though no first-party source file declares it
- The app calls broad inventory APIs such as getInstalledApplications or getInstalledPackages for a secondary feature
- The workflow only needs known package names, specific intent handlers, or provider authorities that <queries> can expose
- The app remains usable when full inventory access is unavailable, suggesting the permission is not core
- The Play listing does not prominently describe the feature that supposedly needs all-app visibility
- An SDK, library, product flavor, dynamic feature, internal build, or older active release contributes the permission
- Installed-app data is retained, transmitted, sold, or shared for an undeclared analytics, advertising, or profiling purpose
Recovery plan
- Preserve the enforcement notice and identify the package name, version code, app bundle, release track, review date, and exact declaration Google evaluated. Do not diagnose from a local debug build.
- Inspect the merged manifest from the exact signed AAB for each relevant active release. Record every occurrence of android.permission.QUERY_ALL_PACKAGES and identify which manifest, dependency, flavor, or dynamic feature contributed it.
- Build a package-visibility map. For every API call that checks or enumerates apps, record the user action, packages or intent types required, data returned, retention, sharing, failure behavior, and whether the app still works without complete inventory.
- Run the narrowest-visibility test. If the required targets are finite or discoverable by a specific intent or provider, replace the broad permission with <queries> entries for package names, intent signatures, or provider authorities. Rely on Android's automatically visible packages where applicable.
- Remove the permission at its real source. Update or remove the contributing SDK, build configuration, flavor manifest, or feature module rather than masking only the main manifest. Rebuild every affected variant and confirm the signed artifact no longer contains the permission.
- If broad visibility is truly indispensable, write a necessity case before resubmitting: the prominent core feature, why the app is broken or unusable without complete inventory, the exact permitted-use category, and why targeted queries cannot produce the required outcome.
- Align the public listing and Play Console declaration with the shipped behavior. Describe the core feature accurately, answer the Permissions Declaration Form with release-specific facts, and reconcile the privacy policy and Data safety answers with collection, transmission, retention, and sharing that actually occur.
- Test the release build on Android 11 or later from a clean install. Verify the core workflow with relevant apps installed and absent, permission-denial or restricted-visibility behavior, and that no hidden fallback still enumerates or transmits the full inventory.
- Choose the recovery route. Submit a new build when the manifest, SDK, code, UI, listing, or data handling changed. Clarify or appeal only when the exact reviewed release already complied or the enforcement relied on a provably incorrect artifact or fact.
Evidence to prepare
- Full policy notice with package name, version code, track, and review date
- Merged-manifest output for the exact signed AAB, including the dependency or module that contributed each permission
- Inventory of active releases and artifacts showing where QUERY_ALL_PACKAGES is present or absent
- API-to-purpose map for every package lookup, including the narrower alternative considered
- Before-and-after manifest diff and dependency report for a removal path
- For an eligible retained use, a short core-function necessity statement explaining why <queries> is insufficient
- Current Permissions Declaration, store-listing text, privacy policy, and applicable Data safety answers
- Clean-install recording and test notes from the exact release build on Android 11 or later
Appeal or fix first?
Appeal or request clarification when the exact reviewed artifact does not contain QUERY_ALL_PACKAGES, Google identified the wrong version or track, or the shipped app already has an eligible core use and your evidence proves why complete visibility is indispensable and targeted visibility is insufficient. Tie every statement to the reviewed version; do not use an appeal to promise a future fix.
Fix and submit a new build when the permission remains in any relevant shipped artifact, the feature can use targeted <queries>, the all-app inventory is optional, the use supports analytics or advertising, the declaration or listing does not match behavior, or sensitive-data handling is incomplete. Changing only the declaration is not a fix for an ineligible implementation.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the package, version code, release track, and exact enforcement wording.
- State whether QUERY_ALL_PACKAGES was removed or retained; name the signed artifact where this was verified.
- If removed, identify the targeted <queries> replacement and the manifest or dependency correction.
- If retained, describe the indispensable core function and why narrower visibility cannot support it.
- Attach only release-specific evidence and ask Google to review the corrected build or reconsider the documented artifact.
Frequently asked questions
What qualifies for QUERY_ALL_PACKAGES on Google Play?
Google requires broad app visibility to be necessary for an app's core, prominently described user-facing purpose and says the app must be broken or unusable without it. Its published permitted-use examples include device search, antivirus, file managers, and browsers, but each app must still show why a narrower method is insufficient and comply with User Data rules.
Why does Play Console still detect QUERY_ALL_PACKAGES after I removed it?
The permission may still be merged from a dependency, product flavor, dynamic feature, or a different active bundle. Inspect the merged manifest inside the exact signed AAB and reconcile every relevant release track rather than checking only AndroidManifest.xml in the main source set.
Can I use <queries> instead of QUERY_ALL_PACKAGES?
Usually yes when the app needs a known set of packages, intent handlers, or provider authorities. Android's <queries> element grants targeted visibility without exposing the complete installed-app inventory.
Does Google consider the installed-app list sensitive data?
Yes. Google's Play policy and Android documentation describe the inventory of installed apps as personal and sensitive user data, so collection and use must also satisfy applicable User Data, disclosure, consent, and data-handling requirements.
Should I appeal or upload a new build?
Upload a new build when you changed the manifest, dependencies, code, or behavior. Appeal only if the exact reviewed release already complied, the use is genuinely eligible with strong evidence, or Google relied on the wrong artifact or a specific incorrect fact.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Google Play — Use of the broad package (app) visibility permission. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.