Skip to main content
Compliance

Justifying Sensitive Permissions: Background Location, SMS, Contacts

Permissions that trigger extra Google review and how to justify each one — in your manifest, your in-app prompts, and your store listing.

By Mr. J. Swain, 3000 Studios·8 min read··
permissionsbackground locationsms

Some Android permissions trigger extra Google Play scrutiny — background location, SMS access, contacts, accessibility services. Declaring one of them in your manifest puts your submission in a special review queue, where a human reviewer evaluates whether your justification matches your app's declared functionality. This guide explains which permissions trigger the queue, what justifications work, and how to write the manifest declaration so it survives review.

The sensitive permissions

Google maintains a list of high-risk permissions whose use triggers extra review:

  • Background location (ACCESS_BACKGROUND_LOCATION): collecting location while the app is not visible.
  • SMS (READ_SMS, SEND_SMS, RECEIVE_SMS): reading or sending text messages.
  • Call log (READ_CALL_LOG, WRITE_CALL_LOG): reading or modifying the call history.
  • Contacts (READ_CONTACTS, WRITE_CONTACTS): accessing the device's contact list.
  • Accessibility services (BIND_ACCESSIBILITY_SERVICE): a powerful permission designed for assistive tech that is frequently abused by overlay malware.
  • Manage external storage (MANAGE_EXTERNAL_STORAGE): full filesystem access, mostly deprecated in favor of scoped storage.
  • Package usage stats (PACKAGE_USAGE_STATS): reading which apps the user has used and for how long.
  • Install packages (REQUEST_INSTALL_PACKAGES): triggering installation of other APKs.

What "justification" means

When you declare one of these permissions, Play Console prompts you to fill out a declaration form. You explain: (1) which feature requires the permission, (2) what data is accessed, (3) whether the access happens in the background, (4) whether the data is shared with third parties, and (5) whether there is a less-invasive alternative you considered.

Reviewers compare your declaration to your app's actual behavior (via the AAB's code paths and any test logins they perform). Mismatches result in rejection.

What gets approved

Background location. Approved for: fitness tracking apps that record routes, ride-sharing apps that show driver location, asset-tracking apps for fleets, emergency-services apps. Rejected for: weather apps (use foreground location), social apps that share location periodically (use foreground), generic utility apps with vague location use.

SMS. Approved for: messaging apps that handle SMS as their primary user-facing feature, account-recovery flows for apps where SMS verification is integral, banking apps that read SMS OTPs as a fallback to push notifications. Rejected for: anything else, including apps that "just want to read confirmation codes for the user's convenience".

Contacts. Approved for: communication apps where the user explicitly invites contacts to join, contact-management apps that are the user's primary phonebook. Rejected for: growth-hacking import flows that upload contacts to the developer's servers, social apps that pre-populate friend suggestions from contacts.

Accessibility services. Approved only for: actual assistive technology serving users with disabilities, screen readers, alternative-input apps. Rejected for: automation tools, password managers (use autofill API instead), parental-control apps (use Family Link API).

Call log. Approved for: dialer/contacts replacement apps. Rejected for everything else.

Manage external storage. Approved for: file managers, backup utilities, antivirus apps. Rejected for: any app that could use scoped storage instead.

The runtime UX

Approval at submission is just the first hurdle. At runtime, users see permission prompts and may decline. Your app must handle declined permissions gracefully — disable the dependent feature, show a clear explanation, and avoid asking again immediately.

Prompting for a sensitive permission too early in the user flow (before the user understands why) is a separate policy violation. The recommended pattern: trigger the permission request from the specific UI control that needs it, not from app launch.

How the wizard handles this

The bundle parser reads your declared permissions from the manifest. The compliance check in Step 12 flags any sensitive permission and asks for your justification text. The text gets formatted into the Play Console declaration form when you reach Step 12 (Review), so you can paste it directly when you submit.

Justifying Sensitive Permissions: Background Location, SMS, Contacts · Playstore Wizard · Playstore Wizard