Normal Permission in Android — what it is, protection levels and how it works

What is Normal Permission in Android

Normal Permission is a type of system permission in Android with ProtectionLevel normal, granted to an application automatically at installation time. The developer does not need to write code to request it — just declare the permission in AndroidManifest.xml. The user sees no dialogs and cannot revoke a normal permission separately, only by uninstalling the entire application.

The Android system classifies normal permissions as low-risk — they do not grant access to personal data, camera or microphone. Typical examples: internet access, vibration control, reading Wi-Fi state. According to Android Security Model (2024), about 40 percent of all system permissions belong to the normal category.

An important property — normal permissions cannot be revoked at runtime through Settings. If the user wants to deny access, the only way is to uninstall the application. Developers should consider this in their architecture, but for users this approach simplifies interaction: no dialogs on first launch.

History of the category

The division into normal and dangerous permissions appeared in Android 6.0 Marshmallow (API 23). Before this version, all permissions were requested at installation — the user saw a single list and accepted or declined it as a whole. Normal Permission retained this model for low-risk operations, while Dangerous switched to runtime requests. This change improved user experience and enhanced security at the same time.

Which APIs require Normal Permission

Many Android system APIs require explicit declaration of a normal permission, even if the access is automatic. For example, the ConnectivityManager class requires ACCESS_NETWORK_STATE, VibratorService requires VIBRATE, WifiManager requires ACCESS_WIFI_STATE. Without declaring the corresponding uses-permission, calling these APIs will result in a SecurityException.

How ProtectionLevel normal works

ProtectionLevel normal is the minimum protection level in the Android Permission System. Permissions with this level are declared in the manifest, and the system checks the declaration at installation, granting access without user intervention. No UI elements are shown, no callbacks are invoked.

The verification mechanism works at the PackageManager level. During APK installation, the system scans all uses-permission tags, determines the protection level of each permission by matching against system definitions in permissions.xml files, and for normal-level simply registers the access. The process takes milliseconds and requires no interaction with the user interface.

The granting algorithm works as follows:

• The system reads the manifest at the moment of application installation
• It matches the protectionLevel in /etc/permissions/ on the device
• If the value is normal — automatically grants access
• The permission remains active until the application is completely uninstalled

The user cannot revoke a normal permission through the interface. In the application settings under the Permissions section, only dangerous permissions are displayed. This contrasts with iOS, where every permission requires separate confirmation regardless of the function’s sensitivity level.

Normal Permission vs Dangerous Permission

Normal and Dangerous Permission are two opposite protection categories in Android. The main difference is in the method of granting: normal ones are given automatically at installation, dangerous ones require explicit consent through a runtime dialog. This distinction is built into the Android security architecture starting from version 6.0 Marshmallow.

Comparison of key characteristics:

Difference in user request

The user sees no dialogs when requesting Normal Permission. If an app needs INTERNET — it gets it silently. For Dangerous Permission, the system shows a modal dialog describing the requested access. The user presses Allow or Deny, and can later revoke the permission at any time through Settings. This is a key UX difference that determines the interface development strategy.

When to choose Normal

Normal should be used in all cases where the access does not involve sensitive data. ACCESS_NETWORK_STATE for checking connectivity, VIBRATE for haptic feedback, INTERNET for HTTP requests — all these are normal permissions. Using a dangerous level where normal is sufficient is bad practice, creating unnecessary dialogs and reducing user trust in the application.

List of normal permissions in Android

Android defines several dozen normal permissions, each corresponding to a specific system function. All of them are available through constants of the Manifest.permission class. Below is a list of the most commonly used ones in application development.

Groups of normal permissions

Normal permissions are not grouped into Permission Groups for UI display purposes. Groups in Android are intended for the settings screen, where only dangerous permissions are shown. However, normal permissions can logically be divided into categories: network (INTERNET, ACCESS_NETWORK_STATE), hardware (VIBRATE, WAKE_LOCK), system (SET_ALARM) and Bluetooth permissions.

Some constants from Manifest.permission may change their protection level on different Android versions. For example, BLUETOOTH_CONNECT on Android 12+ became a dangerous permission with a runtime request, although on older versions it was normal. Developers are advised to check the current protectionLevel for the target API through the documentation.

Checking Normal Permission via PackageManager

A developer can programmatically check whether a permission is normal via PackageManager. The getPermissionInfo method returns PermissionInfo whose protectionLevel field contains the PermissionInfo.PROTECTION_NORMAL flag. This is useful for dynamic handling and debugging.

fun isNormalPermission(permission: String): Boolean {
    val pm = packageManager
    val info = pm.getPermissionInfo(
        permission,
        PackageManager.GET_META_DATA
    )
    return info.protectionLevel ==
        PermissionInfo.PROTECTION_NORMAL
}

How to declare Normal Permission in the manifest

Declaring Normal Permission in AndroidManifest.xml is the simplest operation, requiring just one uses-permission tag. No additional protectionLevel configuration is needed, since the protection level is determined by the system definition, not by the application manifest. The developer simply specifies the full constant name.

<!-- AndroidManifest.xml -->
<uses-permission
    android:name="android.permission.INTERNET" />
<uses-permission
    android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission
    android:name="android.permission.VIBRATE" />

The system processes all declarations at installation. If at least one of the declared permissions has a protectionLevel different from normal, a runtime request will be required. INTERNET is the most popular normal permission, present in most Android applications, especially those that make HTTP requests or load content from the network.

Example of a complete manifest

A complete example of AndroidManifest.xml with normal and dangerous permissions demonstrates the difference: syntactically the uses-permission tags are the same, but at runtime INTERNET and VIBRATE will be granted automatically, while CAMERA will require a dialog.

<manifest
    xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.VIBRATE" />

    <!-- Dangerous permission -->
    <uses-permission
        android:name="android.permission.CAMERA" />
</manifest>

Manifest Merger and Normal Permission

When using libraries — Google Play Services, Firebase, Glide — they may add their own uses-permission entries to the final manifest via Manifest Merger. Some of them are normal (INTERNET for Firebase), others are dangerous (ACCESS_FINE_LOCATION for Google Maps). The developer should check the final merged manifest in build/outputs/logs/manifest-merger-report.txt before publication.

Limitations of Normal Permission

Normal Permission has two fundamental limitations: the inability for the user to revoke it and the absence of a management UI. If the user does not trust the application but the normal permission has already been granted automatically — the only solution is to uninstall the application. This creates a certain risk since normal permissions cannot be blocked by standard Android means.

An additional limitation appears on devices with multiple profiles (Work Profile, Multiple Users). Normal Permission is granted to all profiles at once — the application cannot restrict the permission to just one. In enterprise scenarios this is addressed through Managed Configurations.

It is impossible to check whether an application is using a Normal Permission at a given moment. The system method checkSelfPermission works only for dangerous permissions. For normal ones it always returns PERMISSION_GRANTED, which does not reflect actual activity. This should be considered during security audits and application behavior analysis.

It is also worth remembering that some device manufacturers (Xiaomi, Huawei, Samsung) modify the standard permission behavior. On their firmware, Normal Permission may require additional permissions in the proprietary MIUI or EMUI shell. Developers are advised to test on real devices from different vendors.