Play Store rejections from policy details we keep hitting
The fourth rejection on a field-reporting app came back with "Policy violation — Use of Permissions." The app requests location, camera, and storage. Review flagged all three. We had already submitted a permissions declaration. The problem was not the declaration itself but the gap between what we declared and what the app visibly does when a reviewer walks through it.
Google's review process for apps targeting broad location access runs through a flow where a human tester opens the app, looks for features that justify each permission, and compares against the declared use cases. If the camera permission is declared for "document capture" but the reviewer cannot find a screen where a document is captured, the permission gets flagged. This sounds obvious. In practice, the reviewer often lands on a dashboard or login screen and never reaches the capture flow because it sits behind a role gate or a sync state.
We now build a reviewer path. The first screen after login has a visible button labeled with the exact phrase from the permissions declaration. If we declared "capture delivery proof photos," the button says "Capture Delivery Proof." It does not say "Start Job" or "New Task" — those are too far from the declared language. The reviewer is matching strings, not inferring intent.
The background location policy is the one that bites most often. Apps requesting `ACCESS_BACKGROUND_LOCATION` need to show a foreground service notification while tracking, and the permissions declaration must describe a feature that requires background location specifically — not just "location." We had an app rejected because the tracking feature worked in the foreground and the declaration said "track field staff routes." The reviewer asked: why does this need background location if tracking stops when the app is backgrounded? The answer was that it should not have been requested at all. We removed the permission and kept foreground-only tracking. The app passed on the next submission.
Storage permissions shifted with Android 13. `READ_EXTERNAL_STORAGE` and `WRITE_EXTERNAL_STORAGE` are deprecated for scoped storage. Apps targeting API 33+ that request these permissions get rejected unless they can justify access to broad file collections — media management apps, file browsers. A field-reporting app that saves photos does not qualify. We switched to `READ_MEDIA_IMAGES` and the photo picker. The tradeoff: the picker gives you a content URI, not a file path, so any native module expecting a filesystem path needs a copy step. We added one. It costs about 200ms for a typical photo on the cheap hardware we target, which is acceptable.
The SMS and call log permissions are a near-automatic rejection for any app that is not a default SMS handler or dialer. We had a client ask for call log access to log customer outreach duration. We declined and built a manual call-outcome form instead. The policy is strict enough that the review team does not negotiate on this.
One rejection that took three days to diagnose was for "Misrepresentation." The app had a login screen with no guest access, and the store listing showed screenshots of the full dashboard. The reviewer could not get past login and concluded the app did not match its listing. We added a demo account with limited data to the login screen, with the credentials printed in the review notes. The listing screenshots matched what the reviewer saw after logging in. The app passed.
The review notes field matters more than people expect. We now write a step-by-step walkthrough: tap this button, enter these credentials, navigate to this screen, perform this action. Each step references the permission or feature it demonstrates. A reviewer who has 15 minutes per app will not explore. They follow instructions if the instructions are short and specific.
Submission turnaround on our last three apps was 48 hours, 72 hours, and 6 days. The six-day one passed on first review. The 48-hour one was a resubmission after a permissions fix. Speed of review does not correlate with likelihood of approval. We plan for two review cycles on every app and build the reviewer path before the first submission.