Android permissions

Android permissions provide controls that increase user awareness and limit an app’s access to sensitive data. Configuring permissions on Android 8.0 and lower includes allowlisting, without which privileged apps are disabled, even if they’re in the priv-app path. On Android 9 and higher, a device that tries to use apps that aren’t properly allowlisted won’t boot.

Android 10 introduced the concept of a role, a unique name within the system associated with certain requirements and privileges. Assign roles to apps to grant them permissions for a specific purpose, and configure default roles using platform config resources.

The increased protections against Potentially Harmful Apps (PHAs) improve:

• Transparency into potentially harmful app behavior.
• User control over app behavior.
• App developers' discretion when using private data, protected by permissions.

Package install and permission

In Android 9 and lower, the package install and permission control functionalities were contained in the PackageInstaller package (//packages/apps/PackageInstaller). In Android 10 and higher, the permission control functionality resides in a separate package, PermissionController (//packages/apps/PermissionController). Figure 1 illustrates where the two packages reside in Android 10.

Figure 1. Package install and permission-control functionalities in Android 10

Allowlists and access

In Android 6.0 and higher, apps request access to dangerous permissions at runtime. Android 10 adds activity recognition (AR) runtime permissions, which prompt the user to modify or allow dangerous permissions.

Android 8.0 required you to explicitly allowlist privileged apps in the system configuration XML files in the /etc/permissions directory. In Android 9 and higher, privileged permissions must be allowlisted or the device can't boot.

To limit internal API visibility and prevent apps from accidentally accessing platform libraries, Android 7.0 introduced Namespaces for Native Libraries. This separates system libraries from app libraries, and device manufacturers can add their own native libraries.

Starting in Android 10 apps must have both signature permissions and user consent to access a device's screen content. Privileged apps that rely on the silent capture functionality, such as taking a screenshot, should use the MediaProjection class instead.

Android 15 requires you to explicitly allowlist platform signature permissions that are requested by nonsystem apps or newly requested by updates to system apps, in the system configuration XML files in the /etc/permissions directory.

Transparency and privacy

In Android 6.0 and higher, a device factory MAC address is protected from access by Wi-Fi service providers and packet analyzers. Additional restrictions as of Android 10 limit apps from accessing the immutable device identifiers (IDs) unless they're allowlisted for privileged permissions. (The Connectivity section provides a related discussion about Device Identifiers, as this impacts carriers.)

On Android 9 and lower, users make persistent choices when granting location access to apps. Starting in Android 10, a tristate location permissions feature gives users three options to allow app access to a device's location. These permission requirements are applied to apps in Android 10 regardless of target SDK.

Configure permissions for other transparency and privacy features starting in Android 10

• The background access location reminder shows users when an app accesses their device location using ACCESS_FINE_LOCATION permission in the background.
• Contacts-affinity related data, managed by the Contacts Provider component, is accessed differently: Apps can't write to or read from the contact affinities data in the database. This impacts caller-related APIs.

Streamlined configurations

Permissions configurations have been streamlined for Android 6.0 and higher.

• Ambient capabilities for services launched by init keeps all aspects of the service configuration in a single .rc file. When setting capabilities for services not launched by init, configure file system capabilities using fs_config.c instead.
• Android 7.x and lower extend the Android IDs (AIDs) mechanism, using a device-specific android_filesystem_config.h file to specify filesystem capabilities and/or custom device-manufacturer AIDs. Android 8.0 and higher supports a new method to extend filesystem capabilities.
• In Android 8.0, handling USB commands moved out of device-specific init scripts (a substitution for HAL layers) and into a native USB daemon. The USB HAL interface must be implemented on every device launching on Android 8.0 and higher.