Google Play only lets apps targeting Android 13 or later request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO when a system picker, such as the Android photo picker, cannot serve the app's core function. Everyone else must remove those permissions and use a picker instead, and the policy has been fully enforced since 28 May 2025, with non-compliant apps subject to removal. Apps that genuinely need broad access, such as gallery apps, must justify it in a Play Console declaration. For most apps that let users attach or upload a photo, the photo picker is the compliant answer, and it is also the better privacy design.
Short answer
The Photo and Video Permissions policy treats user photos as personal and sensitive data. If your app targets API level 33 or higher and only needs photos occasionally, for a profile picture, an attachment, a one-off upload, you should not hold READ_MEDIA_IMAGES or READ_MEDIA_VIDEO at all. Use the system photo picker, which gives your app only the items the user selects and needs no permission. If your app's core purpose requires broad, persistent access to the library, keep the permissions and file the declaration explaining why a picker is not enough.
| Your app's use of photos | Policy position | What to do |
|---|---|---|
| Profile picture, avatar, occasional attachment | Picker is sufficient | Remove the permissions, use the photo picker |
| Upload or share a few items at a time | Picker is sufficient | Use the photo picker with multi-select |
| Photo editor working on chosen images | Usually picker is sufficient | Use the picker; justify broad access only if editing truly needs the library |
| Gallery, backup or photo management app | Broad access can be core functionality | Keep permissions, submit the declaration |
| Custom in-app picker for design reasons | Not automatically qualifying | Declaration must explain why the system picker is insufficient |
| Enterprise or device management app | Exempt | Confirm the exemption applies to your distribution |
Why Google introduced the policy
Broad media permissions let an app read every photo and video on a device, not just the ones relevant to the task. Google's policy describes broad access to shared storage as a vector for abuse, and photos are among the most sensitive data a phone holds: faces, documents, locations embedded in metadata, screenshots of messages and banking apps.
The design principle behind the policy is data minimisation. An app that needs one picture should receive one picture. The OWASP Mobile Application Security Verification Standard makes the same point in its privacy controls, which expect apps to collect only the data they need and to use platform mechanisms that limit exposure. The photo picker is exactly such a mechanism: the user chooses, the app receives only the chosen items, and no permission is granted.
How the photo picker works
The Android photo picker presents the user's library in a system interface, lets them choose one or several items, and returns content URIs for only those items. Because the selection happens in the system UI, your app does not need READ_MEDIA_IMAGES or READ_MEDIA_VIDEO.
Several practical details matter:
- Availability. The picker is available on Android 11 (API 30) and higher, and a backported version reaches older devices that support Google Play services.
- Integration. Android's documentation uses the androidx.activity library's picker contracts, version 1.7.0 or higher, which handle single and multiple selection and filter by images, videos or both.
- Updates. The picker is updated by the system, so improvements arrive without code changes in your app.
- Alternatives. Using the Android photo picker is not mandatory. Other system pickers are acceptable, as long as your app does not hold broad media permissions it does not need.
Accessing the returned items is temporary by default. If your app needs to keep working with an item later, for example a draft that references a chosen image, copy the file into your app's own storage or request persistable access where the platform allows it, rather than reacquiring broad permissions.
How to migrate an existing app
Most migrations take an afternoon of code and a careful release.
Find every use of the permissions
Search the merged manifest of your release build, not just your own manifest file. Libraries can add READ_MEDIA_IMAGES, READ_MEDIA_VIDEO or the older READ_EXTERNAL_STORAGE permission through manifest merging, and the policy applies to what ships, whoever added it. Android Studio's merged manifest view shows which library contributed each permission.
Replace the access with a picker
For each feature that reads media, replace the gallery query with a picker launch. Typical changes: a profile photo screen launches the single-item picker; an attachment flow launches the multi-item picker with a sensible maximum; an upload screen filters to images or videos as needed.
Remove the permissions from the manifest
Remove the permissions you no longer need, and use a manifest removal rule for permissions a library adds that your app does not use. Then confirm in the merged manifest that they are gone.
Handle users who previously granted access
Users who granted broad access to an earlier version do not need to do anything; the new version simply stops requesting it. Make sure the features still work for them through the picker, and remove any code that assumes the permission is present.
Test the new flow on old and new devices
Test the picker on the oldest Android version you support as well as the newest. On devices where the system picker is not built in, the backported version arrives through Google Play services, and devices without Play services fall back to another system document picker. Check single and multiple selection, cancelling the picker, choosing videos where only images are expected, very large files, and items stored in cloud-backed libraries that need downloading before your app can read them.
Check the flows around the picker too. Uploads should show progress and survive the app going to the background. Error messages should make sense when a chosen file cannot be read. And any screen that previously showed a grid of the user's recent photos, a pattern that depended on broad access, needs redesigning around an explicit "choose photos" action instead.
Release and check Play Console
After the update, confirm that Play Console no longer flags the permissions, and keep the policy page bookmarked for changes.
If your app genuinely needs broad access
Some apps cannot work with a picker: a gallery, a photo backup service, a media manager or a tool that must scan the whole library. For those, broad access is core functionality, and Google's policy allows it with a declaration.
A declaration that holds up usually does three things. It describes the core feature in concrete terms rather than marketing language. It explains specifically why the system picker is not technically sufficient, for example because the app must process the entire library continuously rather than items a user selects. And it matches what reviewers see when they use the app: a backup app whose store listing and first screen are about backup is credible; a messaging app claiming it needs the whole library is not.
Apps with custom pickers are a common grey area. Building your own picker for design reasons does not qualify automatically, and the declaration has to explain why the Android photo picker or another alternative is insufficient. A nicer look rarely meets that bar.
When a user declines broad access, the policy expects a reasonable effort to keep the feature working through a more limited method, such as a system picker, or a modified experience. An app that stops working entirely without the permission is harder to defend.
Common rejection and removal causes
A library adds the permission. The app's own code never reads the gallery, but an SDK's manifest adds READ_MEDIA_IMAGES. The policy still applies. Remove it with a manifest rule if the feature is unused, or update the SDK.
The permission is requested for a minor feature. A shopping app requests broad access so users can upload a receipt. A picker covers that, so the declaration fails.
The declaration does not match the app. The declared core function is not visible in the app or the store listing. Reviewers compare the two.
Old code paths still request the permission. A legacy screen, an onboarding step or an A/B test variant still triggers the permission prompt. Search the codebase for every request, including in feature flags.
The older storage permission lingers. READ_EXTERNAL_STORAGE declared without a max SDK version can still appear in the merged manifest. Limit it to the API levels where it is actually needed, or remove it.
What this means for privacy beyond Play policy
Removing broad media permissions does more than satisfy a review. It reduces what your app can leak if it is compromised, what an SDK inside it can collect, and what you have to describe in your Data safety form. Google Play's Data safety section asks developers to declare the data their app collects, and photos accessed broadly are much harder to describe accurately than items a user chose to share.
Metadata deserves a mention here. Photos often carry location and device details in their metadata, and an app that uploads a chosen image may pass that along unless it strips it. Removing location metadata before upload, where the feature does not need it, is a small step that protects users even when access itself is limited to what they chose.
It also changes the trust conversation with users. A permission prompt asking for access to all photos is a reason to uninstall for many people. A picker that shows the library and lets them choose feels like a normal part of the task.
Checking what your build actually requests
The fastest way to find stray permissions is to inspect the built APK or AAB rather than the source, because manifest merging is where most surprises come from. A scanner like PTKD.com analyses the build and reports over-broad permissions, exported components and other privacy-relevant settings by severity, mapped to OWASP MASVS. It does not file your Play declaration or decide whether your app qualifies for broad access, which is Google's call; it shows what the binary you are about to upload actually requests.
A quick manual check works too: open the release build in Android Studio's APK Analyzer, read the merged AndroidManifest.xml, and list every permission. For each one, write down the feature that needs it. Any permission without a feature next to it is a candidate for removal.
A short migration checklist
- List every permission in the merged release manifest and note which library added each.
- Replace gallery reads with the photo picker for profile photos, attachments and uploads.
- Remove READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and unnecessary READ_EXTERNAL_STORAGE, including those added by libraries.
- Copy chosen media into app storage when you need it later, rather than reacquiring broad access.
- If broad access is core, write a concrete declaration and make sure the app and listing show that core function.
- Update the Data safety form to match what the app now collects.
- Release, confirm Play Console no longer flags the permissions, and keep checking merged manifests on every dependency update.
What to take away
- Apps targeting Android 13 or later may request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO only when a system picker cannot serve core functionality, and full compliance has been required since 28 May 2025.
- For profile photos, attachments and uploads, the Android photo picker is the compliant choice and needs no permission.
- Apps whose core purpose needs broad access, such as galleries and backup apps, must submit a Play Console declaration that matches what the app visibly does.
- Libraries often add media permissions through manifest merging, so check the merged release manifest, not just your own file.
- Inspect the built APK or AAB before upload, manually or with a tool such as PTKD.com, so no stray permission ships.
