History log of /frameworks/base/services/java/com/android/server/power/ElectronBeam.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a86ab640f7bb0bf3cb4eaed80473ca8c5d131903 30-Aug-2013 Igor Murashkin <iam@google.com> Surface: Change OutOfResourcesException to be a runtime exception

- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException

Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
97f0aa6f8a8b7c1ed41786404423b9c9fcf789b8 06-Sep-2013 Mathias Agopian <mathias@google.com> tweak the electron beam animation a bit

we make the "beam" vanish in the center of the screen.

Bug: 10641933

Change-Id: I61fdb4d46e9f62dc80d65356a884dff0b177384a
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
21ef9647e8bd9997ed63f891b13bc3cc0f566b52 25-Apr-2013 Jeff Sharkey <jsharkey@android.com> Avoid leaking Surface native object.

Bug: 8721827
Change-Id: I8d6192b8eb47911fcf4964de399c7dba94ed9286
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
86e1bc730570765355dc8789b5c6de6962a053cc 14-Mar-2013 Mathias Agopian <mathias@google.com> fix CloseGuard usage in Surface

Bug: 8375415
Change-Id: I03e9f318c2ad586f4bd93b280557ada66121d275
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
0449a40586b45ee05f760802020dc2f8a6e0506b 02-Mar-2013 Mathias Agopian <mathias@google.com> screenshots can now go into a Surface from java

A Surface can trivially be created from a SurfaceTexture.
Update ElectronBeam to use this new API.

Bug: 6940974
Change-Id: I20459443d0d853e3f8ae23104c08d185c336abea
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
29479ebe1007361222bf6ab4d5e2a27927d4b8e8 14-Feb-2013 Mathias Agopian <mathias@google.com> clean-up following Surface split

Change-Id: I853a76d92d957ee38a36fcdd280d6407ec316987
/frameworks/base/services/java/com/android/server/power/ElectronBeam.java
3866f0d581ceaa165710feeee9f37fe1b0d7067d 12-Feb-2013 Mathias Agopian <mathias@google.com> split Surface in two classes: SurfaceControl and Surface

SurfaceControl is the window manager side; it can
control the attributes of a surface but cannot push buffers
to it. Surface on the other hand is the application (producer)
side and is used to push buffers to the surface.

Change-Id: Ib6754c968924e87e8dd02a2073c7a447f729f4dd
/frameworks/base/services/java/com/android/server/power/ElectronBeam.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/ElectronBeam.java
78eb122450f127d66d4e8cf7f65cad80ea85d3ac 11-Oct-2012 Jeff Brown <jeffbrown@google.com> Dejank electron beam.

On some devices it can take hundreds of milliseconds to get a
brand new EGL surface performing in tip-top shape. To get it
ready make it do a few pushups before the show begins.

Bug: 7318962
Change-Id: I7ae92ce100c368327042a29ffa65faee9b567c8d
/frameworks/base/services/java/com/android/server/power/ElectronBeam.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/ElectronBeam.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/ElectronBeam.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/ElectronBeam.java
64a55af0ac700baecb0877235eb42caac59a3560 26-Aug-2012 Jeff Brown <jeffbrown@google.com> Add plumbing for new surface flinger display API.

Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.

Added JNI for all of the new surface flinger display API calls.

Enforced the requirement that all Surfaces created by
the window manager be named.

Updated the display manager service to use the new methods.

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