Google Play permissions declarations: the four that block submissions, and how to fix each

The recurring mistake is declaring a permission your app barely uses — pulled in by an SDK, or kept 'just in case'. Google's reviewers ask what breaks without it. If the honest answer is 'nothing much', remove the permission instead of writing a better justification.

Photo and Video Permissions Policy — Photo and Video Permissions (Restricted Permissions)

Your app requests READ_MEDIA_IMAGES and/or READ_MEDIA_VIDEO, but Google judged that it only needs one-time or infrequent access to media — which must go through the Android photo picker instead. Broad media permissions are reserved for apps whose core functionality requires persistent, library-wide access (galleries, editors, backup tools), and keeping them requires a Play Console declaration proving the picker isn't sufficient.

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. If access is one-time or infrequent (profile photos, occasional uploads, attachments), remove READ_MEDIA_IMAGES/READ_MEDIA_VIDEO from the manifest — check merged manifests, since SDKs can add them — and use the Android photo picker.
2. If your core functionality genuinely requires persistent broad access, complete the Photo and Video Permissions declaration in Play Console (Policy and programs > App content), explaining why the picker cannot provide the core feature.
3. Remove the permissions from every track (production and testing) — Google checks all active version codes in the submission.
4. Resubmit and send the changes for review from the Publishing overview.

Resubmission checklist

• Permissions removed (incl. merged-manifest check) OR declaration completed
• Photo picker implemented for one-off selection
• All active tracks compliant
• Changes sent for review

Reply draft

Use the Play Console appeal/response form on the Policy status page if you believe the classification is wrong — state the core feature that requires persistent access and why the Android photo picker cannot deliver it. Otherwise, fix first (remove the permissions or complete the declaration), then respond noting the version codes updated.

What the decoder can diagnose here: Google's fork in the road: one-off/infrequent use → remove the permissions and use the photo picker; core persistent access → keep them and complete the declaration with a convincing justification. Google's notice usually states which side it put you on. What it cannot: Whether a declaration for a borderline use case will be accepted — declarations are reviewed, and 'users upload a profile photo' is the textbook case Google says belongs on the picker.

Rule text: “Apps that target Android 13 or higher (API level 33+) may only request the READ_MEDIA_IMAGES and READ_MEDIA_VIDEO permissions if system pickers (like the Android Photo Picker) are not sufficient for your app to provide core functionality. Apps that still request the permissions must submit a Play Console declaration to demonstrate access needs.” — Play Console Help / Developer Policy Center, 'Permissions and APIs that Access Sensitive Information' (Photo and Video Permissions), retrieved 2026-10-23

Foreground Service Permissions Policy — Foreground Service Types Declaration

Your app uses a foreground service type that either isn't declared in Play Console, or whose declaration was rejected — usually because the description is vague, the user-impact explanation is missing, or there's no demonstration video. Apps targeting Android 14+ must declare every foreground service type on the App content page, per type.

Severity: blocker · Decoder confidence for this class: A (see the honesty note below)

The fix

1. Open Play Console > App content > Foreground services and declare each type your manifest uses (android:foregroundServiceType) — manifest and declaration must match exactly.
2. Write a concrete description per type: what the feature is, what triggers it, what the user sees (including the persistent notification).
3. Describe the user impact if the system defers or interrupts the task — specifically, not 'the feature may not work'.
4. Record and link a video that shows a user triggering the feature in the app, per type.
5. If a type isn't truly needed, remove it from the manifest and use the recommended alternative API instead of declaring it.

Resubmission checklist

• Manifest FGS types == Play Console declaration types
• Per-type description + user impact completed
• Demo video link works and shows the feature being triggered
• Unneeded types removed rather than declared

Reply draft

Respond via the Policy status page in Play Console. State what changed per type: the declaration fields completed, the demo video link, and any types removed from the manifest. If Google directed you to an alternative API, say which one you migrated to and in which version code.

What the decoder can diagnose here: The four declaration ingredients Google requires per type: (1) description of the functionality, (2) user impact if the task is deferred or interrupted, (3) a link to a video demonstrating the feature being triggered, (4) the specific use case. A rejection almost always means one of the four is missing or generic. What it cannot: Whether Google considers your use case FGS-appropriate at all — some declared types get told to migrate to alternatives (WorkManager, user-initiated data transfer jobs) instead. Note shortService and systemExempted types don't require this declaration.

Rule text: “When your apps target Android 14 and above, you'll need to declare any foreground service types that you use in a new declaration on the App content page in Play Console. For each foreground service type you declare, you'll need to: provide a description of the app functionality; describe the user impact if the task is deferred or interrupted; include a link to a video demonstrating each foreground service feature; and choose your specific use case.” — Play Console Help, 'Understanding foreground service and full-screen intent requirements', retrieved 2026-10-23

Exact Alarm Permission Policy — Exact Alarm Permissions (USE_EXACT_ALARM / SCHEDULE_EXACT_ALARM)

Your app uses exact-alarm capability outside the narrow cases Google Play allows. USE_EXACT_ALARM is restricted to apps whose core, user-facing functionality requires precisely-timed actions — alarm or timer apps, and calendar apps that show event notifications. For other user-facing features that need exact timing, SCHEDULE_EXACT_ALARM (user-granted, revocable) is the alternative; for anything deferrable, inexact alarms or WorkManager are expected.

Severity: major · Decoder confidence for this class: A (see the honesty note below)

The fix

1. If your app is not fundamentally an alarm/timer/calendar app, remove USE_EXACT_ALARM from the manifest.
2. For user-facing reminders that genuinely need exact timing, switch to SCHEDULE_EXACT_ALARM and handle the grant flow (canScheduleExactAlarms() check, settings deep-link, graceful inexact fallback).
3. For deferrable work, migrate to inexact alarms or WorkManager and remove both permissions.
4. Check the merged manifest — libraries sometimes contribute these permissions silently.

