7 Manifest Permissions That Cause App Rejections on Google Play

Google Play reviews your manifest as closely as it reviews your code. A permission that does not match a visible feature can stop a release dead, and a sensitive permission with a weak explanation can send your app into a review queue that lasts days. I have watched solid apps with clean code get bounced for a single line in AndroidManifest.xml, a line the developer had forgotten was even there.

This guide walks through the seven permission patterns that cause the most rejections, with the safer replacement for each one. You will get the exact reasoning reviewers use, the pros and cons of keeping each permission, and a verdict you can act on before your next submission. The goal is simple: a manifest that matches what your app actually does, nothing more.

Read it with your own manifest open. Every section ends with a decision, so by the last paragraph you will know which lines to delete, which to replace, and which to defend with a proper review note.

How Google Play Reviews Manifest Permissions in 2026

Review on Google Play happens in two layers. The automated layer scans the merged manifest, the declared permissions, and the data safety form, then flags anything that looks broad or sensitive. The human layer reads your review notes, watches your video if you attached one, and decides whether the permission fits the feature you claim it serves. A mismatch at either layer can trigger a rejection, and the rejection message usually names the permission, not the code that used it.

The merged manifest is the document that matters. Your source manifest is only the starting point. Libraries, modules, and build variants all add their own entries, and the build system merges them into one final file. Reviewers judge that final file. I once found a location permission in a merged manifest that came from an analytics SDK the app had stopped using months earlier. Nobody on the team had written that line, yet it was ours to defend.

Android 14 and Android 15 tightened the rules further. Photo and video access moved to partial media permissions, background location needs a separate declaration and a video walkthrough, and the Play Console now asks you to justify sensitive permissions in a dedicated declaration form before you can even submit. The bar keeps rising, which is why a permission audit belongs in every release checklist, next to version bumps and changelog notes.

What reviewers actually read in your manifest

Reviewers start with the permission list itself, then look for the feature each permission serves. A camera permission next to a working in-app camera makes sense at once. A call log permission in a recipe app does not, and no amount of clever wording in the listing will fix that gap. They also check whether the permission is requested at runtime, when it is requested, and what the app does when the user says no. An app that breaks completely after a denied permission looks like it never planned for the denial, and that counts against it.

The second thing they read is the data safety form. That form must agree with the manifest. If the manifest declares location access but the form says the app collects no location data, the contradiction alone can trigger a rejection. Keep the two in sync every time you touch either one, and treat a form update as part of the same commit as the manifest change.

The declaration form and why it matters more than the manifest

For the most sensitive permissions, the declaration form carries more weight than the manifest entry. Background location, SMS, call logs, and all-files access each have their own form in the Play Console, and each form asks for a video that shows the feature working. A form with a vague answer, such as better user experience, will not pass. The form wants the feature name, the exact moment the permission is needed, and the user benefit in plain words.

Record the video on a real device, not an emulator, and keep it under two minutes. Show the user opening the feature, the rationale screen appearing, the system prompt, and the feature working after the grant. A video that shows all four moments answers most reviewer questions before they are asked. I keep a short screen recording template for this, so every release with a sensitive permission ships with fresh footage.

Where to find the merged manifest in Android Studio

Open your app module, build the release variant once, then open AndroidManifest.xml and switch to the Merged Manifest tab at the bottom of the editor. That tab shows every permission in the final file and, if you click a line, which library or module contributed it. Check this tab after every dependency update, because that is when surprise permissions appear. A two-minute check here has saved me from at least three rejections I can count.

The 7 Manifest Permissions That Trigger Rejections on Google Play

These seven patterns cover almost every permission rejection I have seen in the last two years. Each one below names the permission, explains why reviewers flag it, gives the pros and cons of keeping it, and ends with a verdict. Work through them in order against your own manifest, and mark each line keep, replace, or delete.

1. ACCESS_BACKGROUND_LOCATION without a foreground feature

Background location is the single most rejected permission on Google Play. It lets an app read location while the user is doing something else, which is a serious privacy power, so reviewers demand a feature that genuinely continues after the user leaves the screen. A running tracker that records a route in the background has that feature. A food delivery app that checks the rider position during an active order has it too. A chat app that reads location once per session does not, and neither does a weather widget that refreshes in the background.

The fix is to use foreground location while the user is active in the app, and to keep background access only for a feature that truly continues without the screen. Describe that feature in the app with a clear rationale screen, show it in the listing in plain words, and record the video walkthrough the declaration form asks for. When no feature truly needs background location, remove the permission entirely. A smaller permission set is easier to defend, and foreground location covers most real use cases.

