Google Play reads your manifest, not your code path

Most permission advice is about runtime: request it when you need it, explain why, handle the refusal. That advice is correct and it is not what this page is about.

Google Play's restricted-permission rules are written against what your app declares, and the declaration Google reads is the merged manifest of the artefact you uploaded — not the manifest in your source tree, and not the set of APIs your code actually calls.

Read 3 September 2026, from Google's policy pages rather than from a summary of them.

The sentence that makes it a build question

Under the SMS and Call Log restrictions, after the table of permission groups:

"Apps lacking default SMS, Phone, or Assistant handler capability may not declare use of the above permissions in the manifest. This includes placeholder text in the manifest."

Read that twice, because the second sentence is doing something unusual. It is not enough to never call the API. It is not enough to leave the permission unrequested at runtime. The line may not be present, and Google says explicitly that a line left in as a placeholder is still a line.

A runtime rule can be satisfied by a code path that is never taken. A manifest rule cannot be satisfied by anything except the absence of the entry.

What the two groups actually contain

Google states them as a table of restricted permissions against the requirement each one carries, and its lists are introduced with "for example" — they are illustrative rather than closed:

And the condition is continuous rather than one-off: "apps must be actively registered as the default SMS, Phone, or Assistant handler before prompting users to accept any of the above permissions and must immediately stop using the permission when they’re no longer the default handler."

QUERY_ALL_PACKAGES, and the two named tiers

Package visibility is its own policy section on the same page, and Google splits it into two levels it names.

Broad visibility, in Google's words: “Broad visibility is the capability of an app to have extensive (or “broad”) visibility of the installed apps (“packages”) on a device.” The restriction attaches to a target level, exactly as the platform behaviour does: "For apps targeting API level 30 or later, broad visibility to installed apps via the QUERY_ALL_PACKAGES permission is restricted to specific use cases where awareness of and/or interoperability with any and all apps on the device are required for the app to function."

Then the test a reviewer applies, which is a comparative one rather than a threshold: "You may not use QUERY_ALL_PACKAGES if your app can operate with a more targeted scoped package visibility declaration (for example, querying and interacting with specific packages instead of requesting broad visibility)."

Two more clauses are worth carrying because they close the obvious workarounds:

• Approximating it by other means is covered too: "Use of alternative methods to approximate the broad visibility level associated with QUERY_ALL_PACKAGES permission are also restricted to user-facing core app functionality and interoperability with any apps discovered via this method."
• And on what the resulting data may be used for: "Under no circumstances can data from the installed app inventory be sold or shared for advertising or analytics monetization."

This is the Play-policy half of a two-part story. The platform half — that an app targeting API level 30 or higher gets a filtered view by default whether or not it asked for one — is in the expiry list, and it is why a package-name check written before that boundary returns a clean answer rather than an error.

The eight that are barred outright

For one class of app there is no declaration to make, because the permissions are prohibited. Google's scope sentence is precise and it is worth quoting rather than paraphrasing, because "fintech" is much broader than what it binds:

"Personal loan apps, apps with the primary purpose of facilitating access to personal loans (for example, lead generators or facilitators) or lines of credit, accessory loan or credit apps (loan calculators, loan guides, etc.), and Earned Wage Access (EWA) apps are prohibited from accessing sensitive data, such as photos and contacts."

Then: "The following permissions are prohibited" — READ_EXTERNAL_STORAGE, READ_MEDIA_IMAGES, READ_CONTACTS, ACCESS_FINE_LOCATION, READ_PHONE_NUMBERS, READ_MEDIA_VIDEO, QUERY_ALL_PACKAGES, WRITE_EXTERNAL_STORAGE.

Eight constants, and note which ones they are. READ_MEDIA_IMAGES and READ_MEDIA_VIDEO are the modern split of the old external-storage read, so both the legacy and current spellings are listed — an app that migrated to the new constants did not leave the list. QUERY_ALL_PACKAGES appears here as well as in its own policy, which means a lending app has two separate reasons to care about the same line.

Why this is a question about your build graph

Every rule above is applied to a document that is assembled rather than written. The merged manifest contains what your code declares plus what every library declares, and a permission contributed by a transitive dependency is indistinguishable, to Google, from one you typed.

So the answerable version of "do we have a permissions problem" is:

1. Read the merged manifest of the artefact you actually ship — not AndroidManifest.xml in the app module.
2. Attribute every <uses-permission> line to whatever contributed it. The build tooling can tell you; nobody usually asks it.
3. For each line that appears in a policy above, establish which of three things is true: your app is the default handler and the requirement is met; the app has a documented core-functionality case; or the line came in with a dependency and nothing in your product needs it.

That third case is the common one and it is the reason this reads as a build problem rather than a policy problem. It is also two of the questions on the build handover sheet — the third-party SDK inventory, and which of them contribute manifest entries — because they are the questions a tester needs answered for exactly the same reason a reviewer does.

What this page does not do

It does not tell you whether your case will be accepted. Declaration forms are submitted in Play Console and Google adjudicates them; no third party reviews one, and nobody outside Google can tell you what the outcome will be.

Nor does reading a manifest discharge a policy obligation. What it does is establish what your artefact declares, which is the thing every rule above is written against — and which, on most Android codebases of any age, nobody currently has written down.