History log of /frameworks/base/services/java/com/android/server/power/Notifier.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e98f5dbe6b6f9f2cb6a73ee750faacda2596b34f 18-Jul-2013 Dianne Hackborn <hackbod@google.com> Make it safe to use start/stop app ops outside of system proc

We now keep track of all of the active start operations per
non-system process, so they can be cleaned up if the process
goes away.

Change-Id: I9d05f1e0281c47dbe1213de014f0491f1359685c
/frameworks/base/services/java/com/android/server/power/Notifier.java
713df150b92a0a5eea877f99405e31eefbf93a09 17-May-2013 Dianne Hackborn <hackbod@google.com> Add app ops for wake locks.

Currently only supports auditing, not disabling.

Change-Id: Ie85f02c29b490d96e073f54d59e165d48c7c00c9
/frameworks/base/services/java/com/android/server/power/Notifier.java
84e2756c0f3794c6efe5568a9d09101ba689fb39 07-Dec-2012 Jeff Brown <jeffbrown@google.com> Play a tone when wireless charging begins.

Only plays a tone if the battery level is below 95% which
is the same heuristic used when determining whether to turn
the screen on.

Use new low battery and wireless charging sounds on Mako.

Bug: 7371658
Change-Id: Ia4527ec398d024ee418a4287e1fcbf0ec83bcc24
/frameworks/base/services/java/com/android/server/power/Notifier.java
c38c9be031ddad5cf551b55458889f11e01dc5b2 04-Oct-2012 Jeff Brown <jeffbrown@google.com> Coordinate screen on with the window manager.

Bug: 7267457
Change-Id: Ic2c322253639e1f0b2e4e72a7b145025d0240f93
/frameworks/base/services/java/com/android/server/power/Notifier.java
543083593430208af87e51b94cdbbb51cbe2d7b5 05-Oct-2012 Jeff Brown <jeffbrown@google.com> Ensure we send at least one wakeup/gotosleep transition.

This fixes an issue where the device would not lock immediately
when the user quickly pressed power off / power on even if
configured to do so. We were suppressing the screen off
and wake up broadcast in this case.

Now we make sure to always send at least one broadcast to
indicate the transition. We still collapse back-to-back
full cycle transitions though so as not to end up enqueuing
useless broadcasts.

Bug: 7061116
Change-Id: I7211c5fd963c271c2b0aceb4d2f746063c629079
/frameworks/base/services/java/com/android/server/power/Notifier.java
5ac72a29593ab9a20337a2225df52bdf4754be02 30-Aug-2012 Dianne Hackborn <hackbod@google.com> Improve multi-user broadcasts.

You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.

Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.

New Context APIs for more kinds of sending broadcasts as users.

Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.

Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.

Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
/frameworks/base/services/java/com/android/server/power/Notifier.java
a2910d0abbbe18ba1710dfd4a31af45769632255 25-Aug-2012 Jeff Brown <jeffbrown@google.com> Make it easier to create asynchronous Handlers.

There are potentially very many Handlers owned by services
that should not be blocked by barriers introduced by UI traversals
occurring on the same thread (if that ever happens).
Add some convenience constructors to make it easy to switch
these Handlers over to being async.

Bug: 7057752
Change-Id: I64d9bffe81e7c52ada4cfad4e89d4340153f4688
/frameworks/base/services/java/com/android/server/power/Notifier.java
259328c04ce16c554b48a14f68d8af94dc54d7ec 22-Aug-2012 Craig Mautner <cmautner@google.com> Eliminate special battery calls by WindowManager

Previous to this change the WindowManager was notifying the
BatteryDtatsService about windows that keep the screen on. WM used a
custom WakeLock tag to indicate to PowerManagerService that it had
already notified the BatteryStatsService.

This change eliminates WindowManager notifying the BatteryStatsService
and lets PowerManagerService do the job.

Fixes bug 7030326.