• Pros: enables live route tracking, delivery tracking, and geofence alerts that keep working after the screen turns off.
• Cons: the strictest review of any common permission, needs a declaration form and a video, and a weak case means a rejection plus a long review queue.
• Verdict: keep it only when a named background feature exists and is visible in the app. Otherwise delete it and use foreground location.

A safer replacement that passes review

Foreground service location with a visible notification covers most tracking features without the background permission. Start the foreground service when the user begins the activity, show a persistent notification that names the activity, and stop the service when the activity ends. Reviewers understand this pattern, users can see it running, and the user can stop it at any time. That transparency is exactly what the review team wants to see.

2. READ_CALL_LOG, READ_SMS, and RECEIVE_SMS for non-core features

Call log and SMS permissions expose private communication data, so Google Play limits them to apps where they are core to the main purpose. A dialer app, a default SMS app, and a spam blocker have a core need. A shopping app that reads SMS only to grab a verification code does not, and a banking app that wants to read transaction SMS usually does not either. Reviewers reject these permissions whenever a safer method exists, and safer methods exist for almost every verification flow today.

Use the SMS Retriever API for automatic verification codes, which reads the code without any SMS permission at all. Use the SMS User Consent API when the code must be read with one tap from the user. Use the system dialer with an intent when the user initiates a call, instead of placing the call directly. Each alternative gives the user the same result with far less data access, and reviewers accept all of them without a fight.

• Pros: direct SMS and call log access makes verification and call history features simple to build.
• Cons: restricted to a short list of core use cases, almost always rejected outside that list, and the declaration process is slow.
• Verdict: delete these permissions from most apps and switch to the SMS Retriever API or a system intent. Keep them only if your app is a dialer, a default SMS app, or a spam blocker.

The SMS Retriever API and other approved alternatives

The SMS Retriever API works with a one-time code that contains an 11-character app hash, and it needs no permission at all. The user never sees a prompt, the code arrives and fills itself in, and the review team has nothing to question because no SMS data is read. For calls, an ACTION_DIAL intent opens the system dialer with the number prefilled, so the user stays in control. Both patterns are documented in the Android developer guides, and both remove the riskiest lines from your manifest.

3. READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE on modern Android

Broad storage access lets an app read files that belong to other apps, so reviewers now expect scoped storage for almost every modern app. An app that reads only its own files should never request broad storage access. An app that edits user photos can use the photo picker, which hands the app exactly the images the user chose. An app that opens documents can use the document picker the same way. A picker gives the user control over which files the app can see, and that control is what reviewers want.

Fix broad storage by moving to the media picker for images and video, the document picker for user-chosen files, and app-specific storage for files only your app needs. Remove legacy storage flags when you target a modern platform version, because a leftover requestLegacyExternalStorage flag on a new target SDK is itself a red flag. Test every file feature after the change, because a picker flow behaves differently from direct file access and your code must handle the user cancelling the picker.

• Pros: broad storage access makes file handling code simple and works the same on every Android version.
• Cons: rejected on modern target SDKs, exposes other apps’ files, and conflicts with the scoped storage rules reviewers now enforce.
• Verdict: replace with pickers and app-specific storage. Keep broad access only for a genuine file manager or backup app, and expect to defend it with a declaration.

4. BIND_ACCESSIBILITY_SERVICE without a real accessibility feature

An accessibility service can read screen content, watch user actions, and control the device, which makes it one of the most powerful permissions in Android. Reviewers treat it as highly sensitive, and they require a real accessibility feature that helps people who need it. A screen reader, a switch access tool, and a voice control feature all qualify. An automation shortcut, a battery saver, or a game helper that uses accessibility access for convenience does not, and those are the cases that get rejected.

Build the accessibility feature first and document how it helps users with disabilities. Show the feature in the app with a clear toggle and a plain explanation of what it does. If the feature can work through a standard API instead, use that API and remove the service. A clear accessibility purpose plus a working feature is the strongest case you can make, and a convenience feature dressed up as accessibility is the weakest.

• Pros: gives deep control over the interface, enables genuine assistive features, and works across apps.
• Cons: the most intrusive permission available, heavily reviewed, and automation use cases are rejected by policy.
• Verdict: keep it only for a real assistive feature with a visible toggle and documentation. Remove it for automation, macros, and convenience shortcuts.

5. REQUEST_INSTALL_PACKAGES and the unknown sources trap

REQUEST_INSTALL_PACKAGES lets an app install other apps, which reviewers associate with sideloading and with stores inside stores. An app store, an enterprise device manager, and a backup tool that restores apps have a legitimate case. A social app that installs a plugin, a game that installs a content pack, and a utility that offers a companion app download usually do not. Reviewers ask whether the install could happen through Google Play instead, and when the answer is yes, the permission is rejected.

