Google Play Photo and Video Permissions in 2026: 8 Questions About the Photo Picker and Broad Media Access

Three of Google Play's minimum-scope permission policies have taken the headlines this year — the location button, the Contact Picker, and the removal of READ_CALL_LOG as a way to verify a phone number. The fourth, Photo and Video Permissions, has no future deadline to announce, because it is already fully enforced: Google introduced the policy in October 2023 and made full compliance mandatory on 28 May 2025, including for developers who had been granted an extension. That turns the topic into operational questions rather than theoretical ones. Your app either holds READ_MEDIA_IMAGES and READ_MEDIA_VIDEO and can justify that access through a Play Console declaration, or it does not — in which case the permissions should already be gone from the manifest. The eight questions below are the ones we are asked most often, answered from the Permissions and APIs that Access Sensitive Information policy page, Google's minimum scope alternatives guidance, and the Android photo picker documentation.

1. Which apps are in scope?

Apps that target Android 13 or higher (API level 33+) may only request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO if system pickers such as the Android Photo Picker are not sufficient for the app to deliver its core functionality. Google also states that all user photos are personal and sensitive data, so the User Data policy applies to anything accessed through them, and that users who decline a permission must never be manipulated or pressured into granting it. The one documented carve-out is worth memorising: private and enterprise device management apps are exempt from this policy requirement.

2. Is this a 2026 requirement, or older?

Older, and that is exactly the point. The timeline on Google's help page reads: October 2023 — the Photo and Video Permissions policy is introduced; 28 May 2025 — full policy compliance is mandatory for all developers, including those who requested an extension, after which non-compliant apps are subject to removal from Google Play. If an app on your account still carries the broad media permissions without a declaration, it has been out of compliance for more than a year rather than waiting for a deadline.

3. Do I still need the Play Console declaration?

Yes, and it is the whole test. Google's wording is that apps which still request READ_MEDIA_IMAGES and READ_MEDIA_VIDEO must submit a declaration to demonstrate access needs for Photos and why the Android Photo Picker (or alternatives) would not suffice. Broad access is reserved for core functionality that genuinely cannot be served by a picker — photo and video management apps whose job is maintaining the user's entire library being the canonical example. If you cannot describe a user-facing feature that breaks without broad access, the declaration is the wrong path and the permissions should come out.

4. Does a custom in-app gallery count as an alternative?

No. Google answers this one directly: apps that have custom pickers are not automatically qualified to use the permission — they must still submit a declaration demonstrating why the Android Photo Picker or another system alternative is insufficient. The reverse is also true, and worth knowing before you spend engineering time: you are not required to use Google's photo picker specifically. Other system pickers are acceptable if they deliver the same minimum-scope behaviour.

5. Does the photo picker need any storage permission?

No. That is the reason Google pushes it: the picker gives users a constrained way to hand over specific items, so the app can read what the user selected without requesting any storage permission and without ever seeing the rest of the library. Implementation is deliberately small — add androidx.activity 1.7.0 or higher and use the PickVisualMedia contract for a single image or video, or PickMultipleVisualMedia for several. If the picker is unavailable on the device, the Jetpack library automatically falls back to the ACTION_OPEN_DOCUMENT intent, which every device on Android 4.4 (API level 19) or higher supports. isPhotoPickerAvailable() lets you branch in code instead of guessing.

6. Which Android versions actually have the picker?

The photo picker ships as a Modular System Component, so it is not tied to one Android release. It is present on devices running Android 11 (API level 30) or higher that receive Google System Updates. Devices on Android 4.4 (API level 19) through Android 10, plus Android Go devices on Android 11 or 12 that support Google Play services, can install a backported version. To trigger that automatic install, add the com.google.android.gms.metadata.ModuleDependencies service to your manifest's <application> tag with the metadata key photopicker_activity:0:required — that is a three-line manifest change that lifts picker availability from "new phones only" to almost the entire install base.

7. What happens when a user grants only selected photos?

On Android 14 the permission dialog offers Selected Photos Access, which gives an app specific images and videos instead of the whole library. The behaviour depends on your targeting: the change is enabled only if the app targets Android 14 (API level 34) or higher, and if you do not declare READ_MEDIA_VISUAL_USER_SELECTED the system runs your app in compatibility mode. Once you declare it, partial access is controlled by the app rather than the system. Treat any URI as temporary: Google's guidance is to query MediaStore through ContentResolver instead of caching results, to refresh when the app returns to the foreground (the user can switch between full and partial access in settings without closing your app), to request related permissions in one operation so users are not hit with several dialogs, and to re-request only after an explicit in-app action. For long-running work such as a background upload, persist access deliberately with takePersistableUriPermission() — noting the ceiling of 5,000 media grants per app, after which the oldest grant is dropped.

8. What has to change if I do not qualify?

Remove the permissions. Google's own FAQ is blunt about the end state: if the app does not need access to photos and videos through a supported core use case, the media access permissions must be removed from the app by the effective policy date. In parallel, the app still has to work for people who refuse broad access — the Restricted Permissions rules require a reasonable effort to accommodate them, which in practice means routing the feature through a system picker or degrading gracefully instead of blocking. After the swap, re-check what the app now reads: because everything reached through those permissions counts as personal and sensitive user data under the User Data policy, the Data safety and app content answers should still describe the app's actual behaviour once the broad permissions are gone.

Where to start this week

• Audit every package on the account for READ_MEDIA_IMAGES and READ_MEDIA_VIDEO, and separate the ones with a real library-management core from the ones that merely wanted a multi-select grid.
• For the second group, add the Jetpack contracts and the backported-module manifest entry, then confirm the picker opens on an Android 11 device and on an Android 9 device.
• For the first group, write the declaration around a named user-facing feature and the technical reason a picker cannot serve it — and keep that evidence handy, because this is the standard Google evaluates against.

Sources

• Google Play policy — Permissions and APIs that Access Sensitive Information: support.google.com/googleplay/android-developer/answer/16558241
• Google Play Console Help — Understanding Restricted Permissions with minimum scope alternatives: support.google.com/googleplay/android-developer/answer/16935362
• Android Developers — Photo picker: developer.android.com/training/data-storage/shared/photo-picker
• Android 14 — Grant partial access to photos and videos: developer.android.com/about/versions/14/changes/partial-photo-video-access