Change-Id: I666dc6ef8f094b8d3d109fea6876be058e057b4f
/frameworks/base/services/java/com/android/server/power/Notifier.java
9630704ed3b265f008a8f64ec60a33cf9dcd3345 28-Jul-2012 Jeff Brown <jeffbrown@google.com> Power manager rewrite.

The major goal of this rewrite is to make it easier to implement
power management policies correctly. According, the new
implementation primarily uses state-based rather than event-based
triggers for applying changes to the current power state.

For example, when an application requests that the proximity
sensor be used to manage the screen state (by way of a wake lock),
the power manager makes note of the fact that the set of
wake locks changed. Then it executes a common update function
that recalculates the entire state, first looking at wake locks,
then considering user activity, and eventually determining whether
the screen should be turned on or off. At this point it may
make a request to a component called the DisplayPowerController
to asynchronously update the display's powe state. Likewise,
DisplayPowerController makes note of the updated power request
and schedules its own update function to figure out what needs
to be changed.

The big benefit of this approach is that it's easy to mutate
multiple properties of the power state simultaneously then
apply their joint effects together all at once. Transitions
between states are detected and resolved by the update in
a consistent manner.

The new power manager service has is implemented as a set of
loosely coupled components. For the most part, information
only flows one way through these components (by issuing a
request to that component) although some components support
sending a message back to indicate when the work has been
completed. For example, the DisplayPowerController posts
a callback runnable asynchronously to tell the PowerManagerService
when the display is ready. An important feature of this
approach is that each component neatly encapsulates its
state and maintains its own invariants. Moreover, we do
not need to worry about deadlocks or awkward mutual exclusion
semantics because most of the requests are asynchronous.

The benefits of this design are especially apparent in
the implementation of the screen on / off and brightness
control animations which are able to take advantage of
framework features like properties, ObjectAnimator
and Choreographer.

The screen on / off animation is now the responsibility
of the power manager (instead of surface flinger). This change
makes it much easier to ensure that the animation is properly
coordinated with other power state changes and eliminates
the cause of race conditions in the older implementation.

The because of the userActivity() function has been changed
so that it never wakes the device from sleep. This change
removes ambiguity around forcing or disabling user activity
for various purposes. To wake the device, use wakeUp().
To put it to sleep, use goToSleep(). Simple.

The power manager service interface and API has been significantly
simplified and consolidated. Also fixed some inconsistencies
related to how the minimum and maximum screen brightness setting
was presented in brightness control widgets and enforced behind
the scenes.

At present the following features are implemented:

- Wake locks.
- User activity.
- Wake up / go to sleep.
- Power state broadcasts.
- Battery stats and event log notifications.
- Dreams.
- Proximity screen off.
- Animated screen on / off transitions.
- Auto-dimming.
- Auto-brightness control for the screen backlight with
different timeouts for ramping up versus ramping down.
- Auto-on when plugged or unplugged.
- Stay on when plugged.
- Device administration maximum user activity timeout.
- Application controlled brightness via window manager.

The following features are not yet implemented:

- Reduced user activity timeout for the key guard.
- Reduced user activity timeout for the phone application.
- Coordinating screen on barriers with the window manager.
- Preventing auto-rotation during power state changes.
- Auto-brightness adjustment setting (feature was disabled
in previous version of the power manager service pending
an improved UI design so leaving it out for now).
- Interpolated brightness control (a proposed new scheme
for more compactly specifying auto-brightness levels
in config.xml).
- Button / keyboard backlight control.
- Change window manager to associated WorkSource with
KEEP_SCREEN_ON_FLAG wake lock instead of talking
directly to the battery stats service.
- Optionally support animating screen brightness when
turning on/off instead of playing electron beam animation
(config_animateScreenLights).

Change-Id: I1d7a52e98f0449f76d70bf421f6a7f245957d1d7
/frameworks/base/services/java/com/android/server/power/Notifier.java