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 whitelisting, 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 whitelisted won’t boot.

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.

Separation of package install
and permission control functionalities for system apps and as used by user-
installed apps
Figure 1. Package install and permission-control functionalities in Android 10

Whitelists 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 whitelist privileged apps in the system configuration XML files in the /etc/permissions directory. In Android 9 and higher, privileged permissions must be whitelisted 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 application 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.

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 whitelisted 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

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.