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