How to Fix Google Play Photo and Video Permissions Rejection
Remove ineligible READ_MEDIA_IMAGES and READ_MEDIA_VIDEO access or prove why broad media access is indispensable to the app's core purpose.
Direct answer
If users only choose a profile photo, attach media to a post, upload a receipt, or select images occasionally, remove READ_MEDIA_IMAGES and READ_MEDIA_VIDEO from every version code in the submission—including production and testing tracks—and use Android Photo Picker or another system picker. A permission declaration does not make an occasional-use case eligible. Keep broad access only when managing or maintaining photos or videos is a core app purpose and the system picker is technically insufficient; then submit a release-specific declaration and demonstration that prove that need.
Match the wording in your rejection
“Your app only requires one-time or infrequent access to media files”
Google expects a minimum-scope system picker, not broad READ_MEDIA_IMAGES or READ_MEDIA_VIDEO access. Remove the permissions from the submitted release set and migrate the affected flow.
The app does not declare the permissions, but Play still detects them
Inspect the final merged manifest and every submitted version code. A dependency, product flavor, older active artifact, or testing track can still carry the permission.
The Photo and Video Permissions declaration was rejected
The declared feature may not be the app's core purpose, the picker may be sufficient, or the evidence may not demonstrate why continuous broad access is technically necessary.
What this rejection usually means
Google Play restricts READ_MEDIA_IMAGES and READ_MEDIA_VIDEO for apps targeting Android 13 or later because these permissions expose broad access to personal media. The usual rejection is a scope mismatch: the app needs a user-selected photo or video, while the submitted artifact requests access to a wider library. A second common cause is release-state mismatch, where the developer removed the permission from source code but it remains in the merged manifest or another version code included in production, open, closed, or internal testing.
Likely rejection signals
- The feature uploads a profile image, receipt, attachment, listing photo, or occasional post
- READ_MEDIA_IMAGES or READ_MEDIA_VIDEO appears only after manifest merging
- An SDK, plugin, product flavor, or legacy module contributes broad media access
- A production or testing-track version code still contains the restricted permission
- The declaration describes a useful feature but does not prove that broad access is core or that a system picker is insufficient
Recovery plan
- Copy the full policy notice and record the package name, affected version codes, tracks, target SDK, cited permissions, and declaration status. Do not answer from memory or upload another unchanged bundle.
- Inspect the merged manifest for every app bundle included in the submission, not only AndroidManifest.xml in the main module. Identify which library, manifest overlay, flavor, or legacy artifact contributes READ_MEDIA_IMAGES or READ_MEDIA_VIDEO.
- Classify each media flow. Profile photos, receipts, attachments, and occasional user-selected uploads normally need transactional access; gallery management, backup, or another media-library-centered purpose may need broad access only when a picker cannot deliver the core function.
- For occasional access, replace broad permission requests with Android Photo Picker or another system picker. Use PickVisualMedia for one item or PickMultipleVisualMedia for a bounded selection, and handle the documented fallback on devices where Photo Picker is unavailable.
- Remove the ineligible permissions from every relevant manifest and verify the signed release artifact. Check production and all testing tracks for version codes included in the submission; update or deactivate noncompliant artifacts through the release workflow available in Play Console.
- For an eligible broad-access use case, request only the necessary media permission and complete the Play Console declaration. Show the core user journey, the point where broad access is required, and why a picker or narrower API cannot provide that function.
- Test the signed bundle on supported Android versions with access granted, denied, partially selected where applicable, and revoked. Confirm the feature degrades reasonably when broad access is not granted and that Data safety and privacy disclosures match actual collection and use.
- Submit one corrected release or one evidence-based appeal. Name the exact version codes and completed changes, link an accessible demonstration when required, and avoid claiming approval is guaranteed.
Evidence to prepare
- Original policy notice, package name, affected version codes, tracks, and target SDK
- Merged-manifest reports for every submitted artifact showing the final permission set and contributing dependency
- Signed-bundle test recording of the Photo Picker or the broad-access core flow
- Play Console artifact inventory confirming no included production or testing version code retains an ineligible permission
- For broad access, a permission declaration and public demonstration proving why the picker is technically insufficient
- Data safety and privacy-policy entries reconciled with the corrected release behavior
Appeal or fix first?
Clarify or appeal when every artifact included in the reviewed submission already omits broad media permissions, or when broad access is genuinely central to the app and the declaration evidence proves why a system picker cannot provide the required function. Anchor the appeal to exact version codes, tracks, merged manifests, and the reviewer-visible flow.
Fix and resubmit when media selection is occasional, a system picker can support the feature, any submitted artifact still carries READ_MEDIA_IMAGES or READ_MEDIA_VIDEO, or the declaration describes convenience rather than an indispensable core function.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the package, affected version codes, tracks, and exact media permissions cited.
- State whether broad permissions were removed or retained under a core-functionality declaration.
- For removal, name the replacement picker and confirm the final merged manifests were checked.
- For broad access, explain the core workflow and why a system picker is technically insufficient.
- Attach a short accessible recording and give the exact reviewer path in the signed release.
Frequently asked questions
Can I keep READ_MEDIA_IMAGES just for profile-picture uploads?
Usually no. A profile-picture upload is normally occasional, user-initiated access, so Google directs developers to remove broad media permissions and use a system picker.
Why is Google detecting a permission that is not in my main manifest?
The final manifest can include permissions contributed by libraries, plugins, flavors, or overlays. Google also evaluates version codes included across the relevant production and testing tracks, so inspect each merged manifest and artifact.
Do I have to use Android Photo Picker?
Google says other system pickers can be used. The key policy distinction is minimum-scope, user-selected access rather than unnecessary broad library access.
Should I appeal after migrating to Photo Picker?
A corrected release is usually the direct path when the rejected artifact carried ineligible permissions. Appeal when the reviewed artifacts already complied or Google evaluated the wrong artifact, and prove that with version-specific evidence.
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 — Restricted permissions and minimum-scope alternatives. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.