1## 8.3\. Power-Saving Modes 2 3If device implementations include features to improve device power management 4that are included in AOSP (e.g. App Standby Bucket, Doze) or extend the features 5that do not apply harder restrictions than [the Rare App Standby Bucket]( 6https://developer.android.com/topic/performance/power/power-details), they: 7 8* [C-1-1] MUST NOT deviate from the AOSP implementation for the triggering, 9 maintenance, wakeup algorithms and the use of global system settings of App 10 Standby and Doze power-saving modes. 11* [C-1-2] MUST NOT deviate from the AOSP implementation for the use of global 12 settings to manage the throttling of jobs, alarm and network for apps in 13 each bucket for App standby. 14* [C-1-3] MUST NOT deviate from the AOSP implementation for the number of the 15 [App Standby Buckets]( 16 https://developer.android.com/topic/performance/appstandby) used for App 17 Standby. 18* [C-1-4] MUST implement [App Standby Buckets]( 19 https://developer.android.com/topic/performance/appstandby) and Doze as 20 described in [Power Management]( 21 https://source.android.com/devices/tech/power/mgmt). 22* [C-1-5] MUST return `true` for [`PowerManager.isPowerSaveMode()`]( 23 https://developer.android.com/reference/android/os/PowerManager#isPowerSaveMode%28%29) 24 when the device is on power save mode. 25* [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to enable and 26 disable the battery saver feature. 27* [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all 28 Apps that are exempted from App Standby and Doze power-saving modes. 29 30If device implementations extend power management features that are included 31in AOSP and that extension applies more stringent restrictions than 32[the Rare App Standby Bucket]( 33https://developer.android.com/topic/performance/power/power-details), refer to 34[section 3.5.1](#3_5_api-behavioral-compatibility). 35 36In addition to the power-saving modes, Android device implementations MAY 37implement any or all of the 4 sleeping power states as defined by the Advanced 38Configuration and Power Interface (ACPI). 39 40If device implementations implement S4 power states as defined by the 41ACPI, they: 42 43* [C-1-1] MUST enter this state only after the user has taken an explicit action 44 to put the device in an inactive state (e.g. by closing a lid that is physically 45 part of the device or turning off a vehicle or television) and before the 46 user re-activates the device (e.g. by opening the lid or turning the vehicle 47 or television back on). 48 49If device implementations implement S3 power states as defined by the 50ACPI, they: 51 52* [C-2-1] MUST meet C-1-1 above, or, MUST enter S3 state only when third-party 53 applications do not need the system resources (e.g. the screen, CPU). 54 55 Conversely, MUST exit from S3 state when third-party applications need the 56 system resources, as described on this SDK. 57 58 For example, while the third-party applications request to keep the screen 59 on through `FLAG_KEEP_SCREEN_ON` or keep CPU running through 60 `PARTIAL_WAKE_LOCK`, the device MUST NOT enter S3 state unless, as described 61 in C-1-1, the user has taken explicit action to put the device in an 62 inactive state. Conversely, at a time when a task that third-party apps 63 implement through JobScheduler is triggered or Firebase Cloud Messaging is 64 delivered to third-party apps, the device MUST exit the S3 state unless the 65 user has put the device in an inactive state. These are not comprehensive 66 examples and AOSP implements extensive wake-up signals that trigger a wakeup 67 from this state. 68