9.1. Permissions

Device implementations:

  • [C-0-1] MUST support the Android permissions model as defined in the Android developer documentation. Specifically, they MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored.

  • MAY add additional permissions, provided the new permission ID strings are not in the android.\* namespace.

  • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image and within the subset of the explicitly whitelisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the whitelisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

Permissions with a protection level of dangerous are runtime permissions. Applications with targetSdkVersion > 22 request them at runtime.

Device implementations:

  • [C-0-3] MUST show a dedicated interface for the user to decide whether to grant the requested runtime permissions and also provide an interface for the user to manage runtime permissions.
  • [C-0-4] MUST have one and only one implementation of both user interfaces.
  • [C-0-5] MUST NOT grant any runtime permissions to preinstalled apps unless:
    • The user's consent can be obtained before the application uses it.
    • The runtime permissions are associated with an intent pattern for which the preinstalled application is set as the default handler.
  • [C-0-6] MUST grant the android.permission.RECOVER_KEYSTORE permission only to system apps that register a properly secured Recovery Agent. A properly secured Recovery Agent is defined as an on-device software agent that synchronizes with an off-device remote storage, that is equipped with secure hardware with protection equivalent or stronger than what is described in Google Cloud Key Vault Service to prevent brute-force attacks on the lockscreen knowledge factor.

Device implementations:

  • [C-0-7] MUST adhere to Android location permission properties when an app requests the location or physical activity data through standard Android API or proprietary mechanism. Such data includes but not limited to:

    • Device's location (e.g. latitude and longitude).
    • Information that can be used to determine or estimate the device's location (e.g. SSID, BSSID, Cell ID, or location of the network that the device is connected to).
    • User's physical activity or classification of the physical activity.

More specifically, device implementations:

    *   [C-0-8] MUST obtain user consent to allow an app to access the
        location or physical activity data.
    *   [C-0-9] MUST grant a runtime permission ONLY to the app that holds
        sufficient permission as described on SDK.
        For example,

TelephonyManager#getServiceState requires android.permission.ACCESS_FINE_LOCATION).

Permissions can be marked as restricted altering their behavior.

  • [C-0-10] Permissions marked with the flag hardRestricted MUST NOT be granted to an app unless:

    • An app APK file is in the system partition.
    • The user assigns a role that is associated with the hardRestricted permissions to an app.
    • The installer grants the hardRestricted to an app.
    • An app is granted the hardRestricted on an earlier Android version.

  • [C-0-11] Apps holding a softRestricted permission MUST get only limited access and MUST NOT gain full access until whitelisted as described in the SDK, where full and limited access is defined for each softRestricted permission (for example, WRITE_EXTERNAL_STORAGE and READ_EXTERNAL_STORAGE).

If device implementations include a pre-installed app or wish to allow third-party apps to access the usage statistics, they:

  • [SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant or revoke access to the usage stats in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent for apps that declare the android.permission.PACKAGE_USAGE_STATS permission.

If device implementations intend to disallow any apps, including pre-installed apps, from accessing the usage statistics, they:

  • [C-1-1] MUST still have an activity that handles the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent pattern but MUST implement it as a no-op, that is to have an equivalent behavior as when the user is declined for access.