History log of /frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
65031a29132e50a7e233d61c1fedc99b88604c6e 05-Nov-2013 Michael Wright <michaelwr@google.com> Continue synthesizing data even after brightness adjustment

Bug: 11337887
Change-Id: I80adb330c4e9250965030626634002a1b9c999cf
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
ec0832133a2115e065eed6e330da95b5c518003b 12-Sep-2013 Jeff Brown <jeffbrown@google.com> Allow phone to enter suspend with positive proximity.

As part of the power manager rewrite in JB MR1, we removed the ability
for the phone to suspend with positive proximity because it was not
clear that the proximity sensor was always correctly registered as
a wake-up source. The sensor service itself does not contain any
code to manage wake-ups. Therefore proximity sensor based wake-up
relies on the sensor driver acquiring a timed wake lock when the
sensor reports a negative result. This behavior is not very well
defined in the sensor HAL so there is a chance that it will not
work reliably on all devices.

This change adds a new config.xml resource to specify whether the
device should be allowed to suspend when the screen is off due to
positive proximity. Devices that support this feature should set
the "config_suspendWhenScreenOffDueToProximity" resource to "true" in
their resource overlays. The feature is disabled by default.

Bug: 9760828
Change-Id: Ic65ab7df0357271b133e2e44f5e35e7756e1e9e0
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
3b971598ed28d45c176e3f9b076fc743a406296d 10-Jan-2013 Jeff Brown <jeffbrown@google.com> Improve heuristics for detecting wireless chargers.

On some devices, we need to apply heuristics to determine whether
the device is docked on a wireless charger because the charging
circuits do not provide sufficient information to know whether
the device is on the charger unless it is actually receiving
power.

The previous heuristics only considered the battery level to
suppress spurious dock signals.

The new heuristics also take into account whether the device
appears to have moved from its previous position on the dock.

Bug: 7744185
Change-Id: I5ba885dac25b37840b6db46b8a0f30968a06776c
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
7f3994ec2a5dce1a037f04714b1f25cab85affb6 04-Dec-2012 Jeff Brown <jeffbrown@google.com> Pin electron beam surface to natural orientation.

If a rotation occurred while the electron beam surface was showing,
the surface may have appeared in the wrong orientation. We fix this
problem by adjusting the transformation matrix of the electron beam
surface according to the display orientation whenever a display
transaction occurs.

The rotation itself is allowed to proceed but it is not visible
to the user. We must let this happen so that the lock screen
is correctly oriented when the screen is turned back on.

Note that the electron beam surface serves two purposes.

First, it is used to play the screen off animation.
When the animation is finished, the surface remains visible but is
solid black. Then we turn the screen off.

Second, when we turn the screen back on we leave the electron beam
surface showing until the window manager is ready to show the
new content. This prevents the user from seeing a flash of the
old content while the screen is being turned on. When everything is
ready, we dismiss the electron beam.

It's important for the electron beam to remain visible for
the entire duration from just before the screen is turned off until
after the screen is turned on and is ready to be seen. This is
why we cannot fix the bug by deferring rotation or otherwise
getting in the way of the window manager doing what it needs
to do to get the screen ready when the screen is turned on again.

Bug: 7479740
Change-Id: I2fcf35114ad9b2e00fdfc67793be6df62c8dc4c3
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
5244c93176497f7c151f85a46e46b534379603bc 24-Oct-2012 Jeff Brown <jeffbrown@google.com> Dim the screen quickly in response to user activity timeout.

Reverts a previous change that made the screen dim slowly instead.
The quick transition does a better job of attracting the user's
attention to the fact that the screen is about to turn off
unless the user touches the screen.

Bug: 7386034
Change-Id: I81e4d8939f6791b96352004984a9e5b2aab79788
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
e941b1e27f6aad8a351c3caa3e0ad5f53dbf3707 23-Oct-2012 Jeff Brown <jeffbrown@google.com> Improve auto-brightness hysteresis.

Reintroduced the stability time heuristic which requires brightness
to remain significantly above or below the currently accepted
ambient brightnes before effecting a brightness change. The
heuristic has the nice property of preventing light sensor noise
from causing oscillations in brightness even when the noise has
a relatively large magnitude (such as in low light environments).

The time bound and filter thresholds are current set so that
brightness increases typically occur within 5 seconds of a change
in the ambient environment. Decreases take somewhat longer and
typically occur within 10 seconds.

Changed the timing for brightness animations when the screen is
being dimmed due to a pending user activity timeout. The screen
now dims slowly but then brightens rapidly when touched.
Previously the screen dimmed quickly and brightened slowly which
felt somewhat unresponsive.

Fixed a problem where a brightness change might not occur because
the light sensor had not reported a new value in a long time.
Now we synthesize measurements when needed to ensure that a
transition will take place if appropriate.

