A location prompt on the first screen
Your home page calls the geolocation API on load, so Android asks for location before the user has seen anything. Nothing explains why. That is the textbook violation.
What the User Data policy asks for
Google's User Data policy has a specific rule for data use a user would not necessarily expect. When your app accesses, collects, uses or shares personal or sensitive data in a way that may fall outside what the user reasonably expects from the feature in front of them, you must first show an in-app disclosure and then ask for consent.
The disclosure has to be inside the app and part of normal use, not hidden in a settings menu, the store description or the privacy policy. It must say which data is involved and how it is used and shared, and it must not be buried among unrelated text such as your terms. Consent needs an affirmative action, like tapping a clearly labeled button; tapping outside, pressing back or a message that disappears on its own does not count. When a runtime permission is involved, the disclosure comes before the system prompt. Google's best practices for prominent disclosure add practical detail: lead with why, list the data, write plainly, offer a way to decline, and do not imitate Android system dialogs.
The disclosure does not replace your privacy policy or the Data safety form. All three have to describe the same reality.
How the rejection reads
The Policy status entry names the User Data policy and its prominent disclosure requirement, often with the data type the reviewer noticed: location, contacts, images, installed apps or a device identifier. Titles developers commonly report include Prominent disclosure not found and Missing information in prominent disclosure. The first means the reviewer saw a permission prompt or a data flow without any explanation before it. The second means an explanation exists but lacks something: usually the word "location", the background wording for background access, or what happens to the data. The screenshot often shows the system permission dialog on the very first screen of the app.
Where web-wrapped apps trigger it
A pile of prompts at launch
WebViewGold asks for notification permission on the first run by default (requirePush). That is not a personal-data issue in itself, but a stack of prompts before any context is exactly what reviewers screenshot. Move every prompt into context.
Contacts sent to your server
The contacts API (requestcontactpermission://, then readcontacts://) hands the address book to your web app. Uploading it for "find friends" needs a disclosure that names contacts and the upload.
Photos leaving the device
An upload the user starts from a file input is expected. Uploading images in the background or using them for anything beyond the visible feature is not, and needs a disclosure.
Scripts inside your web app
Session replay, fingerprinting, chat widgets and analytics tags run inside the WebView and count as your app's data collection. If a script records input or builds a device profile, disclose it or keep it out of the app.
With a good optimized version of your web app you can have a stunning mobile app within a couple of minutes. Additionally to that the customer service is very nice and very helpful! I can just recommend WebViewGold :-)
What each disclosure has to say
| Data | Show the disclosure | It must say |
|---|---|---|
| Location while the app is open | On the feature screen, right before the geolocation call | That the app collects location, for which feature, and whether it is sent to your server or shared |
| Background location | Before the location prompt, inside the feature that needs it | The word location, a phrase such as "when the app is closed or not in use", every feature that uses it and whether it serves ads; see the background location guide |
| Contacts | Before requestcontactpermission:// | Which fields are uploaded (names, numbers, emails), why, how long you keep them and who else receives them |
| Photos, camera, microphone | Before the first capture or upload, whenever the use is not obvious | What is captured or uploaded and where it goes |
| Data collected by scripts | Before the script starts, usually on first launch | What is collected (for example screen recordings or device data), by whom and why, with a real option to decline |
Add a compliant disclosure in your web app
Mostly web app work; a native rebuild is only needed if you change Config.java.
Find every prompt and data flow
Install the testing build fresh, note each system prompt and the screen it appears on, and list what your web app sends to your backend or to third parties. Compare the list with your Data safety answers.
Stop asking at launch
Remove geolocation calls from page load and trigger them from a button on the feature screen. For push, set
requirePushto false in Config.java and request permission later withregisterpush://, as the Android push documentation describes.Show your own explanation first
A modal in your web app with a plain title, the data, the reason and what happens to the data, plus two buttons: Agree and Not now. Keep the design your own; do not imitate the Android permission dialog.
Trigger the native step only after Agree
Then call the geolocation API,
requestcontactpermission://orregisterpush://. The system prompt that follows is the second, official step.Handle Not now gracefully
The feature should keep working in a reduced form, for example manual address entry instead of location. If the user later wants the feature and the permission was denied for good, open the system screen with
settingsapp://(Open App Settings API).Align the paperwork and resubmit
Update the privacy policy and the Data safety form to match. If only your web app changed, the existing build already shows the fix; if Play Console needs a new release, bump the version code and upload a fresh bundle. Describe the path to the disclosure in your reply.
A reusable disclosure helper
A pattern for any web app running in WebViewGold. Replace showModal with your own dialog component and adapt the texts to what your app really does.
javascript
// Each entry: what you tell the user, and the native step that runs after "Agree".
const DISCLOSURES = {
location: {
title: "Show stores near you?",
body: "To list the pickup points closest to you, this app collects your precise location while you use the store finder. It is sent to our server only to calculate distances and is never shared with advertisers.",
run: () => navigator.geolocation.getCurrentPosition(showNearby, showManualSearch)
},
contacts: {
title: "Find friends from your contacts?",
body: "This app uploads the names and phone numbers in your contacts to our server to show which friends already use it. We never message your contacts and delete numbers without a match within 24 hours.",
// After the grant, navigate to readcontacts:// to fill the contacts variable.
run: () => { window.location.href = "requestcontactpermission://"; }
},
notifications: {
title: "Get order updates?",
body: "We send a notification when your order ships and when it arrives. You can turn this off at any time.",
run: () => { window.location.href = "registerpush://"; }
}
};
function askWithDisclosure(kind) {
const d = DISCLOSURES[kind];
showModal({
title: d.title,
body: d.body,
primary: { label: "Agree", onClick: d.run },
secondary: { label: "Not now", onClick: () => {} } // the feature keeps working without it
});
}
// Trigger from a user action on the feature screen, never on page load.
document.querySelector("#find-stores").addEventListener("click", () => askWithDisclosure("location"));Prompt: let your AI agent wire it up
The agent finds every data flow, adds the dialogs and hands you the sentences for the privacy policy and the Data safety form.
Paste into Claude Code, Cursor, Codex or your builder chat
My web app runs inside an Android app built with WebViewGold. Google Play rejected it for a missing prominent disclosure. Find every place where the app (a) calls navigator.geolocation, (b) navigates to requestcontactpermission://, readcontacts:// or registerpush://, (c) uploads contacts, photos or location to our backend or a third party, (d) loads analytics, session replay or chat scripts. For each item: - Remove any call that runs on page load; trigger it from a user action on the feature screen instead. - Before the call, show a modal from our design system with a short title, which data is collected, why, where it is sent, and two buttons: Agree and Not now. - Run the call only after Agree. On Not now, keep the feature usable in a reduced form. - Do not style the modal like an Android system dialog. Then write a table of every data type, the screen where it is disclosed and the exact sentence used, so I can copy it into the privacy policy and the Data safety form.
Disclosures that still get rejected
- Only in the privacy policy, the terms or the store description.
- Part of a swipe-through onboarding the user can skip without reading.
- Combined with the terms of service behind a single Accept button.
- Shown after the system permission prompt instead of before it.
- Vague wording such as "to improve your experience" without naming the data.
- A banner that disappears by itself, or a dialog where tapping outside counts as yes.
Frequently asked questions
Is the Android permission dialog not enough on its own?
No. The system dialog asks for the permission, but it says nothing about what you do with the data. Google wants your own explanation before it whenever the use may not be obvious, and always for background location.
Can the disclosure be part of my web app instead of native code?
Yes. A dialog rendered by your web app inside the WebView is in-app UI. What matters is that it appears during normal use, right before the data is accessed, and not only on a settings or legal page.
Does the disclosure need an explicit Agree button?
When the Android permission prompt follows immediately, Google's background location guidance treats that prompt as the consent step. For data that no system prompt protects, you need your own affirmative consent. A clear Agree and Not now pair is the safest design in both cases and matches Google's best practices.
Do I show the disclosure every time?
Show it before the first request for each data type and again when the user starts the feature after declining. Respect a decline; repeated prompts annoy users and reviewers alike.
My disclosure is in the privacy policy and the store listing. Why was I rejected?
Because the policy requires it inside the app, before the data is accessed. The privacy policy and the listing are additional requirements, not substitutes.
Does the same apply to my iOS app?
Apple handles it differently, with purpose strings in the system prompt and its own privacy rules. The same in-context dialog works well on both platforms, and the App Store side is covered in the Guideline 5.1.1 guide.
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.
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 pageCloud 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.