Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageWhat the Photo and Video Permissions policy says
Since Android 13, broad access to a user's pictures and videos is split into two permissions, READ_MEDIA_IMAGES and READ_MEDIA_VIDEO. Google Play treats both as restricted: an app may request them only if a system picker, such as the Android photo picker, cannot serve its core functionality. Apps that need media only once or occasionally (a profile picture, a receipt, a photo attached to a support ticket or a listing) are expected to use the picker and remove the permissions from their manifest. Apps that keep them must explain why in a declaration in Play Console.
Google's policy details name gallery-style apps that manage all of a user's media as the typical case for broad access. Full compliance has been mandatory since 2025; apps that do not comply can have updates blocked or be removed. The picker is also the better experience: users choose exactly which images to share instead of opening their whole library to your app.
How the rejection reads
Developers typically see an issue under the Photo and Video Permissions policy stating that the permission use is not directly related to the app's core purpose, because the app only needs one-time or infrequent access to media files. The notice asks you to remove READ_MEDIA_IMAGES and READ_MEDIA_VIDEO from every version code in the submission, production and testing tracks alike, or to submit a declaration if your core functionality really needs broad access. For a web app, rewording the declaration rarely helps. Removing the permission does.
How uploads work in a WebView app without media permissions
When your web app shows <input type="file" accept="image/*">, the Android WebView asks the native app to open a file chooser. WebViewGold answers with the camera, the gallery or both, depending on filePickerMode in Config.java: 0 for camera and gallery, 1 for camera only, 2 for gallery only. The file the user picks is handed back to the page and uploads as it would on the web.
Choosing a file through a system picker or chooser grants the app access to that one file only, through the user's own tap. That is why an ordinary upload flow does not need READ_MEDIA_IMAGES. Taking a new photo is a camera feature that uses the camera permission (requireCamera), a separate topic covered in the permissions guide. The document scanner plugs into the same chooser and returns a PDF the same way.
Great way of converting your web app to a native app! Fast turn-around, and a great way to get your apps into the app stores without the need to develop a full native app!
Feature by feature: which permission is really needed
| Feature in your web app | Permission needed | WebViewGold setting |
|---|---|---|
| Upload an existing photo or file | No media permission; the picker shares the chosen file | filePickerMode 0 or 2 |
| Take a new photo for an upload | Camera | requireCamera true, filePickerMode 0 or 1 |
| Scan a QR code or barcode | Camera | requireCamera; see the QR scanner docs |
Save an image to the gallery (savethisimage://) | No read access to the library is needed to add a new image on current Android versions | requireStorage for downloads and uploads; see the downloader docs |
| Show the user's entire photo library inside your app | READ_MEDIA_IMAGES and READ_MEDIA_VIDEO plus a declaration | Rarely a fit for a web app; a gallery manager is a native app |
Remove the permissions and keep uploads working
About thirty minutes in Android Studio, plus one round of testing on a phone.
Find out where they come from
In Play Console, open the App bundle explorer for the rejected version and look at its permission list. In Android Studio, open AndroidManifest.xml and switch to the Merged Manifest tab; it shows whether an entry comes from your own manifest or from a library.
Match the settings to your features
Set
filePickerModeto what your upload needs, setrequireCamerato false if no feature takes photos or scans codes, and keeprequireStoragetrue only if the app uploads or downloads files, as the Config.java reference describes.Strip the media permissions
Delete the
READ_MEDIA_IMAGESandREAD_MEDIA_VIDEOlines from your manifest, or add the removal rules below if a library contributes them. IfREAD_MEDIA_VISUAL_USER_SELECTEDshows up as well, remove it with them unless you know exactly why it is there.Test every media flow on a recent Android version
Install the new build from internal testing on an Android 14 or newer device and try an upload from the gallery, a photo taken with the camera, the document scanner if you use it, an image saved with
savethisimage://and a PDF download. If anything fails, send WebViewGold support your template version and the failing flow before you submit.Replace the bundle on every track
Upload the new bundle with a higher version code and replace older bundles on the internal, closed and open testing tracks too. Google checks every version code in the submission.
Clear the declaration
If Play Console still shows the photo and video permissions declaration, state that the app no longer requests these permissions, then send the changes for review.
Removal rules for AndroidManifest.xml
Use these when the Merged Manifest shows the permissions coming from a dependency. Add the tools namespace to the manifest element if it is missing.
xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<!-- Uploads use the system picker; no broad media access needed -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" tools:node="remove" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" tools:node="remove" />
<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" tools:node="remove" />
</manifest>Template: reply after removing the permissions
Short and verifiable. Name the version code that fixes it and the exact path where the reviewer can test an upload.
For Policy status or the release notes (adapt the brackets)
App: [App name], package name [com.example.app]. Rejected version code [123], new version code [124]. The app needs only occasional access to photos: users attach a single image to [their profile / a support request / a listing]. We removed READ_MEDIA_IMAGES and READ_MEDIA_VIDEO from version code [124] and from every active track, including internal and closed testing. Uploads now go through the Android system picker, which shares only the image the user selects. To verify: log in with the account in Sign-in details, open [Profile > Edit profile], tap [Change photo] and choose an image. Thank you for reviewing version code [124].
Frequently asked questions
Can users still upload photos after I remove READ_MEDIA_IMAGES?
Yes. A file input opens the system picker or chooser, which shares the selected file without any broad media permission. Test the flow once on Android 13 or newer after the change.
Does the policy cover videos too?
Yes, READ_MEDIA_VIDEO falls under the same rules. A selected video can be shared through the picker in the same way as a photo; if your app accepts video uploads, include them in your test round.
My app is a photo community. Do I qualify for broad access?
Probably not. Posting selected photos is exactly what the picker is for. Broad access is meant for apps whose core function the picker cannot serve, such as gallery managers, and the declaration has to explain why the picker is technically insufficient.
Why did Google flag this now if my app did not change?
Google checks the permissions in every bundle you submit against the current policy, and a new library version can add manifest entries. The Merged Manifest tab shows which file each permission comes from.
Is the camera permission affected?
No. CAMERA is a separate permission with its own justification. Keep it only if a feature takes photos or scans codes, and remove it otherwise.
Three ways to get your app into the stores
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
Cloud Builder
$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demoFull Service
$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.