Bug: 7387800
Change-Id: I998df2fec59922042a41a1ba4af97ea52c0bd02a
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
32dafe25ac2e06f127f48d6a5826537e11575f52 20-Oct-2012 Jeff Brown <jeffbrown@google.com> Reduce screen on/off latency.

Reduce latency of screen on/off and improve how it is synchronized with
backlight changes. Screen state changes are no longer posted to vsync
which should save time. What's more, the state change occurs on a
separate thread so we no longer run the risk of blocking the Looper
for a long time while waiting for the screen to turn on or off.

Bug: 7382919
Bug: 7139924
Change-Id: I375950d1b07e22fcb94efb82892fd817e2f780dc
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
4f0e969eabc336f6dfa31c6218efc1b3dec55139 19-Oct-2012 Jeff Brown <jeffbrown@google.com> Reduce auto-brightness jitter.

Apply additional hysteresis controls to prevent repeated brightness
changes within a short interval.

Bug: 7266090
Change-Id: I73122457f6f3200c80188d3716ce2baf38f6a0a6
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
3c584f20ac8fe9378c094ad3b63936bca35954ba 10-Oct-2012 Jeff Brown <jeffbrown@google.com> Use exactly the same timings for the ElectronBeam as JB.

Bug: 7318962
Change-Id: Ic04bac5b07ec64fed84a6381ee1916ddeed01255
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
9e316a1a2a8d734315bbd56a85308f9657a92913 09-Oct-2012 Jeff Brown <jeffbrown@google.com> Blank or unblank all displays as need.

Ensures that both the internal display and HDMI are blanked
or unblanked in tandem.

Bug: 7309812
Change-Id: Ie8b96d393e8bb20d23c92f3320142d9f7cf42aff
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
252c206984299d7ce91c27536cafe1bb2fb9628d 09-Oct-2012 Jeff Brown <jeffbrown@google.com> Improve the power off fade animation.

Fixes an issue where the dim surface alpha was not actually being
animated like it was supposed to.

Bug: 7224614
Change-Id: Iffd54367ca97ae7fd4b9603807f4e036750442b2
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
8b9cf1c8000eb581457713a5c0ce41c59f90c353 07-Oct-2012 Jeff Brown <jeffbrown@google.com> Reduce screen on latency, eliminate flashes.

Always use the ElectronBeam now, even when we are only animating
the backlight so that we will have a black surface remaining
on the screen after the screen turns off.

When turning on the screen, keep the black surface showing until
we unblock screen on then dismiss it as usual.

This change eliminates the flashing of old display content when
the screen is turned on. It also helps to conceal some of the
latency of turning the screen on. We always turn the screen on
immediately (even when screen on has nominally been blocked) and
rely on the black surface to hide the screen contents until the
last moment. Dismissing the black surface is practically
instantaneous compared to turning the screen on.

Bug: 7299370
Bug: 7139924
Change-Id: I57d13287acd05bd0a48811095bb02dc7bc7cbeb6
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
b76eebff47653daf0c98119aeb68b57cb9a46f9d 06-Oct-2012 Jeff Brown <jeffbrown@google.com> Allow the dim brightness to be brighter than the minimum.

Defines the lower end of the allowable screen brightness range
as the lesser of the dim level, the user brightness setting
minimum value and the lowest auto-brightness level.

Bug: 7295909
Change-Id: I7a72b4611631f9e51578205ff12898c5bae02b1b
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.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/DisplayPowerController.java
a52772ff26e41dbb242a78a1f30619e23fb13dd7 05-Oct-2012 Jeff Brown <jeffbrown@google.com> Support animating just the backlight when turning off.

Bug: 7224614
Change-Id: Ic9fa7a9e458c89d347b03bce6829f952bdf3b6a5
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
93cbbb25a56356cd36523809783a277fe92e312e 04-Oct-2012 Jeff Brown <jeffbrown@google.com> Allow phone to go to sleep while in call.

Bug: 7279383
Change-Id: Ia05490218f40a1843507b95ff48fa07910e582d4
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
db21284a7fb081065d26137891594bd8495b116f 01-Oct-2012 Jeff Brown <jeffbrown@google.com> Disable use of twilight mode for auto-brightness.

This adjustment is still experimental.

Bug: 7165399
Change-Id: I3fcf361933995d02a5329eeaec80155b39371ba3
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
631938f26dbc89e7e9530bb85d9f37706dba59f3 09-Sep-2012 Jeff Brown <jeffbrown@google.com> Enable auto-brightness adjustment feature with system prop.

This feature is experimental and disabled by default.

Change-Id: I183534370da7613557e4d1535f556873f8a763df
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
4ed8fe75e1dde1a2b9576f3862aecc5a572c56b5 31-Aug-2012 Jeff Brown <jeffbrown@google.com> More improvements to the display manager.

Added more complete support for logical displays with
support for mirroring, rotation and scaling.

Improved the overlay display adapter's touch interactions.

