Play Store rejections from policy details we keep hitting
A typical rejection on a field-reporting app comes back with "Policy violation — Use of Permissions." The app requests location, camera, and storage. Review flags all three. A permissions declaration was already submitted. The problem is not the declaration itself but the gap between what was 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 have seen this pattern more than once: the tracking feature works in the foreground, the declaration says "track field staff routes," and the manifest still requests background location. The reviewer asks: why does this need background location if tracking stops when the app is backgrounded? The honest answer is that it should not have been requested at all. Remove the permission, keep foreground-only tracking, and the app usually passes 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. The fix is to switch 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. That copy costs a couple of hundred milliseconds for a typical photo on low-end hardware, 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. A request for call log access to record customer outreach duration is one we decline; a manual call-outcome form does the job without the permission. The policy is strict enough that the review team does not negotiate on this.
A rejection that is slow to diagnose is "Misrepresentation." An app with a login screen and no guest access, whose store listing shows screenshots of the full dashboard, will trip it. The reviewer cannot get past login and concludes the app does not match its listing. The fix is a demo account with limited data, with the credentials printed in the review notes, so the listing screenshots match what the reviewer sees after logging in.
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.
Review turnaround varies from under two days to about a week, and speed does not correlate with likelihood of approval. A fast response is often a rejection on something the automated checks caught; a slow one is often a pass after a human walked the whole app. We plan for two review cycles on every app and build the reviewer path before the first submission.