maintenance, wakeup algorithms and the use of global system settings of App Standby
and Doze power-saving modes.
[C-1-2] MUST NOT deviate from the AOSP implementation for the use of global settings to
manage the throttling of jobs, alarm and network for apps in each bucket for App standby.
[C-1-3] MUST NOT deviate from the AOSP implementation for the number of the
App
Standby Buckets
used for App Standby.
[C-1-4] MUST implement
App Standby Buckets
and Doze as described in
Power
Management
.
[C-1-5] MUST return
true
for
PowerManager.isPowerSaveMode()
when the device is on power
save mode.
[C-SR] Are STRONGLY RECOMMENDED to provide user affordance to enable and disable
the battery saver feature.
[C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all Apps that
are exempted from App Standby and Doze power-saving modes.
In addition to the power-saving modes, Android device implementations MAY implement any or all of
the 4 sleeping power states as defined by the Advanced Configuration and Power Interface (ACPI).
If device implementations implement S3 and S4 power states as defined by the ACPI, they:
[C-1-1] MUST enter these states only after the user has taken an explicit action to put the
device in an inactive state (e.g. by closing a lid that is physically part of the device or
turning off a vehicle or television) and before the user re-activates the device (e.g. by
opening the lid or turning the vehicle or television back on).
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.
Device implementations:
[SR] STRONGLY RECOMMENDED to 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.
[SR] STRONGLY RECOMMENDED to report all power consumption values in milliampere
hours (mAh).
[SR] STRONGLY RECOMMENDED to report CPU power consumption per each process's
UID. The Android Open Source Project meets the requirement through the
uid_cputime
kernel module implementation.
[SR] STRONGLY RECOMMENDED to make this power usage available via the
adb shell
dumpsys batterystats
shell command to the app developer.
SHOULD be attributed to the hardware component itself if unable to attribute hardware
component power usage to an application.
8.5. Consistent Performance
Performance can fluctuate dramatically for high-performance long-running apps, either because of
the other apps running in the background or the CPU throttling due to temperature limits. Android
includes programmatic interfaces so that when the device is capable, the top foreground application
can request that the system optimize the allocation of the resources to address such fluctuations.
Device implementations:
Page 113 of 132
