Google Play photo and video permissions: fix READ_MEDIA_IMAGES with the photo picker

How do I switch to the Android photo picker?

The photo picker shows the user's photos and videos in a system screen and returns only the items they choose. Your app needs no storage permission for it. Google's photo picker guide recommends version 1.7.0 or higher of the androidx.activity library, which gives you two contracts: PickVisualMedia for one item and PickMultipleVisualMedia for several.

// Registers a photo picker; no READ_MEDIA_* permission needed.
val pickMedia = registerForActivityResult(PickVisualMedia()) { uri ->
    if (uri != null) {
        // Use the image or video the user chose
    }
}

// Images only; use ImageAndVideo or VideoOnly as needed.
pickMedia.launch(PickVisualMediaRequest(PickVisualMedia.ImageOnly))

Things worth knowing:

• Device support. The picker runs on Android 11 (API level 30) and higher with Google System Updates. Google Play services can install a backported version on Android 4.4 to 10 and on Android Go devices running 11 or 12. Where the picker isn't available at all, the library falls back to ACTION_OPEN_DOCUMENT, still with no permission.
• Longer access. Access to picked files lasts until the device restarts or your app stops. For long uploads in the background, call takePersistableUriPermission() on the returned URI.
• You don't have to use this picker. Google says: "You are not required to use the Android photo picker and can integrate other system pickers per your preference as needed."

Cross-platform frameworks have image picker plugins that call the system picker on Android. Update them to their current version and then check the final manifest, because older versions or extra features may still declare the broad permissions.

How do I remove READ_MEDIA_IMAGES if an SDK adds it?

This is the most common reason the warning won't go away. Your own manifest may be clean, but a library's manifest is merged into your app at build time.

1. Find where it comes from. In Android Studio, open AndroidManifest.xml and click the Merged Manifest tab at the bottom of the editor (Google's manifest merge guide). It shows each permission and which library added it.
2. Check the actual bundle you upload. With bundletool: bundletool dump manifest --bundle=app-release.aab | grep READ_MEDIA.
3. Remove it with a merge rule in your app's main manifest. Google describes tools:node="remove" as the way to drop an element "provided by a lower-priority manifest file that's out of your control (such as an imported library)".

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <!-- Drop broad media access that a library merges in -->
    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES"
        tools:node="remove" />
    <uses-permission android:name="android.permission.READ_MEDIA_VIDEO"
        tools:node="remove" />
    <!-- Only used together with the two above; not needed with the picker -->
    <uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED"
        tools:node="remove" />

</manifest>

Where that manifest lives depends on your tools:

• Native Android, Flutter, React Native: android/app/src/main/AndroidManifest.xml (or app/src/main/ in a native project). Remember to add the xmlns:tools line.
• Expo: list the permissions under android.blockedPermissions in your app config, then rebuild.
• Unity: enable a custom main manifest in Player Settings, Publishing Settings, and add the lines there.
• No-code builders: ask the builder's support. Several platforms added these permissions automatically and had to ship a fix.

Then test every place your app lets users choose a photo. If a library really needed the permission for a feature you use, that feature will now fail, and it's a sign to swap that feature to the picker.

Why does the warning stay after I removed the permission?

Google says the permissions must be gone from "all version codes within the submission. This includes both production and testing tracks." A build still active on internal, closed or open testing with the old manifest keeps the issue open. Release the fixed build (with a higher version code) to every track that still serves an old one, or replace those releases, and then send the changes for review. If you use testing tracks, check each one.

How do I submit the photo and video permissions declaration?

Only do this if broad access really is your app's core function.

1. Open the app in Play Console.
2. Go to Monitor and improve → Policy and programs → App content.
3. Open the photo and video permissions declaration and answer for each permission your app requests.
4. Save, then send your release for review from Publishing overview.

What makes a declaration convincing:

• Name the core function in one sentence, the way your store listing does: "a gallery app that organizes and backs up the user's whole photo library."
• Say why the picker isn't enough, in technical terms: for example, the app must scan the whole library in the background, which a picker selection can't provide.
• Keep it consistent with your store listing, screenshots and Data safety form. A reviewer who sees a chat app claiming to be a gallery will reject it.

Google reviews the request: "We will evaluate your request to determine if your use case is approved." If your use is "users upload a photo", it won't be: use the picker.

What about partial access on Android 14 (READ_MEDIA_VISUAL_USER_SELECTED)?

From Android 14, users can give an app access to selected photos only (Google's partial access guide). Apps with their own gallery screen can handle this with the READ_MEDIA_VISUAL_USER_SELECTED permission. But that permission is requested together with READ_MEDIA_IMAGES or READ_MEDIA_VIDEO, so it doesn't get you around the policy: if your app declares the broad permissions, the Play rules above still apply. Google's own recommendation in that guide is the photo picker, "without having to request any storage permissions."

Apps that are approved for broad access still have to work for people who say no. Google's help page: "you must make a reasonable effort to accommodate users who do not grant broad access to media files on their device." Offer the picker as a fallback.

What happens if I ignore it?

Google's timeline says: "May 28, 2025: Full policy compliance is mandatory for all developers, including those who requested an extension. After this date, all apps are subject to removal from Google Play if not compliant." In practice, developers report that Play Console rejects new releases that still carry the permissions without an approved declaration, so you find out the next time you ship an update.

The same pattern now applies to other permissions. Google's policy preview lists a similar Contacts rule (use the Contact Picker) for apps targeting Android 17, and location has its own change: see the location permission policy for 2027 and the target API level requirement.

Next steps

1. Search your merged manifest and your uploaded bundle for READ_MEDIA_.
2. If photos aren't your app's core function, switch to the photo picker and remove the permissions with tools:node="remove".
3. Release the fixed build to every track, production and testing.
4. Only if you're a gallery-style app, submit the declaration in App content.
5. Update your Data safety form if what you collect changed.

Once your update is live, list your app on TrueLaunch to get it in front of other developers and early users for honest feedback. For everything else Google announced recently, see the October 2026 policy update.