By default, the power manager performs various actions when the system is inactive for a given period of time:
|Power source||Dim screen||Turn screen off||Suspend / sleep|
|Battery||5 minutes||5.5 minutes||6.5 minutes|
|AC||7 minutes||7.5 minutes||8.5 minutes|
There are different ways to define “activity”:
User activity and video activity block all of the above actions from being performed. The screen will still dim and be turned off while audio is being played, but the system will not suspend. Once activity ceases, the inactivity timer starts again.
When the suspend delay is reached while no user is logged in and the system is on battery power, the system will shut down instead of suspending.
As of M41, if the lock screen is displayed, the screen will be dimmed after just 30 seconds of inactivity and turned off after 40 seconds as described in issue 190499.
Several events can result in the above delays being lengthened (specifically, the screen-dimming delay is doubled and the other delays' distances from the dimming delay are maintained; for example, on battery, the delays are changed to 10/11/15 minutes):
If the “Require password to wake from sleep” setting is enabled, the screen will be locked ten seconds after the screen is turned off due to inactivity (in addition to being locked immediately before the system suspends when the lid is closed).
As of M71, an ML model has been enabled to run in Chrome to predict whether a screen dim should be deferred. When powerd is about to dim the screen in response to user inactivity, the model will predict whether the user is likely to reactivate the device after dimming. If reactivation seems likely, Chrome will tell powerd to defer dimming. To reduce the risk of incorrect predictions keeping the system awake indefinitely, dimming will only be deferred once until the user begins interacting with the system again. When the model is enabled, powerd's delay-doubling behavior for “presentation mode” or user activity is disabled.
The above delays and actions can be configured by Chrome and are sent to the power manager as
PowerManagementPolicy protocol buffers via D-Bus. Chrome's settings are controlled by enterprise policies and by the chrome.power extension API.
On a running system,
/var/log/power_manager/powerd.LATEST should contain enough details to understand why a given action was taken. This file is accessible via
chrome://system or by browsing to
src/platform/system_api/dbus/power_manager/policy.proto: definition of
StateControllerclass in power manager; responsible for managing delays