Blocks submissionGoogle Play

Every restricted permission declared meets its own condition: default handler, review, declaration, or core purpose

What is checked This rule is decided by code from the built app and the listing: android.built.manifest, listing.text.

Applies to every app

Checked from built, not yet uploaded, on a test track, submitted and in review, published

The rule, in our words

• Permissions and APIs that Access Sensitive Information: Request a sensitive permission only for a current feature promoted in the listing, ask in context, use the data only as consented and never sell it. Restricted permissions carry extra conditions: honour a refusal and keep the app usable; SMS and call-log permissions only while the app is the default SMS, Phone or Assistant handler, and never derived by other means; location should be requested at the minimum scope, never solely for ads or analytics, foreground-service location only as a user-initiated action that ends when done, background location only for a core user-benefiting feature and with a Play Console declaration; all-files access only after passing Google's review and with a clear prompt to enable it; QUERY_ALL_PACKAGES only for named interoperability use cases and never sold for ads or analytics; the accessibility API never to change settings without permission or defeat platform controls, documented in the listing, and, unless the app is a genuine accessibility tool flagged isAccessibilityTool, with a console declaration, in-app disclosure and consent; REQUEST_INSTALL_PACKAGES only where sending, receiving or user-initiated installing of packages is core, and not for self-update except for device-management purposes; body sensors (granular health permissions from Android 16) and Health Connect under the User Data and Health apps policies and approved use cases; VpnService only for VPN apps and listed exceptions, documented in the listing, encrypted, never for traffic manipulation; USE_EXACT_ALARM only for alarm, timer or calendar apps, others should evaluate SCHEDULE_EXACT_ALARM instead; USE_FULL_SCREEN_INTENT on Android 14+ auto-granted only to alarm and call apps, others must ask the user; photo and video permissions on Android 13+ only where the photo picker is not enough, with a declaration; Age Signals data only for legal compliance. A location-button minimum scope and a Contacts Permissions policy take effect January 27, 2027.

Okkok never stores the stores' text. Each item above is our paraphrase, and the link is the page it rests on, verified unchanged by fingerprint on every run.

The other store

• Google's rule covers permissions generally; Apple's names push notifications specifically (and 5.1.2 extends to location and tracking). partial
• none on principle; Google adds per-permission conditions (SMS, call log, all-files, QUERY_ALL_PACKAGES, accessibility, exact alarms) and console declarations; Apple adds purpose-string content rules. same
• Google allows installed-app visibility for named interoperability use cases; Apple bans the collection for analytics or marketing without a listed exception. partial
• Google gates health APIs behind approved use cases; Apple bans specific downstream uses (advertising, data mining, iCloud storage of personal health information, writing false data). partial

Check your app

pip install git+https://github.com/petresandu-cloud/okkok
okkok audit path/to/app

The report names this rule as google.restricted-permissions and says what to do, who does it, where, and how it knows.