Because Android merges manifests. At build time Gradle combines your manifest with the manifests of every library into one file, so an SDK can add permissions you never wrote. Open the Merged Manifest view in Android Studio to see them, and remove the ones you do not need with tools:node="remove".
How the merge works
Android's documentation says a project can have several manifests: main, build variant, build type, product flavors and imported libraries. The manifest merger combines them into one AndroidManifest.xml, merging the lowest priority file into the next highest until one remains.
Priority, highest first: the build variant, build type and flavor manifests, then the app module's main manifest, then library manifests in the order they appear in your dependencies block.
Matching elements are combined. Your app inherits everything a library declares unless you say otherwise.
Why this matters for security and store review
Each permission widens what your app can do and what you must explain. Google's Data safety documentation says you are responsible for declarations that include data handled by third-party libraries and SDKs. A permission you did not know about is a disclosure you may get wrong.
How to see it
- Open
AndroidManifest.xmlin Android Studio. - Click the Merged Manifest tab.
- Click a permission to see which file contributed it under Merging Log.
- For the full decision record, read the manifest merger report in your module's build outputs logs folder.
How to remove one
In your own manifest, declare the tools namespace and mark the element for removal, as Android's documentation shows:
<uses-permission android:name="android.permission.READ_PHONE_STATE"
tools:node="remove" />
You can add tools:selector with a library's package name to restrict the removal to that library. Test afterward. If the SDK needs that permission for a feature you use, removing it will break the feature or cause a crash.
A review routine for each release
| Step | Question to answer |
|---|---|
| Compare merged manifests between releases | Did a dependency update add a permission? |
| Trace each new permission | Which library added it? |
| Ask whether you use the feature | If not, remove it |
| Update your store declarations | Do they still match? |
A permission diff is a cheap check that catches a quiet scope change after a library bump.
Quick check
Can I trust that an SDK only asks for what it needs?
Not automatically. Review the merged result and ask the provider about anything unexpected. The Play SDK Index also lists permissions for covered SDKs.
Does removing a permission fix a vulnerability?
It reduces what the app can do if abused, but it is not a patch. Vulnerable libraries still need updating.
Safeguard works on the dependency and SBOM side, showing which libraries are in a build and which carry known advisories, which tells you where to look first when a permission changes. It does not analyze compiled mobile binaries. See the free scan.
Sources
- Android Developers: merge multiple manifest files
- Google Play Help: Data safety section
- Android Developers: Google Play SDK Index
Last reviewed: 19 October 2026.
