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
Lockscreen and statusbar now launch the intent on the current user.
Make sure that the intent resolution is made to the package manager
for the specific user, as the app could have been disabled for that
user or may have an alternative app installed.
Change-Id: I93b0f972d6c7e8880b146da83dc3d08a68fe7e51
when config_showMin3G is enabled to true in a CDMA device
Change-Id: I79a4fa200dc406fc7f9f4527165046541961ef69
Signed-off-by: Madan Ankapura <mankapur@sta.samsung.com>
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
Default implementation of Dreams will finish() on KEYCODE_BACK.
PhoneStatusBar will awaken() from any Dream when the Home key is pressed.
Change-Id: I55e2a5d533a7fb93debc4c54514dba3b9098f009
Added a new method to Context: startActivityAsUser() requiring the
INTERACT_ACROSS_USERS_FULL permission.
Show the correct Recents list, based on current user.
Added a getRecentTasksForUser() in ActivityManager. Hidden and requires
the INTERACT_ACROSS_USERS_FULL permission.
Change-Id: If5b56465efdd3ead36601a3b51ed4af157bbf35c
For kiosk-type devices that do not present any navigation UI. This allows
for clean selection of the implementation based on resource overlays,
without the need for the tablet or phone status bar implementations to
accomodate the desired behaviors.
Bug 5824373
Change-Id: Idcec70eef437904edda452b69e5eb7a3cc7094f7
(cherry picked from commit 5717f80927944c141f059162ecd69649488f8049 in ics-aah)
Signed-off-by: Mike J. Chen <mjchen@google.com>
The framework is no longer letting us skate by without a
default (unqualified) for of each resource; in particular,
the land/port aspect of the configuration appears to be
binding much later than it used to.
Bug: 6937365
Change-Id: I6bf72c76e707548168fefa9466dc196ffde33ab3
when config_showMin3G is enabled to true in a CDMA device
Change-Id: I79a4fa200dc406fc7f9f4527165046541961ef69
Signed-off-by: Madan Ankapura <mankapur@sta.samsung.com>
1. Notification panel on tablet does not handle back and home key events and
as a result the notification panel stays open. Hence, after opening the
notifications panel, pressing the back key on a keyboard will move back
in the app instead closing the panel. Same happens for the home key.
The expected behavior is if the panel is open the back button will dismiss
it and the key should be consumed by the panel. The home key should hide
the panel and the key should not be consumed by the panel so the system
can do the right thing.
bug:6902903
Change-Id: I06e8ceea1f51b998e6703d70dcb3a24128d5a581
If mobile data connection is disabled while there is active data
activity, the data activity overlay will not be removed and will
be stuck there. This patch fixes that.
Change-Id: I4cc1a14bb2e2d85687752657608e5989adfe9af1
While carrier info (or SSID for devices without mobile data)
will still be shown in a floating text view at the bottom of
the notification shade, emergency-calls-only mode will now
be shown in the notification panel header so that it cannot
be obscured by notifications.
Change-Id: I714b6801be2b9b631b86b51d229440445eff5e76
We don't actually need the raw size in these places.
The logical size is good enough.
Starting to move dependencies on surface flinger
and window manager out of the Display class.
Change-Id: I2065bee8e5bf7f42c5a452dd1e8479e40ebb0d37
Add an additional codepath to the "no connectivity" logic in
NetworkController to allow the PLMN bubble up from the
GsmServiceStateTracker, where R.string.emergency_calls_only
is returned if we're in emergency call mode.
Bug: 6804479
Change-Id: I0a77261e4393cc0dc32bae3e631ef196b2342f06
The navigation buttons for the old 720dp device used to be left-justified.
They're now centered. This change removes the 720dp configuration and
restores it to the original 600dp behavior, which is centered.
Change-Id: I98a2905bd015e12df74ab1f91551da0b0aecf805
Look for it in /sdcard/statusbar_gestures.dat, in "JSON
lines" format: one list of gestures per line; each gesture
is itself a list of objects representing motion events and
tags (annotations).
Exploded example:
[ // list of gestures
[ // this starts a gesture
{"type":"motion",
"time":1347697, // in SystemClock.uptimeMillis() base,
// like MotionEvents
"action":"down", // down, up, move, cancel, else numeric
"x":277.61,
"y":1.00
},
{"type":"tag",
"time":1347701,
"tag":"tracking", // "tracking" or "fling"
"info":"collapsed" // extra stuff
},
... // more events
],
... // more gestures
]
// newline
[ // another list of gestures
...
]
...
Change-Id: Ifacbf03749c879cd82fb899289fb79a4bdd4fc3b
For activities with a null taskAffinity, simply finish the current task.
(They probably shouldn't have specified a parentActivityName anyway.)
When launching into app info from ResolverActivity, launch the app info
page in the current task with FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET. Back
will return to the resolver, and Up will jump to Settings.
When launching into app info from RecentsPanelView or BaseStatusBar,
since this is a system affordance akin to notifications or widgets,
build the full task stack for the app info activity with
TaskStackBuilder and launch it as a new task.
Change-Id: I73b1941d0f52bd8b30382b5e17edd8ceb058c70d
