Compatibility Definition

Random read. Device implementations MUST ensure a random read performance of at
least 3.5MB/s for a 256MB file using 4KB write buffer.
8.3. Power-Saving Modes
All apps exempted from App Standby and/or Doze mode MUST be made visible to the end user.
Further, the triggering, maintenance, wakeup algorithms and the use of Global system settings of
these power-saving modes MUST not deviate from the Android Open Source Project.
8.4. Power Consumption Accounting
A more accurate accounting and reporting of the power consumption provides the app developer both
the incentives and the tools to optimize the power usage pattern of the application. Therefore, device
implementations:
MUST be able to track hardware component power usage and attribute that power usage
to specific applications. Specifically, implementations:
MUST provide a per-component power profile that defines the current
consumption value for each hardware component and the approximate battery
drain caused by the components over time as documented in the Android Open
Source Project site [Resources, 123].
MUST report all power consumption values in milliampere hours (mAh)
SHOULD be attributed to the hardware component itself if unable to attribute
hardware component power usage to an application.
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.
MUST make this power usage available via the adb shell dumpsys batterystats
shell command to the app developer [Resources, 124].
MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a
settings menu that shows this power usage [Resources, 125].
9. Security Model Compatibility
Device implementations MUST implement a security model consistent with the Android platform
security model as defined in Security and Permissions reference document in the APIs [Resources,
126] in the Android developer documentation. Device implementations MUST support installation of
self-signed applications without requiring any additional permissions/certificates from any third
parties/authorities. Specifically, compatible devices MUST support the security mechanisms described
in the follow subsections.
9.1. Permissions
Device implementations MUST support the Android permissions model as defined in the Android
developer documentation [Resources, 126]. Specifically, implementations MUST enforce each
permission defined as described in the SDK documentation; no permissions may be omitted, altered,
or ignored. Implementations MAY add additional permissions, provided the new permission ID strings
are not in the android.* namespace.
Permissions with a protection level of dangerous are runtime permissions. Applications with
targetSdkVersion > 22 request them at runtime. Device implementations:
MUST show a dedicated interface for the user to decide whether to grant the requested
Page 61 of 74