A big change here is that the display manager no longer relies
on a single-threaded model to maintain its synchronization
invariants. Unfortunately we had to change this so as to play
nice with the fact that the window manager wants to own
the surface flinger transaction around display and surface
manipulations. As a result, the display manager has to be able
to update displays from the context of any thread.

It would be nice to make this process more cooperative.
There are already several components competing to perform
surface flinger transactions including the window manager,
display manager, electron beam, overlay display window,
and mouse pointer. They are not manipulating the same surfaces
but they can collide with one another when they make global
changes to the displays.

Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
bd6e1500aedc5461e832f69e76341bff0e55fa2b 28-Aug-2012 Jeff Brown <jeffbrown@google.com> Add initial multi-display support.

Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.

Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.

Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.

Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.

At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.

Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.

Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.

Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.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/DisplayPowerController.java
00a8f4ff627584f4d9a8ae0cd83f87786005e16d 22-Aug-2012 Jeff Brown <jeffbrown@google.com> Make the electron beam animation shorter.

Now using about the same duration as it used to have when
it was implemented in Surface Flinger.

Change-Id: I09b28222379f4b6583f1f7b34188cc36c50509e9
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
aa202a6dc33d331cbd9e34a1bb5f74db6284dda6 22-Aug-2012 Jeff Brown <jeffbrown@google.com> Add a mechanism to adjust auto-brightness at night.

Uses the twilight service to determine the hours of
sunrise and sunset. Shortly after sunset or before sunrise
gradually start to apply a gamma correction factor to the
auto-brightness calculations to make the screen a little
dimmer at night.

The effect is relatively small and is mostly noticeable
in dark rooms. This is just a first pass at the algorithm,
we can tweak the adjustment later to ensure that it has even less
impact in moderate or bright environments.

Change-Id: Idf89022a5d0bb52975e04779352d53fa63371178
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
330560f53bccd06be805fee1b7988162119d1295 22-Aug-2012 Jeff Brown <jeffbrown@google.com> Add support for auto-brightness adjust, but leave it disabled.

Auto-brightness adjustment applies a gamma correction factor
between 1/3 and 3 depending on the setting. This feature
is disabled for now.

Change-Id: I2b300b5c455da545bea56b2bae5bc7903e30f30e
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
5356c7dc72e80bbadd0ffbc69cfe3ea333280785 21-Aug-2012 Jeff Brown <jeffbrown@google.com> Disable electron beam on animation.

We want the screen to come back on as soon as possible.

Change-Id: Ifdaa2e88d19590c3da53be985dd886633e5cac59
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
5f47ba4db739d0db6feb8ce899764dbf87855901 20-Aug-2012 Jeff Brown <jeffbrown@google.com> Adjust auto-brightness time constants.

Specifically, dim a little more slowly.

Change-Id: I10d66a83ddc3a63f8c93d740a0cb116e6c974d10
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
6307a150d374cec7b20f80a68800bbf69f495839 20-Aug-2012 Jeff Brown <jeffbrown@google.com> Fix some proximity sensor bugs.

Forgot to clear waiting for proximity negative flag.
Waiting for proximity negative also shouldn't turn the screen off
if it is currently on.

Change-Id: I9885b2f54b185beb961acda44176bc5f11a9f58b
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
98365d7663cbd82979a5700faf0050220b01084d 20-Aug-2012 Jeff Brown <jeffbrown@google.com> Refactor for multi-display support.

Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.

Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).

Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.

Add stubs for some new display manager API features.

Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.

Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
13c589b66c47aa4d988eecce9a12c39d580939c9 17-Aug-2012 Jeff Brown <jeffbrown@google.com> Animate brightness with electron beam.

Also added an internal flag to control whether the electron beam
on animation is used. It's on for now but we might want to
turn if off if we can't get the HAL to provide the
necessary screen on synchronization on all devices.

Change-Id: Iaa3cfa0fd61de10174e68351e4db890eff2d2918
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
1a30b55036c2279d72ba69cb1107ec5f6f40d5e9 16-Aug-2012 Jeff Brown <jeffbrown@google.com> Use spline interpolation for auto-brightness.

Strictly speaking, this is a change in behavior for all products.
Instead of using discrete zones, they will all now use spline
interpolation. We could make this behavior configurable
but there seems to be little point to it. The range of brightness
values used will be more or less the same as before, it's just
that what used to be the brightness value for all levels within
a particular zone now becomes the brightness value for the
highest level in that zone and lower values are used for lower
levels within the zone.

Change-Id: I39804ee630ba55f018e1e53c0576b28e7bd27931
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.java
06565b64de1953fc9534f789b2e8b8fd70758979 16-Aug-2012 Jeff Brown <jeffbrown@google.com> Improve auto-brightness debounce.

Change-Id: I045e2a14cb31ff987a22872733c442fc92ebadbf
/frameworks/base/services/java/com/android/server/power/DisplayPowerController.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/DisplayPowerController.java