When your app genuinely needs to install packages, show the user a clear prompt before the install, explain what is being installed and why, and give the user a way to cancel. Keep the install flow inside the feature that needs it, never trigger it from a banner ad or a background task. Document the flow in your review notes with a video, because a silent install is the exact behaviour reviewers are screening for.

• Pros: enables in-app installation of companion apps, plugins, and enterprise packages without leaving your app.
• Cons: closely watched by reviewers, easily confused with sideloading abuse, and needs a strong justification.
• Verdict: keep it only for stores, enterprise managers, and backup tools. For everything else, link to Google Play and let the Play app handle the install.

6. SYSTEM_ALERT_WINDOW and device admin misuse

Overlay permission lets an app draw over other apps, and device admin access can lock the device and change security settings. Both powers can be abused for lock screens, deceptive screens, and ads that cover other apps. Reviewers reject them when the app purpose does not justify them. A screen filter app that dims the display has an overlay case. A corporate security app may justify device admin access. A wallpaper app cannot justify overlay access for ads, and a cleaner app cannot justify locking the device.

Use these permissions only when no standard method can achieve the feature. Explain the feature in the listing and in the app, provide a clear way for users to remove the permission, and test removal to confirm the app still works for basic features after the permission is gone. An app that keeps working after the user revokes a powerful permission shows reviewers the permission was a genuine choice, not a trap.

• Pros: overlays enable screen filters, chat heads, and floating tools; device admin enables remote lock and wipe for managed devices.
• Cons: both are classic abuse vectors, both need a clear justification, and overlay ads are a fast route to rejection.
• Verdict: keep overlay only for a visible floating feature the user turns on deliberately, and keep device admin only for enterprise or security apps. Delete both from everything else.

7. Permissions declared but never requested at runtime

Some permissions need a runtime request in addition to the manifest declaration. A manifest entry alone does not grant the permission on modern Android, so an app that declares a permission but never requests it leaves reviewers with two questions: why is it declared, and what happens if it is granted? A permission in the listing that never produces a prompt in the app confuses users too, because the listing promises access the app never explains.

Match each manifest permission to a runtime request or remove it. Walk the full flow from first launch to feature use, confirm each prompt appears at a sensible moment, and confirm the app still works when the user denies it. A clean match between manifest and runtime behaviour shows reviewers the app uses permissions deliberately, and it is one of the cheapest wins in this whole guide.

• Pros: declaring a permission early feels like preparation for a feature that is coming soon.
• Cons: unused declarations confuse reviewers and users, bloat the listing, and can trigger a rejection for a feature that does not exist yet.
• Verdict: delete every permission the current release does not request at runtime. Add it back in the release that actually ships the feature.

How to Audit Your Merged Manifest Before Every Release

A manifest audit takes about fifteen minutes and belongs in the release checklist between the final build and the Play Console upload. Open the merged manifest tab, export the permission list, and write one line next to each permission naming the feature that needs it. When you cannot name a feature, mark the permission for removal. When a library contributed the permission, check whether the library still earns its place or whether a smaller library can replace it.

Unused library permissions deserve special attention. An analytics SDK may add network permissions you expect, but a media library may add storage permissions you never asked for, and a crash reporter may add permissions from an old version. Reviewers judge the merged manifest, so an unused library permission can cause a rejection even when your own code is clean. Remove unused permissions with manifest merger rules such as tools:node=”remove” when the library allows it, and record the removal in your release notes so the next review can trace it.

Test permission flows on a real device or an emulator after every manifest change. A removed permission can break a feature that depended on it, and a new prompt can confuse users when the timing is wrong. Ask for each permission only when the user starts the feature that needs it, and test on more than one Android version, because prompt behaviour differs between releases. The walkthrough on Android Studio emulator setup shows how to build device profiles that match your target versions, so a flow that works on Android 15 can be checked against Android 12 before reviewers see it.

Library audits also touch code hygiene beyond permissions. A library that adds permissions silently can also ship hardcoded keys or insecure defaults, so the same audit session is a good moment to review the guide on securing mobile app credentials and move any secret out of the app and into a proper store. Permission hygiene and credential hygiene travel together, and reviewers notice when both are clean.

Keep that table next to your manifest during the audit. When a permission appears in the left column, the middle column tells you what the reviewer will think, and the right column tells you the replacement to build. A permission with no row in the table still needs the same treatment: name the feature, name the safer method, and decide.

uses-permission android:name="android.permission.CAMERA"
uses-feature android:name="android.hardware.camera" android:required="false"

