This is the one relevant setting that moved from System to Global,
a move that we do not automatically redirect on writes.
Change-Id: I7b26d0c364695c4a10a7cd477db3dfcfe89d7ef5
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
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
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
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
The system depends on receiving reliable vsync signals from
surface flinger during the boot process. If it doesn't get them
because the screen is off then a hang may occur.
This isn't a problem when surface flinger manages the screen
blanking itself but it is a problem for devices that still
rely on early-suspend. When early-suspend is involved, the
screen may be off without surface flinger knowing. This is a
problem because surface flinger will only synthesize fake
vsyncs when it knows the screen is off, otherwise relying
on the hardware to generate vsync signals itself. Unfortunately,
the hardware won't generate vsync signals if the screen was
turned off by early-suspend, so we have a problem.
Bug: 6975688
Change-Id: Iaf4527f716bf4ea72cc3e6fdaf060855697b02f2
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
Don't activate on sleep if below the threshold, and quit any currently
running dream when the threshold is reached.
Bug:6999949
Change-Id: I961b350d24ee6f95e502228aaa57312b0ffbadc1
Previous to this change the WindowManager was notifying the
BatteryDtatsService about windows that keep the screen on. WM used a
custom WakeLock tag to indicate to PowerManagerService that it had
already notified the BatteryStatsService.
This change eliminates WindowManager notifying the BatteryStatsService
and lets PowerManagerService do the job.
Fixes bug 7030326.
Change-Id: I666dc6ef8f094b8d3d109fea6876be058e057b4f
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
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
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
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
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
Fixes b/6996990
Ideally, the HWC HAL should turn off the backlight when the display is turned
off. This patch enforces this at the PowerManager, which can guard against
errant HWC implementations.
Change-Id: Ibb826a02871c983f8a68034d010e68abe9c5c1d5
Signed-off-by: Iliyan Malchev <malchev@google.com>
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
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
It turns out OFF_BECAUSE_OF_TIMEOUT is not the best indicator
of actual screen timeout.
For example, it is the reason passed down when acquiring a wake lock.
This was causing us to launch Dreams in the wrong situations, and
deadlocking on calls to WindowManager.
This fix simply adds an additional check ensuring the intention is to
turn the screen off.
Change-Id: If8adff446b5b1fcb19424b45878b75bfd0552b90
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
The purpose of this change is to remove direct reliance on
SurfaceFlinger for describing the size and characteristics of
displays.
This patch also starts to make a distinction between logical displays
and physical display devices. Currently, the window manager owns
the concept of a logical display whereas the new display
manager owns the concept of a physical display device.
Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
This allows for the setting to be persisted or not.
Also turn on Bluetooth in System Server if needed.
It won't work currently because the service wouldn't have
started.
Change-Id: I15fa2bff93aa32134c1b565fcbe90ba68614b6a1
Changes to make Bluetooth Service part of the system_service.
These changes may be temporary.
Changes to update to the new disable API.
Change-Id: If89dba17e6e6c6daa53c37684221763a2da076e9
Conflicts:
services/java/com/android/server/pm/PackageManagerService.java
