History log of /frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
c428aae6429c3fd5e2037c3793af399d9f6e23bf 04-Oct-2012 Dianne Hackborn <hackbod@google.com> Fix issue #7267494, issue #7212347

7267494 Calendar is not syncing
Check for whether a content provider is dead before returning
it. This is kind-of a band-aid, but probably the right thing
to do; I'm just not sure exactly the full details of why this
problem is happening. Hopefully this "fixes" it, though I don't
have a way to repro to tell.

7212347 System power off dialog is only visible to user 0
Make it visible. Also turn on some battery debugging stuff and
clean it up so we can just keep it.

Change-Id: I5add25bf2a763c8dfe1df23bc5c753a9ea5d157a
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
1e3b98d47df596d0c4eadbdf60143709f8465b28 01-Oct-2012 Jeff Brown <jeffbrown@google.com> New internal API to eliminate poke locks.

Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.

Added a new WindowManager.LayoutParams field userActivityTimeout.

Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
edce6a797878792de2b0bde4360f3171b9e9d9d2 01-Oct-2012 Jeff Brown <jeffbrown@google.com> Remove clearUserActivityTimeout().

This function is not implemented and not needed.

Bug: 7165399
Change-Id: Ib1c50fabad6292ccf670404ba70aeb1242c4614d
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
120664816a9bf325b618d8dd40febae2e3636ec8 29-Sep-2012 Jeff Brown <jeffbrown@google.com> Get rid of preventScreenOn().

Bug: 7165399
Change-Id: I1968265ecd74fff4d85efd2ca03b1983425ea518
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
62c82e4d92cc0b856059f905d81885f7808a0e7d 26-Sep-2012 Jeff Brown <jeffbrown@google.com> Make DreamManagerService more robust.

Clearly isolated the DreamManagerService and DreamController
responsibilities. DreamManagerService contains just enough logic to
manage the global synchronous behaviors. All of the asynchronous
behaviors are in DreamController.

Added a new PowerManager function called nap() to request the device
to start napping. If it is a good time to nap, then the
PowerManagerService will call startDream() on the DreamManagerService
to start dreaming.

Fixed a possible multi-user issue by explicitly tracking for
which user a dream service is being started and stopping dreams
when the current user changes. The user id is also passed to
bindService() to ensure that the dream has the right environment.

Fix interactions with docks and the UI mode manager. It is
important that we always send the ACTION_DOCK_EVENT broadcast
to the system so that it can configure audio routing and the like.
When docked, the UI mode manager starts a dock app if there is
one, otherwise it starts a dream.

This change resolves issues with dreams started for reasons other
than a user activity timeout.

Bug: 7204211
Change-Id: I3193cc8190982c0836319176fa2e9c4dcad9c01f
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java
a421f6c0ba8c354e2a81830e6402654bbf732780 22-Feb-2012 Xavier Ducrohet <xav@android.com> Fix sdk layout rendering in JB.

Since JB, com.android.internal.R does not contain all the resources,
instead only the ones that are accessed through Java.
This means we need to dynamically generate IDs for resources that are
private and only accessed from other XML resources. This is done
through the DynamicIdMap class.

Also add a PolicyManager and a PowerManager since those are now
needed by ViewRootImpl?!?

Change-Id: If2ae8ad79502fa084d852664a44aefd46e01aec6
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgePowerManager.java