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
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
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
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
Synchronized methods make me cry so fixing this first before
I introduce any new functionality that could result in a deadlock.
Bug: 6548391
Change-Id: I9c006dc491ce205bfd86acf828dcebda2a63b2ca
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
Enable feature in config. Expose Dream in public api for unbundled apps.
Unhide package. Add isDreaming() method to service.
Re-arrange the Dream api a bit. (use onStart as hook for subclasses).
Coordinate properly with power manager.
Replace old dock mode (don't fire old intent).
Change-Id: I1318d20cc1613e5d862f2913f2fcdc9719302cf7
Bug: 6921930
In additional to adding the StringMode API for controling CloseGuard,
this checkin fixes several CloseGuard issues found booting a device.
Bug: 3041575
Change-Id: I4dffd184f49438d6d477ed81a1c2a2a5b56cc76b
Extract all UI behavior from dock observer and ACTION_DOCK_EVENT.
Also introduce a desk type to go along with the car type all through
the resource system, since we now need to have corresponding high-level
broadcasts for desk dock mode. As part of that I also reworked some
of the logic for switching modes to all funnel through a single
update() call that looks all of the current state to decide what to
do next, and fixed various locking issues.
In addition I found there were bugs in the configuration change
handling causing us to only switch into the car mode config and
then never get out of it. Unfortunately now that we are actually
changing the configuration for each mode change, the transitions
between them are really crummy as we restart all kinds of
activities. :(
The current implementation does not take care of location changes in the case
the network location is not enabled. The fix will use the passive location provider
to receive any location updates (gps and network) and using the network location
provider to trigger the passive provider.
Change-Id: I851bb1ff90e9103712a0e741528a6dfa5d4353c8
When the device is booted in a car dock the car mode needs to be set
as well, so that the status bar notification shows up and the system
is initialized the same way as if the phone is placed into a car dock
when it's booted already.
Changing the status bar behavior requires special permission.
Since disableCarMode is called out of a context that might not have this
permission, the calling identity is cleared before changing the status
bar behavior.
The automatic switching between night/notnight is based on the calulcation of
the civil twilight of the current location. The location is mainly retrieved
from the NetworkLocationProvider.
Automatic switching will only be available, when
1) the device is in UI_MODE_TYPE_CAR
2) the setting for the UI mode are set to 'automatic'
If mode is set to automatic, the next twilight is caluclated and
an alarm is set that timestamp. The alarm will trigger a new calculation
of the twilight and sets the UI_MODE_NIGHT to the appropriate value.
modified: services/java/com/android/server/DockObserver.java
new file: services/java/com/android/server/TwilightCalculator.java
- Low battery. (http://b/2320026)
- Dock/undock events.
- Keyguard lock/unlock events.
New system settings have been created to turn these on/off
and to specify the relevant sound files.
[Production notes: The provided low battery sound and dock
sounds were synthesized; the lock screen sounds are
processed samples of a ballpoint pen click mechanism.]
Bug: 2320026
Change-Id: I374285b0f94f59c7555bb8816580f5a8c802e90d
The device mode is now called ui mode. Furthermore is the order of
precedence for the resources now in such a way that the ui mode needs
to be specified after the orientation and before the density.
The ui mode can be set, like it is done for the locale, as follows:
IActivityManager am = ActivityManagerNative.getDefault();
Configuration config = am.getConfiguration();
config.uiMode = Configuration.UI_MODE_TYPE_CAR | Configuration.UI_MODE_NIGHT_ANY;
am.updateConfiguration(config);
To allow users to disable the car mode and set the night mode the IUiModeManager
interface is used.
The automatic night mode switching will be added in a separate change.
Use this in various places where it should serve no purpose to deliver
both broadcasts. This is intended to reduce somewhat the flurry of
broadcasts that we churn through during boot.
The fact that the phone is losing power will do this anyway,
and this fixes (or works around) bug b/2250075
(Desk dock clock app sometimes doesn't exit when removing a sleeping droid from the dock)
Change-Id: I7b8b6cfb44ca16d2d9eb67589cb9d9a108a8de82
Signed-off-by: Mike Lockwood <lockwood@android.com>
We now just don't send out dock broadcasts/launches when the
device is not provisioned. Good enough for our purposes.
Change-Id: Iee6384121675e0e9854745ec1168245e8a23a241
- New meta-data you can add to a dock activity to have it launched by the
home key when the device is in that dock.
- Fix a deadlock involving ActivityThread's internal content provider lock.
- New window flag to have a non-secure keyguard entirely dismissed when a
window is displayed.
- New WindowManagerPolicy APIs to allow the policy to tell the system when
a change it makes during layout may cause the wall paper or
overall configuration to change.
- Fix a bug where an application token removed while one of its windows is
animating could cause the animating window to get stuck on screen.
Change-Id: I6d33fd39edd796bb9bdfd9dd7e077b84ca62ea08
Categories CATEGORY_CAR_DOCK and CATEGORY_DESK_DOCK can be assigned to
activities to make them launchable on docked events.
This is a better mechanism than listening for ACTION_DOCK_EVENT with a broadcast receiver.
Change-Id: Ic5f3ab3555ce02ca922bc31ebba41978cefe8bda
Signed-off-by: Mike Lockwood <lockwood@android.com>
Docking station intents for dock switch driver.
Add DockObserver and updated Intent.java and systemserver.jave
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
modified: core/java/android/content/Intent.java
new file: services/java/com/android/server/DockObserver.java
modified: services/java/com/android/server/SystemServer.java
Docking station updates
Add constants for the dock
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
