Every permission your Android app requests is something a user can see, question, and deny, and something Google Play expects you to justify. The principle that keeps you out of trouble is least privilege: ask for only the permissions your features actually use, request them in context, and handle a denial gracefully. Over-requesting erodes user trust, invites scrutiny, and with high-risk permissions can get your app removed. AI-built apps and copied templates often request more than they need. Here is how runtime permissions work and how to keep your requests minimal.
Short answer
Android runtime permissions require your app to request dangerous permissions, like camera, location, microphone, and contacts, at runtime, where the user can grant, deny, or later revoke them. Per Android's permissions guidance, you should follow least privilege: request only the permissions your features genuinely need, ask in context with a clear reason, and handle denial without breaking the app. Over-requesting harms privacy and user trust, and high-risk permissions such as background location or SMS access require justification to Google Play or your app is removed. Request the minimum, prefer narrower options where they exist, and do not inherit permissions from SDKs you do not need.
What you should know
- Dangerous permissions are requested at runtime: the user grants or denies them.
- Least privilege is the rule: request only what your features use.
- Ask in context with a reason: not all at once on launch.
- Handle denial gracefully: the app must work, or degrade, without it.
- High-risk permissions need justification: or Google Play removes the app.
How do Android runtime permissions work?
Sensitive permissions are granted by the user at runtime, not silently at install. Android classifies permissions, and the dangerous ones, those touching private data or sensors like the camera, microphone, location, and contacts, must be requested at runtime, prompting the user to allow or deny. The user can also revoke a granted permission later in settings, and the system can auto-reset permissions for apps left unused, so you cannot assume a permission stays granted. Newer versions add finer control: one-time permissions, approximate rather than precise location, and granular media access instead of a single broad storage permission. The practical consequence is that permissions are a negotiation with the user, not a given, so your app has to request them deliberately and cope with whatever the user decides.
Least privilege: requesting only what you need
Ask for the narrowest set that supports your features. The table shows the mindset.
| Practice | Why it matters |
|---|---|
| Request only permissions your features use | Fewer requests, more trust, less scrutiny |
| Ask in context, when the feature is used | Users understand and grant more readily |
| Prefer narrower options | Approximate location or granular media over broad access |
| Avoid SDK-driven permissions you do not need | A dependency can pull in permissions you never use |
| Drop unused permissions | Remove anything no current feature requires |
The discipline is to map each permission to a feature a user can see, and to drop any permission that does not map to one. Requesting a permission your app does not visibly use looks like overreach to users and to Google Play, and it expands what a compromise could touch. Narrower options, like approximate location when you do not need precise, reduce both the privacy impact and the friction of getting a yes.
How do you handle denial and high-risk permissions?
Design for denial, and justify or avoid high-risk permissions. Assume any permission can be denied or revoked, and make your app degrade gracefully rather than crash or block, offering the feature when permission is granted and a reasonable fallback when it is not. For high-risk permissions, background location, SMS or Call Log access, and similar, Google Play requires that your app's core functionality genuinely needs them and that you justify them, often through a declaration, or the app is removed, so do not request these unless they are central to what your app does. Watch SDK-driven permissions too, since an ad, analytics, or maps library can add permissions to your manifest that you did not intend, which both surprises users and can trip Play policy. The goal is that every permission is necessary, justified, and survivable when denied.
What to watch out for
The first trap is requesting permissions on launch or in bulk rather than in context, which lowers grant rates and looks like overreach. The second is a high-risk permission without the core-function justification Google Play requires, which can get the app removed. The third is a dependency adding permissions you do not need; audit your manifest for permissions no feature uses. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces the permissions your app declares, so you can spot over-requested or SDK-driven permissions that do not match your features before you ship. Trimming the manifest to least privilege is the fix.
What to take away
- Android requires dangerous permissions to be requested at runtime, where users can grant, deny, or revoke them, so permissions are not guaranteed.
- Follow least privilege: request only the permissions your features use, ask in context, and prefer narrower options like approximate location.
- Handle denial gracefully, and only request high-risk permissions like background location or SMS if your core function needs them and you can justify them to Google Play.
- Audit for SDK-driven and unused permissions, and use a pre-submission scan such as PTKD.com to confirm your declared permissions match your features.
