There have been a lot of reports of Chrome OS devices that are running kiosk apps, or CfM devices, unexpectedly suspending:

issue 752312
issue 738631
issue 729609
issue 715257
http://b/65174186
etc.

The powerd logs from these feedback reports always show powerd happily keeping the system awake in response to a policy from a Chrome app or extension using the chrome.power API:

[0829/080713:INFO:daemon.cc(1414)] Received updated external policy: ac_dim=0s ac_screen_off=0s ac_lock=0s ac_idle_warn=0s ac_idle=30m battery_dim=0s battery_screen_off=0s battery_lock=0s battery_idle_warn=0s battery_idle=10m ac_idle=no-op battery_idle=no-op lid_closed=no-op use_audio=1 use_video=1 presentation_factor=2.0 user_activity_factor=2.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs, extension)

At some point, Chrome restarts for an unknown reason:

[0829/080714:INFO:suspend_delay_controller.cc(123)] Unregistering suspend delay 42860546 (chrome) due to D-Bus client :1.15 going away
[0829/080714:INFO:suspend_delay_controller.cc(123)] Unregistering dark suspend delay 42893314 (chrome) due to D-Bus client :1.15 going away
[0829/080714:INFO:suspend_delay_controller.cc(62)] Registering suspend delay 42860548 (chrome) of 5000 ms on behalf of :1.108
[0829/080714:INFO:suspend_delay_controller.cc(62)] Registering dark suspend delay 42893315 (chrome) of 5000 ms on behalf of :1.108

Then Chrome sends powerd a default policy no longer including the keep-awake request from the app:

[0829/080714:INFO:daemon.cc(1414)] Received updated external policy: ac_dim=7m ac_screen_off=8m ac_lock=0s ac_idle_warn=0s ac_idle=30m battery_dim=5m battery_screen_off=6m battery_lock=0s battery_idle_warn=0s battery_idle=10m ac_idle=suspend battery_idle=suspend lid_closed=suspend use_audio=1 use_video=1 presentation_factor=2.0 user_activity_factor=2.0 wait_for_initial_user_activity=0 force_nonzero_brightness_for_user_activity=1 (Prefs)

And then powerd suspends the system (as expected).

I thought that the app wasn't getting restarted at all, but choonc@ noticed that in at least some cases, Chrome actually restarts the app, which dutifully uses chrome.power again to try to keep the system awake, but it's too late at that point: powerd has already started suspending.

I don't know anything about the Chrome startup flow for kiosk apps or CfM (is it the same between the two cases?), but perhaps Chrome ought to hold off on sending the initial default power management policy to powerd until the app has had time to reacquire its request using chrome.power. For example, maybe Chrome could create a device::PowerSaveBlocker with kPowerSaveBlockPreventDisplaySleep at startup when running in this mode and hold it for ~30 seconds to give the app time to start.

Can someone who knows more about the startup flow when using these apps (Rahul?) provide some details about it?