What is a dangerous permission in Android?

A dangerous permission gives an app access to private user data or device features that could affect your privacy or cost you money, for example CAMERA, ACCESS_FINE_LOCATION, or READ_CONTACTS. Android requires the app to ask you at runtime before using these.

What is the difference between a normal and a dangerous permission?

Normal permissions cover low-risk features like INTERNET or VIBRATE; Android grants them automatically at install time without prompting you. Dangerous permissions cover sensitive data or hardware and must be accepted by you at runtime before the app can use them.

What is a signature permission?

A signature permission is only granted to apps signed with the same certificate as the app that declared it, usually the OS itself. Third-party apps cannot obtain signature permissions through the normal request flow.

Dev

Android Permissions Explained

Search any Android permission to see its protection level, group, and plain-English explanation. Click any row to copy the full permission constant.

Runs locally
Works offline
No sign-up

Permission lookup

What each permission grants

Permission	Level	Group	What it does
Loading permissions...

All lookups run on-device against bundled data. Nothing is uploaded.

About this tool

This tool lists the most common Android permissions alongside their protection level, permission group, and a plain-English explanation of what the permission actually lets an app do. Search by name or description, then filter by protection level to narrow things down.

Click any row to copy the full permission constant (for example android.permission.CAMERA) to your clipboard, handy for dropping straight into a manifest.

Protection levels

Normal: Low-risk permissions that Android grants automatically at install time. You are not asked to approve them individually. Examples: INTERNET, VIBRATE.
Dangerous: Permissions that touch private data or hardware. Android shows a runtime dialog and the user must explicitly grant them. Examples: CAMERA, ACCESS_FINE_LOCATION, READ_CONTACTS.
Signature: Only granted to apps signed with the same certificate as the declaring app, usually the OS or a device OEM. Third-party apps cannot obtain these. Examples: WRITE_SECURE_SETTINGS, INSTALL_PACKAGES.

Tips for developers

Declare every permission your app uses in AndroidManifest.xml under <uses-permission>.
Request dangerous permissions at runtime with ActivityCompat.requestPermissions() and handle the denial gracefully.
On Android 13+ use the granular media permissions (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO) instead of READ_EXTERNAL_STORAGE.
Declare ACCESS_BACKGROUND_LOCATION only if you genuinely need background location access. The Play Store reviews this carefully.
POST_NOTIFICATIONS became a runtime permission in Android 13 (API 33). Apps targeting API 33+ must request it explicitly.

About Android App Permissions

Every Android app runs in a sandbox. To reach outside that sandbox (to use the camera, read your contacts, or access your location), an app must declare which permissions it needs, and for sensitive operations it must also ask you at runtime. That two-step model (manifest declaration plus runtime request) is how Android keeps apps from quietly accessing data they have no business touching.

How protection levels work

Android assigns every permission one of several protection levels. Normal permissions cover features with minimal privacy risk and are granted automatically when you install the app. Dangerous permissions cover data or hardware that could affect your privacy or cost you money; Android shows you a dialog and you choose to grant or deny each one. Signature permissions are reserved for the OS and OEM system apps. A third-party app cannot obtain them through any user-facing flow.

Permission groups

Dangerous permissions are organized into groups such as Location, Camera, Contacts, and Storage. When you grant one permission in a group, Android may automatically grant others in the same group without asking again, though that behavior has become stricter in recent Android releases. Understanding groups helps you explain to users why your app needs certain combinations of permissions.

Changes in recent Android versions

Android has tightened permission controls with each major release. Android 10 added background location restrictions. Android 11 introduced one-time permissions. Android 12 split Bluetooth into finer-grained permissions. Android 13 replaced the broad external storage permission with media-type-specific ones and added POST_NOTIFICATIONS as a runtime permission. Keeping up with these changes is essential if you want your app to pass Play Store review and work correctly across devices.

Frequently asked questions

What happens if I deny a dangerous permission?

The app must handle denial gracefully. It should not crash or become unusable. If the feature requiring the permission is optional, disable only that feature. If it is core to the app, show a clear explanation and a button to open settings so the user can grant it manually.

Can an app use a permission without declaring it?

No. Android enforces permission checks at the system level. If a permission is not in the manifest, the system denies the call and throws a SecurityException. The app cannot bypass this restriction.

What is ACCESS_BACKGROUND_LOCATION and why is it special?

ACCESS_BACKGROUND_LOCATION lets your app read location even when it is not visible to the user. Google Play scrutinizes it closely and may reject apps that request it without a compelling use case. You must also declare the foreground location permission (ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION) alongside it.

How do I check which permissions an installed APK requests?

Use aapt dump permissions your-app.apk or open the APK in Android Studio's APK analyzer. You can also run adb shell dumpsys package com.your.package on a connected device to see granted and requested permissions at runtime.