Timing beats wording
We have watched install-to-churn spikes tied to a camera permission on the splash screen—before anyone understood why the app needed it. Android’s runtime model is fair: you get one serious ask, then users tap “Don’t allow” and forget you exist. Show value first, then request. If you must pre-declare in the manifest, keep the set minimal and decode what you added with our Android Permissions Decoder so marketing and legal see plain English, not `READ_MEDIA_IMAGES` soup.
Honestly, the copy on your in-app rationale screen matters more than the system dialog text. Two sentences: what you do, what you do not do. No walls of policy links before trust exists.
Product analytics on grant rate mean little if timing is wrong—store reviews say “creepy” weeks before charts move. We screenshot the full flow for compliance reviews so nobody argues about what users actually saw.
Scary permissions and boring ones
SMS, call logs, and broad storage access still spook people even when Google tightens policies. Location is a spectrum: coarse for weather feels fine; background for “deals near you” needs a story. I have seen perfectly good utilities die because they grouped five sensors in one release—users assume malware.
Contrast that with network state or vibration: users ignore them. When we audit manifests before Play upload, we flag “noticeable” permissions and ask whether a less sensitive alternative exists. The decoder output becomes a release-notes input for support teams who will get the angry emails anyway.
Notification access and overlay permissions are the new scary set for utility apps. If you do not need them, do not declare them to impress stakeholders who will never read the manifest.
Denial paths are part of the design
If camera is optional, the scan feature should degrade gracefully, not loop the prompt forever. Settings deep links help, but only after you explain the benefit again. We map each permission to a UI state: granted, denied once, denied with “don’t ask again,” and permanently off in system settings.
QA scripts should include denial flows, not only happy paths. Otherwise your five-star rating craters the week a privacy blogger screenshots your aggressive prompt. We have been that screenshot; it is not fun.
Teach support to recognize “don’t ask again” without making users feel dumb. A short GIF in the help center beats a thousand-word policy page nobody scrolls through.
Ship checklist we actually use
Manifest matches feature set. Rationale screens exist for every risky permission. Prompt appears after intent, not before. Denied state is usable. Support macros explain how to re-enable in Settings. Decoder run attached to the ticket.
Play’s policy moves; user expectations move slower. Treat permissions like onboarding copy—iterate with support transcripts, not only with lint warnings. Your future self on launch day will thank you.
After each release, diff the manifest against the prior build and post the decoder summary in the release channel. Surprises should not reach users before engineering hears about them.