On this page (9 sections)
The rule everything else follows from
Google Play, Permissions and APIs that Access Sensitive Information
“To promote user trust, Google Play mandates that requesting permissions and APIs that access sensitive user data must be necessary for the app's core functionalities as promoted in your Google Play listing and limited to user consented purposes.”
Two consequences developers underestimate. First, “core functionality promoted in your listing” means the listing has to describe the feature — an undocumented convenience feature will not justify a restricted permission. Second, the merged manifest is what counts: an SDK can add a permission you never wrote.
Start by finding what you actually ship
- Build the release bundle and open the merged manifest (Android Studio → Build → Analyze APK, or
app/build/outputs/logs/manifest-merger-release-report.txt) — it shows every permission and which dependency introduced it. - Map each permission to a feature a user can reach, and to a sentence in your store listing.
- Anything you cannot map is a removal candidate. Removing a permission is almost always cheaper than defending it.
The permissions Google restricts, and the narrower alternative
| Permission / API | Google’s position | Narrower alternative to try first |
|---|---|---|
| Photos and video (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO) | Apps targeting Android 13+ may only request them if the system pickers are not sufficient | Android photo picker; or the “selected photos” partial access flow |
| SMS and Call Log (READ_SMS, RECEIVE_SMS, READ_CALL_LOG) | Only for apps whose core function needs them; Permissions Declaration Form required | SMS Retriever API for OTP; Digital Credentials API for verification |
| Location, including ACCESS_BACKGROUND_LOCATION | Background access needs a declaration and a user-visible feature that requires it while the app is closed | Foreground-only access; the system location button as minimum scope for precise location |
| All files access (MANAGE_EXTERNAL_STORAGE) | Only where broad storage access is critical; must pass an access review before publishing | Scoped storage, MediaStore, the Storage Access Framework |
| Package visibility (QUERY_ALL_PACKAGES) | “You may not use QUERY_ALL_PACKAGES if your app can operate with a more targeted scoped package visibility declaration” | A <queries> element listing the packages or intents you need |
| REQUEST_INSTALL_PACKAGES | May not be used for self-updates, modification, or bundling other APKs | Play-delivered updates; remove the flow entirely |
| Accessibility API (BIND_ACCESSIBILITY_SERVICE) | Apps not eligible for IsAccessibilityTool must meet prominent disclosure and consent requirements and complete a Play Console declaration | Purpose-built APIs (notification listener, autofill) where they fit |
| Exact alarms (SCHEDULE_EXACT_ALARM / USE_EXACT_ALARM) | Only where core functionality genuinely needs exact timing — alarms, timers, calendars | WorkManager or inexact alarms |
| Full-screen intents (USE_FULL_SCREEN_INTENT) | Auto-granted only for alarm-like and call-like core functionality | Standard high-priority notifications |
| Body sensors and Health Connect | Restricted, with their own declaration and data-handling requirements | Aggregated data, or the specific Health Connect permissions you need |
| VpnService | Cannot be used to redirect or manipulate other apps’ traffic for monetization | Redesign; there is no scoped alternative |
| Advertising ID (AD_ID) | Declared in the manifest and in the Data safety form; removing it changes what you may declare | Remove the permission if no SDK needs it |
When the Permissions Declaration Form is required
For SMS/Call Log, background location, all files access, package visibility, install packages and accessibility use, Play Console asks you to declare the use before the release is accepted. What gets a declaration approved is specificity:
- Name the exact user-visible feature and where it appears in the app.
- Explain why the narrower alternative does not work — reviewers know the alternatives exist.
- Where a video is requested, record the real flow on a device: the feature, the permission prompt, and what changes after the user grants it.
- Keep the listing consistent: if the declaration says the feature is core, the listing should mention it.
- Handle refusal gracefully — apps must make a reasonable effort to accommodate users who do not grant a sensitive permission.
Foreground services are a declaration too
Apps targeting Android 14 and above that use foreground services must declare each service type in the manifest (android:foregroundServiceType) with the matching permission, and complete the foreground service declaration in Play Console: a description of the functionality using each type, what happens if the task is deferred or interrupted, and a link to a video demonstrating the feature. Calling startForeground() without a declared type throws MissingForegroundServiceTypeException at runtime.
Changes dated 27 January 2027
Google's Policy Deadlines page lists four changes that affect permissions, all effective 27 January 2027:
- Contacts: “Apps that don't need broad access must use the Android Contact Picker, a more secure, easy-to-integrate alternative that minimizes data collection and improves user safety.”
- Location: “We're introducing the location button as the recommended minimum scope for precise location in line with our user data and sensitive permissions requirements.”
- Call Log: “Our SMS and Call Log Permissions policy will no longer permit account verification via phone call as a use case for the READ_CALL_LOG permission.” Google points to the Digital Credentials API or the SMS Retriever API instead.
- Foreground services: “We're removing geofencing as an approved foreground services use case. Developers can instead use the Geofence API for this use case.”
If your app verifies accounts by phone call, reads the full contact list, or runs a geofencing foreground service, that is a planned code change, not a policy argument. The dated list of everything else is on app publishing deadlines.
Declare it, scope it, or remove it?
| Situation | Right response |
|---|---|
| The feature is core, promoted in the listing, and no narrower API exists | Declare it, with a precise description and a demonstration video |
| A system picker, scoped query or foreground-only variant does the job | Scope it — re-implement with the narrower API and drop the permission |
| The permission came from an SDK you no longer need | Remove or reconfigure the SDK, then re-check the merged manifest |
| The feature is a convenience, not core | Remove the feature or move it behind an explicit, optional flow |
| The permission is left over from a removed feature | Delete it from the manifest — it is pure rejection risk |
| Google says the use case is not allowed at all (e.g. VpnService monetization) | Redesign; an appeal on this point does not succeed |
What we do
- Read the merged manifest and attribute every restricted permission to your code or to a dependency.
- Map each to a promoted feature, and identify which have a scoped alternative in the current APIs.
- Implement the alternative — photo picker, contact picker,
<queries>, SMS Retriever, foreground-only location, Geofence API — and remove what is left over. - Draft the declaration text and shot list for the video where a declaration is genuinely required, and re-check the Data safety form afterwards, because permission changes change it.
Checklist
- Merged manifest reviewed; every restricted permission attributed to a dependency or to your code
- Each restricted permission maps to a feature promoted in the listing
- Scoped alternative evaluated (pickers,
<queries>, foreground-only, Retriever/Geofence APIs) - Declaration forms complete, accurate and backed by a video where required
- Foreground service types declared in the manifest and in Play Console
- App still works when the user denies the permission
- 27 Jan 2027 changes planned: contacts, precise location, call-log verification, geofencing
- Data safety form re-checked after any permission change