By default, an Android application cannot do anything meaningful outside its own sandbox. It cannot reach the network, read a file, or vibrate the device. This strict isolation protects users from malicious code. When an application needs to break out of this sandbox, it must declare a permission. Not all breakouts carry the same risk. The Android framework categorizes permissions by protection levels, which dictate exactly when and how the system grants access.
Why Some Permissions Are Automatic
Bothering the user with a dialog every time an application wants to vibrate the device would cause alert fatigue. Users would quickly learn to blindly accept every prompt. The platform needs a way to grant low-risk capabilities without friction.
These capabilities fall under the normal protection level. Examples include checking network status, setting an alarm, or connecting to the internet. The risk to user privacy or system stability is minimal.
If an application declares a normal permission in its manifest, the system grants it automatically at install time. The user never sees a prompt. The permission cannot be revoked through the system settings. The system still tracks the capability internally, but automatic approval is deemed safe.
Because the system grants normal permissions silently, you might wonder how Android handles access to truly sensitive data. That requires a completely different mechanism.
When the User Must Decide
When an application wants to read SMS messages, track location, or record audio, the privacy implications become severe. The system cannot safely make this choice on behalf of the user. The platform must pause and ask for explicit consent.
These are dangerous permissions. Historically, Android granted these at install time as an all-or-nothing proposition. Starting with Android 6.0, the model shifted to runtime permissions, giving users granular control over sensitive data while actively using the application.
The following sequence diagram illustrates what happens when an application requests a dangerous permission. You will see how the framework handles the request by communicating with a dedicated permission controller. Pay attention to how the asynchronous result flows back to the application.
An application explicitly calls a request function in its code. The framework displays an out-of-process dialog to the user while the application continues running. The result arrives later through a dedicated callback method. This allows the application to react to the user's decision.
Users retain ultimate control over these dangerous permissions. They can navigate to the system settings and revoke access at any time. This runtime model works well for third-party apps, but the core Android OS requires access to internal APIs that cannot be exposed to standard applications.
Establishing Trust with Cryptography
The Android operating system consists of many discrete applications. Components like SystemUI draw the status bar, while Settings manages device configuration. These core components need deep system access to function. If a regular third-party app could access those same APIs, it could completely compromise the device.
The platform solves this problem using signature permissions. These represent the most restrictive protection level in the framework.
The system only grants a signature permission if the requesting application holds the exact same cryptographic signing certificate as the package that defined the permission. Because the framework package defines most internal system APIs, only apps signed with the platform key can access them. This mechanism allows the core platform to share powerful APIs among its own components while locking out third-party developers entirely.
Interview Note: If you are asked how Android secures internal IPC calls between system services, signature permissions are the primary answer. The framework checks the caller's UID and verifies the signing certificate before fulfilling the request.
Sometimes an equipment manufacturer wants to bundle a custom application that needs deep access, but they do not want to sign it with the core platform key. That specific scenario requires an extension of the signature model.
Controlling Manufacturer Bundles
When an equipment manufacturer builds a custom dialer or a specialized hardware companion app, they need system-level access. However, signing every bundled app with the core platform key violates the principle of least privilege. The framework needs a way to grant specific system permissions to specific pre-installed applications without sharing the master key.
This requirement birthed signature|privileged permissions, commonly referred to as privileged permissions. These provide a secure middle ground between system-signed apps and regular third-party apps.
The system evaluates two strict conditions before granting a privileged permission. First, the application must be physically located in a specific trusted partition, such as /system/priv-app/ or /vendor/priv-app/. Second, the manufacturer must explicitly allowlist the requested permission in an XML file on the device filesystem.
If a privileged application requests a privileged permission that is not explicitly present on the allowlist, the system responds aggressively. The device will either refuse to boot entirely, or the application will crash on launch. This guarantees strict manufacturer control over the capabilities of pre-installed software.
The permission model ultimately scales from harmless automatic grants to cryptographically verified platform access. Normal permissions keep the user experience smooth, while dangerous permissions protect sensitive data. Signature and privileged permissions ensure the core OS remains completely isolated from untrusted code. Understanding these boundaries is critical before exploring how the system enforces these rules across process boundaries.