caused by the components over time as documented in the Android Open Source Project
site.
[ 8.4 /H-0-2] MUST report all power consumption values in milliampere hours (mAh).
[ 8.4 /H-0-3] MUST report CPU power consumption per each process's UID. The Android
Open Source Project meets the requirement through the uid_cputime kernel module
implementation.
[ 8.4 /H-0-4] MUST make this power usage available via the adb shell dumpsys batterystats
shell command to the app developer.
[ 8.4 /H] SHOULD be attributed to the hardware component itself if unable to attribute
hardware component power usage to an application.
If Handheld device implementations include a screen or video output, they:
[ 8.4 /H-1-1] MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and
display a settings menu that shows this power usage.
2.2.5. Security Model
Handheld device implementations:
[ 9.1 /H-0-1] MUST allow third-party apps to access the usage statistics via the
android.permission.PACKAGE_USAGE_STATS permission and provide a user-accessible
mechanism to grant or revoke access to such apps in response to the
android.settings.ACTION_USAGE_ACCESS_SETTINGS intent.
Handheld device implementations (* Not applicable for Tablet):
[ 9.11 /H-0-2]* MUST back up the keystore implementation with an isolated execution
environment.
[ 9.11 /H-0-3]* MUST have implementations of RSA, AES, ECDSA, and HMAC
cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly
support the Android Keystore system's supported algorithms in an area that is securely
isolated from the code running on the kernel and above. Secure isolation MUST block all
potential mechanisms by which kernel or userspace code might access the internal state
of the isolated environment, including DMA. The upstream Android Open Source Project
(AOSP) meets this requirement by using the Trusty implementation, but another ARM
TrustZone-based solution or a third-party reviewed secure implementation of a proper
hypervisor-based isolation are alternative options.
[ 9.11 /H-0-4]* MUST perform the lock screen authentication in the isolated execution
environment and only when successful, allow the authentication-bound keys to be used.
Lock screen credentials MUST be stored in a way that allows only the isolated execution
environment to perform lock screen authentication. The upstream Android Open Source
Project provides the Gatekeeper Hardware Abstraction Layer (HAL) and Trusty, which can
be used to satisfy this requirement.
[ 9.11 /H-0-5]* MUST support key attestation where the attestation signing key is
protected by secure hardware and signing is performed in secure hardware. The
attestation signing keys MUST be shared across large enough number of devices to
prevent the keys from being used as device identifiers. One way of meeting this
requirement is to share the same attestation key unless at least 100,000 units of a given
SKU are produced. If more than 100,000 units of an SKU are produced, a different key
MAY be used for each 100,000 units.
Note that if a device implementation is already launched on an earlier Android version, such a device
is exempted from the requirement to have a keystore backed by an isolated execution environment
and support the key attestation, unless it declares the android.hardware.fingerprint feature which
requires a keystore backed by an isolated execution environment.
When Handheld device implementations support a secure lock screen, they:
[ 9.11 /H-1-1] MUST allow the user to choose the shortest sleep timeout, that is a
transition time from the unlocked to the locked state, as 15 seconds or less.
[ 9.11 /H-1-2] MUST provide user affordance to hide notifications and disable all forms of
authentication except for the primary authentication described in 9.11.1 Secure Lock
Screen . The AOSP meets the requirement as lockdown mode.
If Handheld device implementations include multiple users and do not declare the
android.hardware.telephony feature flag, they: