What is the difference between normal and dangerous permissions?

Normal permissions cover low-risk capabilities and are granted automatically at install with no user prompt. Dangerous permissions touch private data or sensors, so on Android 6.0 and later your app must request them at runtime and the user can deny or revoke them.

Which permissions need a runtime request?

Only dangerous permissions need requestPermissions at runtime, such as CAMERA, ACCESS_FINE_LOCATION, RECORD_AUDIO and READ_CONTACTS. Normal and signature permissions are granted without a prompt when declared in the manifest.

What are permission groups?

Dangerous permissions are organized into groups like LOCATION, CAMERA and CONTACTS. Granting any permission in a group historically granted the rest, but since Android 11 each permission is requested individually even within a group.

What is a signature permission?

A signature permission is granted only to apps signed with the same certificate as the app that defines it. It is used for trusted inter-app communication and cannot be obtained by an unrelated third-party app.

Do I still declare dangerous permissions in the manifest?

Yes. Every permission your app uses, dangerous or not, must be declared with a uses-permission element in AndroidManifest.xml. The manifest declaration plus a granted runtime request are both required for dangerous permissions to work.

What is the Android Permissions Reference?

Searchable Android permission reference: common manifest permissions with their protection level (normal, dangerous, signature), the runtime-request requirement, and the permission group each dangerous permission belongs to. It runs free in your browser on Gera Tools, with nothing uploaded.

Android Permissions Reference

Name: Android Permissions Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Android permissions by protection level

Android gates sensitive capabilities behind permissions, each carrying a protection level that decides how it is granted. Normal permissions are auto-granted at install; dangerous ones require a runtime prompt the user can deny; signature permissions are limited to apps signed with the same key. This searchable reference lists common permissions with their level, group and runtime requirement.

How permissions are granted: the three-level model

Understanding which permissions need which treatment saves significant debugging time:

Normal permissions are declared in AndroidManifest.xml and automatically granted at install with no user interaction. They cover capabilities with limited privacy risk, such as INTERNET, ACCESS_NETWORK_STATE, or VIBRATE. Users do not see these in any prompt.

Dangerous permissions touch private data, device sensors, or capabilities that could be misused. They require both a manifest declaration and a runtime request that presents a dialog to the user. Examples include CAMERA, ACCESS_FINE_LOCATION, READ_CONTACTS, and RECORD_AUDIO. Users can grant, deny, or revoke these at any time in system Settings.

Signature permissions are a special case used for trusted inter-app communication. They are only granted to apps signed with the same certificate as the app that defined the permission. A third-party app can declare a signature permission in its manifest, but it will not be granted unless its signing key matches.

How it works

Declare every permission in the manifest, then request dangerous ones at runtime:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

if (checkSelfPermission(Manifest.permission.CAMERA) != PERMISSION_GRANTED) {
  requestPermissions(arrayOf(Manifest.permission.CAMERA), REQ_CODE)
}

A normal permission is granted at install with no prompt. A dangerous permission also needs the user to approve the runtime request, and they can revoke it later in Settings, so always check checkSelfPermission before use.

Key changes from Android 6 to Android 13+

Android has tightened permissions substantially across major versions. Knowing which version introduced which restriction helps you target the right minimum SDK:

Android 6 (API 23): Dangerous permissions moved from install-time to runtime. Apps targeting API 23+ must request them with requestPermissions.
Android 10 (API 29): ACCESS_BACKGROUND_LOCATION became a separate, distinct permission from ACCESS_FINE_LOCATION. An app can have foreground location without background; getting background requires an additional prompt with an explicit “Allow all the time” option.
Android 11 (API 30): Permissions can be auto-reset if the app is unused for several months. Also introduced one-time permission grants for location, camera, and microphone.
Android 12 (API 31): BLUETOOTH_SCAN and BLUETOOTH_CONNECT replaced the old BLUETOOTH permission for most BLE use cases, requiring runtime requests.
Android 13 (API 33): READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, and READ_MEDIA_AUDIO replaced READ_EXTERNAL_STORAGE for accessing media. Notification posting (POST_NOTIFICATIONS) became a dangerous permission requiring a runtime request.

Tips and notes

Request a dangerous permission only at the moment the feature that needs it is invoked — not at app launch. Users are more likely to grant a permission when the reason is obvious from context.
Since Android 11, each permission is granted individually even within a group. Granting ACCESS_FINE_LOCATION does not automatically grant ACCESS_BACKGROUND_LOCATION in the same request.
Always handle denial gracefully. Degrade the feature rather than crashing or showing an unhelpful error. If the user permanently denied a permission, shouldShowRequestPermissionRationale returns false, signalling that you should direct them to Settings rather than showing another system dialog.
Background location (ACCESS_BACKGROUND_LOCATION) requires a separate, stricter flow and Google Play review for apps that need it. Request foreground location first; then, only if truly necessary, request the background permission separately.
uses-feature declarations in the manifest signal to the Play Store which hardware your app requires. If you declare CAMERA permission, you should also check whether to add <uses-feature android:name="android.hardware.camera" android:required="false" /> so your app remains visible to devices without a camera when the camera feature is optional.