The tripwire
Google Play's Financial Services policy has a General Requirements section that most people skip, because they read the category list, conclude "we don't lend money or take custody of funds", and move on. That section explicitly scopes in:
accessory loan or credit apps (loan calculators, loan guides, etc.)
So a pure calculator — no money movement, no account linking, no payment instruments, no order entry, no brokerage, no lending — can still be classified as an accessory loan app on the strength of shipping a mortgage or auto-loan calculator. Reviewers are not obliged to accept your self-classification.
The consequence is not a form field. Apps in that scope are prohibited from declaring a set of permissions, including:
READ_MEDIA_IMAGESREAD_CONTACTSACCESS_FINE_LOCATIONQUERY_ALL_PACKAGES
(plus others; read the live policy — the list has changed and will change.) This is an app-wide constraint triggered by one feature, and it can collide head-on with an unrelated roadmap item: "let users pick a screenshot from their gallery" is the obvious way to build an import flow, and it is exactly the permission that gets you rejected.
Why this is easy to get wrong in both directions
Under-declaring looks safe and is not. If your store listing describes mortgage/retirement calculators and an AI money assistant, and your Financial Features declaration says "no financial features", that is a visible discrepancy between two things Google reads together — and Play's remedy for an inaccurate declaration is enforcement, not a request to correct it. For a decision-support/calculator app with personalized output, the honest answer was a single selection: Support services -> Financial advice, since the policy scopes itself to services "related to the management or investment of money … including personalized advice". No documentation upload was required (that is triggered by the personal-loan categories, not by this one).
Over-declaring is also costly: selecting lending/custody/brokerage categories you don't belong to invites a documentation request and a specialist review queue you cannot schedule around.
Procedure
- Read the General Requirements section, not just the category list. The category list answers "what am I", the General Requirements answer "what am I now forbidden from doing".
- Pull the option list live rather than from memory. These policies are revised; an answer sheet written from recall will be wrong in a way that is hard to notice. (Category and target-audience option lists both come from live Google support pages.)
- Audit the MERGED release manifest, not the source manifest.
AndroidManifest.xmlin your source tree understates the real permission set, because dependencies inject permissions at merge time. Readapp/build/intermediates/merged_manifest/release/**/AndroidManifest.xmlafter a real build. A permission a transitive dependency adds is still yours as far as review is concerned. - Check whether you can avoid the permission entirely. Image upload through a WebView file picker (or the Android photo picker) needs no media permission, so a screenshot-import feature and this policy can coexist — but only if you never reach for
READ_MEDIA_IMAGESas the default implementation. - Write the ban list into the repo as a standing rule, not into a one-off submission doc. The person who adds
READ_CONTACTSin six months for a referral feature will not be reading the Play checklist.
Generalization
Store policies gate on capability described, not on architecture. A feature can pull a whole app into a stricter regime while every internal reasoning path says "that rule isn't about us" — and the resulting constraint is a permission denylist, i.e. it lands on code unrelated to the feature that triggered it. Check what regime your listing copy puts you in, then check what that regime forbids app-wide.