Decode Android permissions from a manifest snippet

When to use this — and when not to

Use it when you have a text list of permissions — from source AndroidManifest.xml, a merged manifest, or aapt output — and you want a readable report before a Play policy pass or a UX review of runtime dialogs. Pair it with the permissions users actually notice post when you are trimming dialogs.

Do not use it as Play Console. Google’s review looks at declared permissions plus how the app uses them, Data safety answers, and restricted permissions (SMS, Call Log, All files access). This page cannot see your APK, your code, or your store listing. It also cannot decode a binary manifest inside an APK — use the APK Analyzer for structure, then paste text here.

How it works in this browser

The registry is a JavaScript array shipped in android-permissions-decoder.js — on the order of forty common platform constants (INTERNET through REQUEST_INSTALL_PACKAGES, including Android 12 Bluetooth and Android 13 media/notification permissions). Search filters that array. Decode scans the textarea with a regex for android.permission.* and uses-permission names, then looks up each hit. Unknown names are labeled unknown. Nothing is sent to a server.

Levels in this table follow the usual platform grouping we assigned in the list: normal (install-time), dangerous (runtime), special (settings / policy), signature (same-signer). These labels are a teaching map, not a dump of PackageManager for your targetSdk. A permission’s protection level has moved across API releases — verify against the docs for the SDK you ship.

Failure modes: OEM permissions (com.huawei.*, com.samsung.*) will show unknown. Custom permissions you declare in your own manifest will show unknown. Typo’d names (ACCESS_FINE_LOCATON) will not fuzzy-match. Pasting binary AXML garbage will match nothing useful.

Worked example

Paste:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.READ_SMS" />
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

Expect INTERNET as normal / Network (almost every app; users never see a dialog). CAMERA as dangerous — you need a runtime prompt and a reason that matches a camera feature. READ_SMS as dangerous / SMS — this is the permission that still triggers Play restricted-permission review if you are not a default SMS handler. POST_NOTIFICATIONS as dangerous on API 33+. A flashlight app with READ_SMS in that paste is the review you want to fail on your desk, not in the console.

Mistakes people make

• Leaving leftover library permissions in the merged manifest (ads, analytics, file pickers) and assuming “the decoder said normal, so we are fine.”
• Confusing uses-permission with uses-feature. CAMERA as a feature can filter the Play catalog; as a permission it gates the API.
• Declaring READ_EXTERNAL_STORAGE on a high targetSdk and expecting it to behave like Android 10. Scoped storage changed the meaning.
• Treating MANAGE_EXTERNAL_STORAGE (“All files access”) as just another dangerous permission. It is special and policy-gated.

How this differs from the official docs and Play Console

• developer.android.com is the source of truth for protection level and runtime behavior per API.
• Play Console / policy center decides whether SMS, Call Log, and All files access are allowed for your category.
• This page is a local lookup so you can read a pasted list in one pass and copy a report into a PR.

Related

APK analysis guide · Manifest Validator · APK Analyzer

Frequently asked questions