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
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
Previous assumption -- that the drag window was defined at time of
DragState construction -- was false. The window, and hence the
Display, is not known until performDrag. This change delays assigning
DragState.mDisplayContent until the window/Display is known.
Fixes bug 7028203.
Change-Id: I5799005652c484ff0c45ab340ce3b9e4b784883e
The variables mKeyguardDisabled and mAllowDisableKeyguard were
being modified unprotected by mKeyguardTokenWatcher. Fix is to
serialize accesses to these variables by only referencing them
from the same Handler that mKeyguardTokenWatcher uses. Eliminates
synchronization blocks and mKeyguardDisabled variable.
Fixes bug 7045624.
Change-Id: I6355aa393507408296316bee61e178dc81e2a172
Make better use of Display object by saving it in DisplayContent.
Only use layerStack when referring to Surfaces. Get displayId from
default Display or default DisplayContent. Remove warnings.
Fixes bug 7038151.
Change-Id: Ie493f0f5e755dc9b91ee969ff561c2a098283ead
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
Was not previously checking to make sure that the appId was not
SYSTEM_UID (1000). This caused certain system windows to fail to
appear.
Change-Id: I939dc2f8a256acb84b7c413c7e00003a89aff6d4
When transitioning between old user and new user application windows
from the old user may not be shown because only one user's windows
can be shown at a time.
Change-Id: I4e17b36c9100c9457cc6eb3cb3b77f3a94fa2b41
The method showAllWindowsLocked can be called from the layout
side of the WindowManagerService. Previously the AppWindowAnimator
member mAllAppWinAnimators was created on the animation side. If
showAllWindowsLocked was called before the first animation of the
activity an NPE would occur. This fix creates mAllAppWinAnimators
when the AppWindowAnimator is created and also updates it with
current values before calling showAllWindowsLocked.
Fixes bug 6917136.
Change-Id: If3ace22022b65c6888bbb9d0575efe9a45d86475
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
The window manager was telling the activity manager to evaluate
the new configuration when first initializing the display, before
actually setting mDisplay, so it failed creating that first config.
Change-Id: I6e94fcf55b0587ccf15a5fd7ecbe2c9a0c201b96
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
Normally the ValueAnimator scale factor is applied the first
time a ViewRootImpl window session is created but that may
be too late for animators created by system services that
start early in the boot process. So set the scale factor
immediately whenever the setting changes.
Also make ValueAnimator.getDurationScale() accessible (but @hide)
for custom animators that want to apply the same scale to
their animations.
Change-Id: I0f5a750ab5b014f63848445435d8dca86f2a7ada
1.If a window is shown but never moved the window window
is never notified for its current location. Therefore,
accessibility nodes do not contain correct bounds in
screen coordinates.
bug:6926295
Change-Id: I7df18b095d33ecafffced75aba9e4f4693b0c393
Preloaded drawables now have a density associated with them, so we
can load the correct drawable if we are using a different density.
Window manager now formally keeps track of the density for each
screen, allowing it to be overridden like you can already do with
size, and relies on this density to drive itself internally and
the configurations it reports.
There are a new set of Bitmap constructors where you provide a
DisplayMetrics so they can be constructed with the correct density.
(This will be for when you can have different windows in the same
app running at different densities.)
ActivityThread now watches for density changes, and pushes them
to the DENSITY_DEVICE and Bitmap global density values for that
process.
A new am command allows you to change the density.
Fix a couple of bugs that turned up.
Remove touch/focus from display. Add iterators for access.
Respond to comments. Remove TODOs, and some deviceId parameters.
Change-Id: Idcdb4f1979aa7b14634d450fd0333d6eff26994d
This puts in most of the infrastructure needed to allow us to
switch between different densities at run time. The main remaining
uses of the global are to initialize the Bitmap object (not sure
what to do about that since it doesn't have anything passed in
the constructor to get this information from), and being able to
load drawables if we need a different density than what was preloaded
by zygote.
Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
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
1. The window manager was not notifying a window when the latter
has been moved. This was causing incorrect coordinates of the
nodes reported to accessibility services. To workaround that
we have carried the correct window location when making a
call from the accessibility layer into a window. Now the
window manager notifies the window when it is moved and the
workaround is no longer needed. This change takes it out.
2. The left and right in the attach info were not updated properly
after a report that the window has moved.
3. The accessibility manager service was calling directly methods
on the window manager service without going through the interface
of the latter. This leads to unnecessary coupling and in the
long rung increases system complexity and reduces maintability.
bug:6623031
Change-Id: Iacb734b1bf337a47fad02c827ece45bb2f53a79d
- Use local AppWindowAnimators in WindowAnimator rather than
using shared WindowManagerService objects.
- Use local WindowStateAnimators in AppWindowAnimator rather
than use AppToken's WindowState objects.
- Remove redundant WindowManagerService parameter passed to
AppWindowAnimator ctor.
- Keep from copying parameters from performLayout if the
parameters haven't changed since the last copy.
- Link WindowStateAnimator to AppWindowAnimator to keep
from going through WindowStateAnimator.mWin,
WindowState.mAppToken and AppWindowToken.mAppAnimator.
- Converted attached WindowState in WindowStateAnimator to
WindowStateAnimator to eliminate multiple conversions.
Change-Id: I5e35af88d8fdc1a7454984eaea91a1bc4f926978
Previous to this change the forceHiding variable was a boolean. This
change recognizes the different configurations of the keyguard by
defining separate states for forceHiding and testing for window
visibility differently in each state.
Fixes bug 6786114.
Change-Id: I078e0df7865ddafe498ee46e02110c3a017386d0
Provide separate copies of mWallpaperTarget, mWallpaperTokens, and
mLower/UpperWallpaperTarget in the layout and animation sides of
Window Manager.
Simplify constructors of WindowAnimator and WindowStateAnimator.
Change-Id: I7e35794a432c25c4194c046e9e27150d1c905403
A recent optimization to only send updates to WindowManagerService
when there is something to report backfired. One bit indicating
change had negative polarity so the update should also have been
sent when this bit was cleared. This change alters the bit to
positive polarity.
Fixes bug 6780496.
Change-Id: I3336812a60534ebffc9e94b2fb1d0df4d6969bca
Wallpaper offset was passing through H Handler before being set.
It isn't part of animation and wasn't going through animation anyways.
This change goes back to original implementation of setting
wallpaper offset directly from call.
Change-Id: Ied88e2dc042af814b5ba91c7efb839bd82682567
The controls for the DimAnimator were going through the H Handler
to sync with the Animator. We are switching to using the
LayoutToAnimator object for passing data from layout to animator.
Change-Id: Ib6d0afabba781c88bcc1c525e3ae424cf19ac1ad
It will be better to have the object that moves layout parameters to
animation on the layout side, and the object that moves animation
parameters back to layout on the animation side. That way we can
do partial filling of these objects without calling across. We
may never do partial draining of these objects.
Change-Id: I88826fa97350f96e309beef386885f55a9a73305
Separate updateWindowsAndWallpaperLocked into two methods,
updateWindowsLocked and updateWallpaperLocked. Eliminates mForceHiding.
Change-Id: I3958cfae09283aaa7f1781d1b54ef224d8e80f3f
