Consider adding inactivity grace period after wake locks are released |
||||||||||
Issue descriptionThe user experience around power management when watching video using Android apps is poor. From http://feedback/product/208/neutron?lView=rd&lReport=55082593046: [0316/004821:INFO:daemon.cc(1359)] 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=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, ARC) [0316/004821:INFO:state_controller.cc(757)] Updated settings: dim=0s screen_off=0s lock=0s idle_warn=0s idle=10m (no-op) lid_closed=suspend use_audio=1 use_video=1 ... [0316/010218:INFO:daemon.cc(1359)] Received updated external policy: ac_dim=7m ac_screen_off=8m ac_lock=8m10s ac_idle_warn=0s ac_idle=30m battery_dim=5m battery_screen_off=6m battery_lock=6m10s 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) [0316/010218:INFO:state_controller.cc(757)] Updated settings: dim=5m screen_off=6m lock=6m10s idle_warn=0s idle=10m (suspend) lid_closed=suspend use_audio=1 use_video=1 [0316/010218:INFO:state_controller.cc(89)] Dimming screen after 7m6s [0316/010218:INFO:internal_backlight_controller.cc(674)] Setting brightness to 2 (12.5%) over 200 ms [0316/010218:INFO:state_controller.cc(89)] Turning screen off after 7m6s [0316/010218:INFO:internal_backlight_controller.cc(674)] Setting brightness to 0 (0%) over 200 ms [0316/010218:INFO:state_controller.cc(89)] Locking screen after 7m6s [0316/010218:INFO:display_power_setter.cc(80)] Asking Chrome to turn all displays off As soon as the app releases its wake lock, the ARC PowerSaveBlocker within Chrome is destroyed. If there are no other PowerSaveBlockers and the user has been idle long enough to hit any of the inactivity timeouts, the corresponding action(s) are performed immediately. This is non-optimal if the user has just finished watching a video; the screen may turn off and be locked immediately. For non-Android audio and video activity, powerd keeps track of the last-reported activity and uses it reset the inactivity timers. Unfortunately it's not easy for us to do the same thing with Android audio/video activity, since it's lumped together with the everything else that's reported to powerd. I'm not sure of the right way for us to fix this. One option might be adding additional fields to the PowerManagementPolicy protobufs that Chrome sends to powerd. For example, what about the following? int32 display_wake_locks int32 dim_wake_locks int32 system_wake_locks Instead of clearing the dim, lock, etc. delays when PowerSaveBlockers are held, Chrome would copy the counts to the new fields. powerd would keep track of the last time at which the counts were nonzero, similar to what it does with audio and video activity, and factor them into inactivity calculations. The end result would be that there'd be a grace period before inactivity actions are taken after Android wake locks or chrome.power requests are released, similar to what we do for audio and video activity right now. I need to think more about this to know if there are downsides that I'm missing. Eric, would this make us run afoul of anything on the CTS side? I'm not sure how Android behaves in this regard.
,
Mar 24 2017
,
Mar 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/f864edc328f6eb2d6f6f5cb8a661f1948ce53856 commit f864edc328f6eb2d6f6f5cb8a661f1948ce53856 Author: Daniel Erat <derat@chromium.org> Date: Sat Mar 25 02:38:04 2017 power: Initialize policy::StateController members in header. Do some cleanup now so I don't get tempted to lump it into a later change that adds new code. BUG= chromium:704408 TEST=builds and tests pass Change-Id: Ia12c5da47010760b8e09dfa46fa99dfb6ad79d0c Reviewed-on: https://chromium-review.googlesource.com/459197 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> [modify] https://crrev.com/f864edc328f6eb2d6f6f5cb8a661f1948ce53856/power_manager/powerd/policy/state_controller.cc [modify] https://crrev.com/f864edc328f6eb2d6f6f5cb8a661f1948ce53856/power_manager/powerd/policy/state_controller.h
,
Apr 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/1fa4f42ef2f10e31d3e12cd93354ea74aca07869 commit 1fa4f42ef2f10e31d3e12cd93354ea74aca07869 Author: Daniel Erat <derat@chromium.org> Date: Thu Apr 06 17:56:33 2017 power: Add StateController::ActivityInfo. Add a tiny ActivityInfo helper class to powerd's StateController class. This is currently just used to track audio activity, but it will be used to track wake locks as well in the near future. BUG= chromium:704408 TEST=unit tests still pass Change-Id: I2ad5732e04c66830dda44af680aed860c9e55746 Reviewed-on: https://chromium-review.googlesource.com/461230 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> [modify] https://crrev.com/1fa4f42ef2f10e31d3e12cd93354ea74aca07869/power_manager/powerd/policy/state_controller.cc [modify] https://crrev.com/1fa4f42ef2f10e31d3e12cd93354ea74aca07869/power_manager/powerd/policy/state_controller.h
,
Apr 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/0e464138d09b1569ddfb164071d7c5ccffef9a44 commit 0e464138d09b1569ddfb164071d7c5ccffef9a44 Author: Daniel Erat <derat@chromium.org> Date: Wed Apr 12 06:26:09 2017 power: Improve delay scheduling. Extremely lengthy background information: At present, powerd's StateController::ScheduleActionTimeout method takes a bunch of delays for actions (e.g. screen-dim, screen-off) and a bunch of activities (e.g. user, video, audio) and uses them to start a "wait until I need to wake up to perform the next action" timer. This is all fine and well for activity that's reported periodically (e.g. video activity, reported every five seconds), since we'll recompute the time-until-wakeup every time we get a new report of activity and never actually hit the timeout. Things are a bit weirder when it comes to activity that remains active until we receive notification that it's stopped. If nothing else is going on, we may actually hit the timeout after (say) ten minutes. In practice, this is fine, because the UpdateState method (called by HandleActionTimeout) recomputes the delays (getting the full durations again since the activity is still active) and doesn't do anything. It makes things a bit weird for tests that want to make sure that various actions are being blocked, though. Ideally, they'd be able to just see that the timeout isn't set at all, but with the way the code works at present, they actually need to advance the timer until it fires and then verify that the action wasn't actually performed. This makes testing much trickier in a followup change, so I'm introducing new IsIdleBlocked and IsScreen{Dim,Lock,Off}Blocked methods that can be called to check whether a given action will be indefinitely blocked barring a state change. ScheduleActionTimeout now calls these to verify that a given action can be performed before computing its delay. If the action is blocked in the current state, then we don't include its delay when computing the timeout. Note also that most actions can't be blocked indefinitely by anything right now. That will change once Chrome is reporting wake locks to powerd. BUG= chromium:704408 TEST=tests pass Change-Id: Idcbdc36a7fce1784db947b5156013dd2d1a72a9d Reviewed-on: https://chromium-review.googlesource.com/471831 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> [modify] https://crrev.com/0e464138d09b1569ddfb164071d7c5ccffef9a44/power_manager/powerd/policy/state_controller_unittest.cc [modify] https://crrev.com/0e464138d09b1569ddfb164071d7c5ccffef9a44/power_manager/powerd/policy/state_controller.cc [modify] https://crrev.com/0e464138d09b1569ddfb164071d7c5ccffef9a44/power_manager/powerd/policy/state_controller.h
,
Apr 20 2017
This has some possible implications to the way that wake locks behave when policies are sent. Copying-and-pasting from email: ---- As things stand right now: a) Chrome has a power.allow_screen_wake_locks pref (controlled by policy) that can be set to false to make "screen" wake locks (that keep the screen on and unlocked) instead be interpreted as "system" wake locks (that only prevent us from performing the idle action, e.g. suspend, log out, shut down). b) Chrome has power.use_audio_activity and power.use_video_activity prefs (again controlled by policy) that can be set to false to prevent wake locks from being automatically acquired during audio and video playback. Note that this doesn't prevent them from being acquired by the chrome.power API or by Android apps, though. c) Screen-lock has its own delay, and screen wake locks are currently (and have always been) able to block it modulo the above caveats. d) System (and screen) wake locks only override the idle action to "do nothing" if it's set to "suspend". If it's set to something else, screen wake locks just keep the screen on up to the point where the idle action is performed later. The final point is the thing that I'm considering changing. The different levels of locks are essentially layered: screen wake locks (which can be split further into full-brightness and dimmed-brightness locks; the latter was added for ARC) keep the screen on and additionally perform system wake locks' role of blocking the idle action. With the new implementation that I'm considering, there's no easy way to make screen wake locks keep the screen on while still letting us perform the idle action later, but I'm not sure that it ever made sense that we did that. I don't know if anything depends on the existing behavior in this regard. If we just want an escape hatch to be able to make sure that policies can never be overridden, perhaps we should add an additional power.allow_wake_locks or power.allow_system_wake_locks pref/policy that can be used to completely block them. ---- Bartosz and Mattias, do you have any concerns? If not, I plan to go ahead with the change as described above. It should be easy to add an additional policy setting to disallow system wake locks if we need it.
,
Sep 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/system_api/+/a8a31cea143fb6bf2a06c91d5a5349ae51c067b4 commit a8a31cea143fb6bf2a06c91d5a5349ae51c067b4 Author: Daniel Erat <derat@chromium.org> Date: Tue Sep 05 20:44:01 2017 system_api: Add wake_lock fields to PowerManagementPolicy. Add screen_wake_lock, dim_wake_lock, and system_wake_lock fields to powerd's PowerManagementPolicy protocol buffer. These will be used to report the existence of Chrome wake locks to powerd. BUG= chromium:704408 TEST=none Change-Id: I236f2560e174432c1e479659e03b27c5c25066cd Reviewed-on: https://chromium-review.googlesource.com/650509 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> [modify] https://crrev.com/a8a31cea143fb6bf2a06c91d5a5349ae51c067b4/dbus/power_manager/policy.proto
,
Sep 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/6b19a7e7e6f99398c6a20edd238aa5f700f948b9 commit 6b19a7e7e6f99398c6a20edd238aa5f700f948b9 Author: Daniel Erat <derat@chromium.org> Date: Tue Sep 05 20:44:02 2017 power: Track wake locks. Make powerd track wake locks received from Chrome. Letting Chrome report wake locks directly rather than simulating them by overriding delays avoids some edge cases where actions take effect immediately when a wake lock is briefly released. BUG= chromium:704408 TEST=added unit tests CQ-DEPEND=I236f2560e174432c1e479659e03b27c5c25066cd Change-Id: Ie322990ce3a62aee02ee626df6e44a12e0c9d935 Reviewed-on: https://chromium-review.googlesource.com/650510 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> [modify] https://crrev.com/6b19a7e7e6f99398c6a20edd238aa5f700f948b9/power_manager/tools/set_power_policy.cc [modify] https://crrev.com/6b19a7e7e6f99398c6a20edd238aa5f700f948b9/power_manager/powerd/policy/state_controller_unittest.cc [modify] https://crrev.com/6b19a7e7e6f99398c6a20edd238aa5f700f948b9/power_manager/powerd/policy/state_controller.cc [modify] https://crrev.com/6b19a7e7e6f99398c6a20edd238aa5f700f948b9/power_manager/powerd/policy/state_controller.h
,
Sep 6 2017
The main (only?) reason for an admin to fiddle with timeouts in non-kiosk mode is to ensure that the device cannot be left running unlocked, indefinitely. IIUC, there is a way to achieve this today (set the idle action to shutdown, which cannot be overridden in any way) but it is not obvious at all to admins that this is the only way which works. An admin may set the idle action to suspend or configure a lock timeout, reasonably expecting this approach to work as well, only to be overridden by a wake lock. I like your proposal of an explicit policy that determines whether wake locks are allowed. If the admin cares about enforcing timeouts, he can configure them any way he wants and disable wake locks. Much cleaner than the implicit interacitons of the various features we had so far.
,
Sep 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a6615ff353f57eec316183bcfb25d53977e234c2 commit a6615ff353f57eec316183bcfb25d53977e234c2 Author: Daniel Erat <derat@chromium.org> Date: Wed Sep 06 20:37:41 2017 Roll src/third_party/cros_system_api/ 27810c6ba..a8a31cea1 (1 commit) https://chromium.googlesource.com/chromiumos/platform/system_api.git/+log/27810c6ba2d3..a8a31cea143f $ git log 27810c6ba..a8a31cea1 --date=short --no-merges --format='%ad %ae %s' 2017-03-27 derat system_api: Add wake_lock fields to PowerManagementPolicy. Created with: roll-dep src/third_party/cros_system_api Bug: 704408 Change-Id: I592bae308393eda0a32580c93d180341ae64168a Reviewed-on: https://chromium-review.googlesource.com/651909 Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Cr-Commit-Position: refs/heads/master@{#500073} [modify] https://crrev.com/a6615ff353f57eec316183bcfb25d53977e234c2/DEPS
,
Sep 6 2017
Issue 761248 has been merged into this issue.
,
Sep 6 2017
Issue 738631 has been merged into this issue.
,
Sep 6 2017
Issue 752312 has been merged into this issue.
,
Sep 6 2017
Issue 729609 has been merged into this issue.
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4004e53a0efdf35baa11ec231d6bb613dc2e4737 commit 4004e53a0efdf35baa11ec231d6bb613dc2e4737 Author: Daniel Erat <derat@chromium.org> Date: Thu Sep 07 00:35:49 2017 chromeos: Report wake locks to powerd. Make PowerPolicyController report screen, dim, and system wake locks to powerd rather than overriding the corresponding inactivity delays. This avoids earlier unexpected behavior when a newly-reinstated delay's action is suddenly performed as soon as a wake lock is released. Bug: 704408 Change-Id: I752b42ca2d75e838c9adca6c9f4b4bb62144a3e4 Reviewed-on: https://chromium-review.googlesource.com/651170 Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Cr-Commit-Position: refs/heads/master@{#500158} [modify] https://crrev.com/4004e53a0efdf35baa11ec231d6bb613dc2e4737/chrome/browser/chromeos/policy/power_policy_browsertest.cc [modify] https://crrev.com/4004e53a0efdf35baa11ec231d6bb613dc2e4737/chromeos/dbus/power_policy_controller.cc [modify] https://crrev.com/4004e53a0efdf35baa11ec231d6bb613dc2e4737/chromeos/dbus/power_policy_controller_unittest.cc
,
Sep 7 2017
I've convinced myself that this fixes the race described in issue 761248 . To replicate the issue outside of a kiosk setting, I pushed a modified version of powerd that ignores audio activity (because the login screen seems to briefly open an audio stream now) and doesn't treat session state changes as user activity (because I don't think that sessions are started for kiosk apps). Without this change to how Chrome reports wake locks, I'm able to repro the issue by: a) logging in b) using go/keepawake to grab a wake lock c) waiting for powerd to log that it's performed the no-op idle action d) running "restart ui" to restart Chrome without generating user activity powerd suspends immediately when it gets the default policy from Chrome. With this change, powerd doesn't perform the idle action at all while the user is logged in (since the wake lock is treated is activity) and doesn't start the inactivity timeout until the wake lock is released at the login screen. Requesting a merge to M62.
,
Sep 7 2017
We do start sessions for kiosk apps. With your changes in, how will the following behave: * Kiosk mode * Kiosk app is holding wake lock * Idle action set to log out with a very short timeout * No user activity in a long time (or ever) * Kiosk app releases wake lock We use this combination to give kiosk apps the ability to end the kiosk session (which will respawn automatically from the login screen) to apply updates. It used to be that when the wake lock is released, the session ends immediately. Will we incur a delay here now? How long?
,
Sep 7 2017
The idle action should be performed after the very short timeout in that case. This feels more consistent than what we did before (where with idle delay D, session start time S, and release time R, the action would be performed at max(S + D, R)).
,
Sep 7 2017
That's great, this is the only corner case I could think of.
,
Sep 7 2017
Approved for 62. Please verify this change makes it through the Chrome PFQ on Chrome OS before merging.
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/system_api/+/724640fdd62faf49728a4685e50367192555f8b2 commit 724640fdd62faf49728a4685e50367192555f8b2 Author: Daniel Erat <derat@chromium.org> Date: Thu Sep 07 16:44:37 2017 system_api: Add wake_lock fields to PowerManagementPolicy. Add screen_wake_lock, dim_wake_lock, and system_wake_lock fields to powerd's PowerManagementPolicy protocol buffer. These will be used to report the existence of Chrome wake locks to powerd. BUG= chromium:704408 TEST=none Change-Id: I236f2560e174432c1e479659e03b27c5c25066cd Reviewed-on: https://chromium-review.googlesource.com/650509 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> (cherry picked from commit a8a31cea143fb6bf2a06c91d5a5349ae51c067b4) Reviewed-on: https://chromium-review.googlesource.com/655280 Reviewed-by: Dan Erat <derat@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Trybot-Ready: Dan Erat <derat@chromium.org> [modify] https://crrev.com/724640fdd62faf49728a4685e50367192555f8b2/dbus/power_manager/policy.proto
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/364d2e91ed22e891bcfeb0a92ba257ff2865d811 commit 364d2e91ed22e891bcfeb0a92ba257ff2865d811 Author: Daniel Erat <derat@chromium.org> Date: Thu Sep 07 16:45:29 2017 power: Track wake locks. Make powerd track wake locks received from Chrome. Letting Chrome report wake locks directly rather than simulating them by overriding delays avoids some edge cases where actions take effect immediately when a wake lock is briefly released. BUG= chromium:704408 TEST=added unit tests CQ-DEPEND=I236f2560e174432c1e479659e03b27c5c25066cd Change-Id: Ie322990ce3a62aee02ee626df6e44a12e0c9d935 Reviewed-on: https://chromium-review.googlesource.com/650510 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> (cherry picked from commit 6b19a7e7e6f99398c6a20edd238aa5f700f948b9) Reviewed-on: https://chromium-review.googlesource.com/655597 Reviewed-by: Dan Erat <derat@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Trybot-Ready: Dan Erat <derat@chromium.org> [modify] https://crrev.com/364d2e91ed22e891bcfeb0a92ba257ff2865d811/power_manager/tools/set_power_policy.cc [modify] https://crrev.com/364d2e91ed22e891bcfeb0a92ba257ff2865d811/power_manager/powerd/policy/state_controller_unittest.cc [modify] https://crrev.com/364d2e91ed22e891bcfeb0a92ba257ff2865d811/power_manager/powerd/policy/state_controller.cc [modify] https://crrev.com/364d2e91ed22e891bcfeb0a92ba257ff2865d811/power_manager/powerd/policy/state_controller.h
,
Sep 7 2017
I've merged the OS-side changes to release-R62-9901.B, and will merge the Chrome changes to branch 3202 after they've gone through the Chrome PFQ.
,
Sep 8 2017
,
Sep 8 2017
I'm merging the Chrome changes now. At least some of the PFQ builders have passed with these changes (there's nothing board-specific about this change), and I don't want to lose bake time for the merged changes because we're bad at running tests.
,
Sep 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3613d897da7b834263c7424af4e30d900a1b71db commit 3613d897da7b834263c7424af4e30d900a1b71db Author: Daniel Erat <derat@chromium.org> Date: Fri Sep 08 19:18:08 2017 Roll src/third_party/cros_system_api/ 27810c6ba..a8a31cea1 (1 commit) https://chromium.googlesource.com/chromiumos/platform/system_api.git/+log/27810c6ba2d3..a8a31cea143f $ git log 27810c6ba..a8a31cea1 --date=short --no-merges --format='%ad %ae %s' 2017-03-27 derat system_api: Add wake_lock fields to PowerManagementPolicy. Created with: roll-dep src/third_party/cros_system_api TBR=derat@chromium.org (cherry picked from commit a6615ff353f57eec316183bcfb25d53977e234c2) Bug: 704408 Change-Id: I592bae308393eda0a32580c93d180341ae64168a Reviewed-on: https://chromium-review.googlesource.com/651909 Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#500073} Reviewed-on: https://chromium-review.googlesource.com/657273 Reviewed-by: Dan Erat <derat@chromium.org> Cr-Commit-Position: refs/branch-heads/3202@{#92} Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098} [modify] https://crrev.com/3613d897da7b834263c7424af4e30d900a1b71db/DEPS
,
Sep 8 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/01775ab491d205ae6f5c3bed975f1aaecbe965b9 commit 01775ab491d205ae6f5c3bed975f1aaecbe965b9 Author: Daniel Erat <derat@chromium.org> Date: Fri Sep 08 20:33:54 2017
,
Sep 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/86125d591883fc24ff4a6a0e5ef9b2827314bb6b commit 86125d591883fc24ff4a6a0e5ef9b2827314bb6b Author: Daniel Erat <derat@chromium.org> Date: Fri Sep 08 20:41:19 2017 chromeos: Report wake locks to powerd. Make PowerPolicyController report screen, dim, and system wake locks to powerd rather than overriding the corresponding inactivity delays. This avoids earlier unexpected behavior when a newly-reinstated delay's action is suddenly performed as soon as a wake lock is released. TBR=derat@chromium.org (cherry picked from commit 4004e53a0efdf35baa11ec231d6bb613dc2e4737) Bug: 704408 Change-Id: I752b42ca2d75e838c9adca6c9f4b4bb62144a3e4 Reviewed-on: https://chromium-review.googlesource.com/651170 Reviewed-by: Michael Giuffrida <michaelpg@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#500158} Reviewed-on: https://chromium-review.googlesource.com/657967 Reviewed-by: Dan Erat <derat@chromium.org> Cr-Commit-Position: refs/branch-heads/3202@{#94} Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098} [modify] https://crrev.com/86125d591883fc24ff4a6a0e5ef9b2827314bb6b/chrome/browser/chromeos/policy/power_policy_browsertest.cc [modify] https://crrev.com/86125d591883fc24ff4a6a0e5ef9b2827314bb6b/chromeos/dbus/power_policy_controller.cc [modify] https://crrev.com/86125d591883fc24ff4a6a0e5ef9b2827314bb6b/chromeos/dbus/power_policy_controller_unittest.cc
,
Sep 8 2017
,
Sep 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e3db850f5b2a50d0965b4afc9350fbbc501b5c66 commit e3db850f5b2a50d0965b4afc9350fbbc501b5c66 Author: Muyuan Li <muyuanli@chromium.org> Date: Sat Sep 23 00:18:07 2017 Roll src/third_party/cros_system_api a8a31cea..860f010f3 git log a8a31cea..860f010f3: commit 860f010f3e903e089d0ed197c3beb0e147f2dffa (HEAD, origin/release-R62-9901.B) Author: Muyuan Li <muyuanli@google.com> Date: Mon Sep 11 16:39:39 2017 -0700 add HotwordTriggered signal BUG=b:62065175 Change-Id: I004206768850ded54e43263fd0ba61f51878d8fe Reviewed-on: https://chromium-review.googlesource.com/661947 Commit-Ready: Muyuan Li <muyuanli@chromium.org> Tested-by: Muyuan Li <muyuanli@chromium.org> Reviewed-by: Dan Erat <derat@chromium.org> (cherry picked from commit 8dbf538802c8f50b0ce1f06f579d3a4809592ecc) Reviewed-on: https://chromium-review.googlesource.com/677093 Commit-Queue: Muyuan Li <muyuanli@chromium.org> Trybot-Ready: Muyuan Li <muyuanli@chromium.org> commit 724640fdd62faf49728a4685e50367192555f8b2 Author: Daniel Erat <derat@chromium.org> Date: Mon Mar 27 08:22:54 2017 -0600 system_api: Add wake_lock fields to PowerManagementPolicy. Add screen_wake_lock, dim_wake_lock, and system_wake_lock fields to powerd's PowerManagementPolicy protocol buffer. These will be used to report the existence of Chrome wake locks to powerd. BUG= chromium:704408 TEST=none Change-Id: I236f2560e174432c1e479659e03b27c5c25066cd Reviewed-on: https://chromium-review.googlesource.com/650509 Commit-Ready: Dan Erat <derat@chromium.org> Tested-by: Dan Erat <derat@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> (cherry picked from commit a8a31cea143fb6bf2a06c91d5a5349ae51c067b4) Reviewed-on: https://chromium-review.googlesource.com/655280 Reviewed-by: Dan Erat <derat@chromium.org> Commit-Queue: Dan Erat <derat@chromium.org> Trybot-Ready: Dan Erat <derat@chromium.org> BUG=b:62065175 Change-Id: I9158152d56dc40033337409714ac9d6ae9eb5a2c Reviewed-on: https://chromium-review.googlesource.com/679323 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Cr-Commit-Position: refs/branch-heads/3202@{#410} Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098} [modify] https://crrev.com/e3db850f5b2a50d0965b4afc9350fbbc501b5c66/DEPS
,
Sep 26 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/382c08b6cdf5ad6518901c507df61aa2794e7e23 commit 382c08b6cdf5ad6518901c507df61aa2794e7e23 Author: Muyuan Li <muyuanli@google.com> Date: Tue Sep 26 21:10:37 2017 |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ejcaruso@chromium.org
, Mar 23 2017