Resubmission checklist

• USE_EXACT_ALARM present only if core alarm/timer/calendar functionality
• Grant flow + denial fallback implemented for SCHEDULE_EXACT_ALARM
• Merged manifest audited

Reply draft

Respond via the Policy status page after fixing. State which permission the new build declares and the core feature it serves. If you migrated to SCHEDULE_EXACT_ALARM or inexact scheduling, name the version code that carries the change.

What the decoder can diagnose here: Which permission you declared and whether your app's core use falls inside the permitted set — the classification is usually clear-cut from your app's primary purpose. What it cannot: Borderline 'reminders are our main feature' claims — Google decides by what the app principally does, not by the feature you point at. If exact timing is a secondary feature, plan on SCHEDULE_EXACT_ALARM plus a user-grant flow.

Rule text: “The USE_EXACT_ALARM permission is only intended for use by apps which core, user facing functionality requires precisely-timed actions, such as: an alarm or timer app, [or] a calendar app that shows event notifications. If your use case is not covered, you should consider using SCHEDULE_EXACT_ALARM as an alternative.” — Google Play policy on use of the Exact Alarm API (Developer Policy Center), retrieved 2026-10-23

Health Apps Policy / Health Connect Permissions — Health Data Permissions and Declaration

Your app requests health permissions (Health Connect android.permission.health.* or health-related access) without completing Google Play's health requirements: the Health apps declaration and the Health Connect permissions form in Play Console, a privacy policy that describes health data use, and a Data safety section that declares the health data. Extra declared permissions you didn't justify are the most common trigger.

Severity: major · Decoder confidence for this class: B (see the honesty note below)

The fix

1. Complete the Health apps declaration and Health Connect permissions form in Play Console (App content), justifying every health permission requested.
2. Remove any health permission the app doesn't actively use — declared-but-unused is the classic rejection.
3. Update the privacy policy (the one linked in Play Console and shown in the Health Connect permission sheet) to describe health data collection, use, and sharing.
4. Update the Data safety section to declare the health and fitness data types accurately.
5. Submit the health change as its own release and expect a longer review.

Resubmission checklist

• Health apps declaration + permissions form completed
• Every declared health permission justified and used
• Privacy policy covers health data
• Data safety declares health data consistently

Reply draft

Respond via the Policy status page. List the health permissions the build declares, the feature each serves, and confirm the declaration, privacy policy, and Data safety section have been aligned. Attach nothing Google didn't ask for; answer follow-up questions precisely.

What the decoder can diagnose here: The paperwork chain — declaration + permissions form + privacy policy + Data safety must all agree, per permission. A mismatch between any two is a rejection loop waiting to happen. What it cannot: Health reviews take longer than standard reviews and Google may ask follow-up questions about use cases; budget the time, and ship health changes as their own release rather than bundled with features.

Rule text: “Apps requesting Health Connect permissions must complete Google Play declarations describing how they use health data and comply with Play's health data policies.” — Google Play Health Apps policy / Health Connect permissions declaration (Play Console, App content), retrieved 2026-10-23

Frequently asked questions

Why did Google Play reject my permissions declaration?

Usually one of three things: the permission is declared but barely used (pulled in by an SDK or kept ‘just in case’), the justification is vague, or a required piece is missing — a per-type description, the user-impact explanation, or the demo video. Google asks what breaks without the permission; if the honest answer is ‘nothing much’, removing the permission beats a better-written justification.

Do I need a declaration to use READ_MEDIA_IMAGES or READ_MEDIA_VIDEO?

Only if your app’s core functionality requires persistent, library-wide access — galleries, editors, backup tools. If access is one-time or infrequent (profile photos, occasional uploads, attachments), Google expects the Android photo picker instead: remove the permissions and use the picker. Keeping them requires a Play Console declaration proving the picker isn’t sufficient.

Does the foreground service declaration need a video?

Yes — for each declared foreground service type, Google requires four things: a description of the functionality, the user impact if the task is deferred or interrupted, your specific use case, and a link to a video showing a user triggering the feature in the app. Note that shortService and systemExempted types don’t require this declaration.

Which apps are allowed to use USE_EXACT_ALARM?

Only apps whose core, user-facing functionality requires precisely-timed actions: alarm or timer apps, and calendar apps that show event notifications. For user-facing reminders outside that set, SCHEDULE_EXACT_ALARM (user-granted and revocable) is the alternative; for deferrable work, use inexact alarms or WorkManager.

What do Health Connect permissions require on Google Play?

Four pieces that must agree with each other, per permission: the Health apps declaration and Health Connect permissions form in Play Console, a privacy policy that describes health data collection, use, and sharing, and a Data safety section that declares the health data types. Declared-but-unused health permissions are the most common trigger.

Related guides

• Rejection decoder — Google Play mode included
• Google Play Pre-Flight — the checks and the enforcement ladder
• App Store Pre-Flight — the other store's rulebook
• Play — Data safety section
• Play — Target API level requirement

Sources

• Play Console Help / Developer Policy Center, 'Permissions and APIs that Access Sensitive Information' (Photo and Video Permissions), retrieved 2026-10-23
• Play Console Help, 'Understanding foreground service and full-screen intent requirements', retrieved 2026-10-23
• Google Play policy on use of the Exact Alarm API (Developer Policy Center), retrieved 2026-10-23
• Google Play Health Apps policy / Health Connect permissions declaration (Play Console, App content), retrieved 2026-10-23

Last updated November 3, 2026. Rules change; the retrieval dates above say when this page was last checked against the store's published text.