The snippet above is an original example written for this guide. It shows a camera permission paired with a hardware feature declaration marked as not required, so the app can install on devices without a camera and still use the camera where one exists. Use this pairing pattern when a feature needs specific hardware, and remove the feature declaration when the app can work without that hardware. A feature marked required when it is not will limit your device reach for no reason.

Write Review Notes That Help Reviewers Approve Faster

Review notes explain permission choices to the team that reviews the app, and a good note names the permission, the feature that needs it, and the user benefit, in that order. A note should also name the safer alternative you considered and why it did not work for this feature. A reviewer who reads a complete note can approve faster because the reasoning is clear. A note that says only that a permission is needed gives the reviewer nothing to judge, and vague notes are one of the most common reasons a sensitive permission goes back for another round.

Include a short video of the permission flow when a permission is sensitive. A visual record shows the exact moment the app asks for permission, the explanation the user sees before the prompt, and the feature working after the grant. Keep the video short and focused on the permission moment. A long video wastes reviewer time, and a video that never shows the prompt wastes it even more.

Update review notes when permission use changes. A feature that once needed background location may later work with foreground location only, and a note that still claims a background need will confuse a reviewer and may trigger a rejection. Review notes are part of the release checklist and deserve the same update discipline as code. The release checklist also covers the parts of the app that sit beside permissions, such as licence checks. If your app verifies paid licences, the guide on custom licensing and authentication shows how to build that check cleanly, without asking for extra permissions to do it.

When a release includes a crash fix or a performance fix, mention it in the notes too, because a reviewer who sees a stable app is more likely to trust the permission story. The walkthrough on debugging memory leaks with Profiler is a useful companion here: a permission flow that crashes on an older device wastes a review cycle, and a flow that runs clean on the same device does not.

Common Manifest Mistakes That Waste Review Cycles

The most common mistake is copying a manifest from another project without review. A copied manifest can carry permissions the new app never uses, and a fresh review from scratch takes minutes while a rejection costs days. Read every line of the manifest for each project as if it were new, because for the review team it is new.

The next mistake is asking for all permissions at first launch. Early prompts without context feel invasive, they increase rejection risk, and they train users to deny everything. Ask for each permission when the user starts the related feature, and explain the benefit on a rationale screen before the system prompt appears. Contextual requests build trust and improve approval rates on both sides of the review.

Developers also forget to check the merged manifest after a library update, and library permissions can appear silently after an update that changed nothing else. Check the merged output before every release, not just before major releases. A quick check catches surprises early, and a surprise caught before submission is free, while the same surprise caught by a reviewer costs a whole review cycle.

Another mistake is writing vague justifications in review notes. A vague note such as better experience does not explain a sensitive permission. Write the exact feature and the exact user benefit, name the alternative you ruled out, and attach the video. Specific notes help reviewers approve faster, and they protect you when a new reviewer picks up the next release with no memory of the last one.

Frequently Asked Questions About Google Play Permission Rejections

Can I keep a permission for a feature I plan to ship later?

No. Remove permissions for future features and declare a permission only when the current release uses it. Add the permission in the release that actually ships the feature, with the runtime request and the review note written at the same time. A permission with no feature behind it is the easiest rejection in this guide to avoid, and keeping one for later is never worth the risk.

Do permissions added by libraries count in review?

Yes. Reviewers judge the merged manifest, which includes every permission your libraries contribute. Check the merged manifest after every library update, remove unused library permissions with merger rules when the library allows it, and replace a heavy library with a smaller one when the heavy library adds permissions you cannot remove. Record library permission changes in your release notes so future reviews can trace them.

What should I do after a permission rejection?

Read the rejection message and find the permission it names, then decide between removing it, replacing it with a safer method, or defending it with a better note and video. Most rejections are fixed by removal or replacement, not by arguing. Resubmit with clear notes that explain exactly what changed, and attach a fresh video when the permission is sensitive. A resubmission that shows the change usually moves faster than the first review.

How long does a permission review take after I resubmit?

It varies. A simple manifest fix with a clear note can clear in a few hours, while a sensitive permission such as background location or accessibility access can take several days, especially on a first submission. The declaration form, the video, and a complete review note shorten the wait, because the reviewer has fewer questions to send back. Plan your release date around the slower case, not the faster one.

Your Next Step: Clean the Manifest Today

Permission rejections usually come from a mismatch between the manifest and the real features, not from bad code. List each permission, match it to a visible feature, remove the unused ones, and replace broad access with safer pickers and APIs. Your concrete next step is to open the merged manifest today, find one permission with no matching feature, and remove it. Test the affected flow, confirm the app still works, and repeat the audit before your next release. A manifest that survives this audit is a manifest a reviewer can approve without a second look.