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.
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
- The
background access location reminder shows users when an app accesses their
device location using
ACCESS_FINE_LOCATIONpermission 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
initkeeps all aspects of the service configuration in a single.rcfile. When setting capabilities for services not launched byinit, configure file system capabilities usingfs_config.cinstead. - Android 7.x and lower extend the Android IDs (AIDs) mechanism, using a
device-specific
android_filesystem_config.hfile 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
initscripts (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.