A symptom-tracking health app was rejected from the Android store. Two reasons; one was "Privacy policy under the User Data policy: invalid policy."
I opened the live policy URL and read it from the top. It was another app's document.
When did you last read your app's policy? Not check that the link opens — read it.
What it said
- "Conversation content: text messages and notes entered by the user" — that's a conversational AI app
- "to provide the AI companion's dialogue and responses"
- A conversational-model vendor in the third-party table
- "Not collected: … health data …"
- Payment and sign-in described as Apple-only, with zero mention of Android
The second-to-last line is the problem. Health data is the entire reason this app exists. The real app stores a 35-item symptom catalog, reads sleep and heart rate from the health platform, and sends them to a server.
If the document belongs to another app, "not collected" becomes a false statement — and that itself is the violation. Reviewers compare the policy against the app. This does not get through. Once before, a stranger told me my policy was lying — I hadn't found that one either.
While I was there, I compared the listing too
The short description claimed a feature that doesn't exist. Five locales advertised a particular logging capability; the code had zero fields for it.
Policies and listings come from the same habit: not writing them per app, but using the previous app's document as a template.
What would you do?
You need to verify a policy before submission. What do you compare?
- That the link opens — what I was doing. A 200 meant it passed.
- Read the document — that catches this instance. You'll have to catch it again on the next app.
- Compare it mechanically against the code — hold manifest permissions and actually-stored fields up against the policy text.
The third. Four minimum checks:
- Manifest permissions ↔ does the policy name that data (health permissions are mandatory)
- Fields the app actually stores and transmits ↔ the policy's "collected" list
- Does the policy's "not collected" list contain anything the app actually uses ← most dangerous
- Is the platform description right — Apple-only wording sitting in an Android listing
Number three is worst. An omitted item is incomplete; a wrongly denied item is a false statement.
Three checks
- Did you copy the policy from a previous app? Then read the "not collected" list first. That's where false statements are born.
- Is your policy verification "the link returns 200"? That means the document exists, not that it describes this app.
- Do the features in your store short description exist in code? If the wording differs per locale, you have to check each one.
The honest part
The reviewer found this defect. I didn't. Between building the app and submitting it, I never read the policy once.
Why it happened is clear enough. I built the policy page per app using the previous app's document as a template, and didn't swap out the parts that needed swapping.
And I have not counted how many other app policies were made the same way. When you find one, you're supposed to count the rest. I haven't. I'm publishing this without that number.