If any window on the default display has focus, then it
gets focus as usual. If no window on the default display
has focus, then we consider windows on the secondary display.
In the future we will need more elaborate schemes for
managing focus across multiple displays, but this is enough
for testing purposes now.
Bug: 7183618
Change-Id: I21ddb9904eb9e574e42d28743aeca51f4ffebf64
We will be adding additional callbacks for other components.
This change makes it clearer how the input manager is started
and where the callbacks are initialized.
Bug: 6548391
Change-Id: I4b2a61482126a12b7cf11fafe513f846c76c11e5
Activity manager now updates window manager's current user id
directly and immediately rather than waiting for a broadcast
update. Window manager passes this through policy to the
KeyguardViewMediator and into LockPatternUtils. LockPatternUtils
no longer goes to Activity to get the current user id if it finds
that its local id is non-default.
Fixes bug 7193726.
Change-Id: Id5613e7a9fe9e5b49e83c26b74504f587c3998c2
- Checking for found wallpaper to match either mWallpaperTarget
or mLowerWallpaperTarget keeps from swapping the layers while
transitioning between two wallpaper activities.
- Fade out RecentsActivity while bringing up selected activity. This
keeps the RecentsActivity from showing through a launching wallpaper
activity.
- When moving a starting window from one activity to another clear
the startingDisplayed flag in the old activity.
- When moving a starting window from one activity to another assign
the new activity's mAppAnimator to the starting window's mWinAnimator.
- Only treat a wallpaper transition as entering if the mWallpaperTarget
is visible and not being hidden. Keeps from assigning the wrong
animation when activities are launched back to back and the
mWallpaperTarget is still animating away.
Fixes bug 7148089.
Change-Id: Idd405b1ba113f3345ca2116d141b474abe5bd4c0
Bug: 7136483
Store device policy information for each user and apply them when user switches.
Global proxy can only be controlled by owner.
Camera restriction applies to all users, if any one has an admin that disables it.
Storage encryption can only be controlled by owner, although other users can query the state.
Wipe data will only remove the user if non-zero, wipe the device, if zero.
Change-Id: I359be46c1bc3828fd13d4be3228f11495081c8f2
- New public APIs to find out when a user goes to the foreground,
background, and is first initializing.
- New activity manager callback to be involved in the user switch
process, allowing other services to let it know when it is safe
to stop freezing the screen.
- Wallpaper service now implements this to handle its user switch,
telling the activity manager when it is done. (Currently this is
only handling the old wallpaper going away, we need a little more
work to correctly wait for the new wallpaper to get added.)
- Lock screen now implements the callback to do its user switch. It
also now locks itself when this happens, instead of relying on
some other entity making sure it is locked.
- Pre-boot broadcasts now go to all users.
- WallpaperManager now has an API to find out if a named wallpaper is
in use by any users.
Change-Id: I27877aef1d82126c0a1428c3d1861619ee5f8653
Now that surface flinger lets us set a display projection,
the window manager no longer needs to place a black frame
around the content when simulating a different display size.
Bug: 7139798
Change-Id: I6014390f47444633d434ccf918cee5ff7b502869
This change removes the test for hidden when deciding whether to
do a layout. So layout begins as soon as hiddenRequested occurs.
Since hidden is cleared when animations starts considering hidden
in the layout decision will delay layout until it is too late.
In particular we were not executing a relayout on return to an
activity even though the screen had been rotated while away.
Fixes bug 6615859.
Change-Id: I5fb0b4bf2c253b910a7a192da04419236d8f09d9
1. The way for computing the magnified region was simplistic and
incorrect. It was ignoring window layering resulting in broken
behavior. For example, if the IME is up, then the everything else
is magnifed and the IME not. Now the keyguard appears and covers
the IME but the magnified region does not expand while it would
since the keyguard completely covers the not magnified IME window.
bug:7138937
Change-Id: I21414635aefab700ce75d40f3e913c1472cba202
The window manager now has a facility to provide a full-screen
animation, which the activity manager uses every time a user
switch happens.
The current animation is just a simple dumb slide until we get
a design from UX.
Also some cleanup: moved the portrait task animations to the
default config so we always have an animation for them, and finally
got the java symbol stuff out of public.xml.
Change-Id: I726f77422b2ef5f2d98f961f8da003e045f0ebe8
We now support scaling the logical display to fit the
physical display, whatever size it is. So we can allow
adb shell am display-size to use more or less arbitrary sizes
although we do enforce an upper and lower bound to
protect the user.
Change-Id: I5fe6ba32ad1f9e4fbcd6915f7d36850b987bbcc0
There were several problems resulting from the use of
mDefaultDisplay before displayReady() was called.
As it happens, we don't need mDefaultDisplay becase we
can get the information from the default display content.
Also modified the Configuration calculations to never
choose a SQUARE orientation. The constant is deprecated
and documented as no longer used, so we should make that
be the case.
Change-Id: I326ed7100030a81e24411e898e5243f28895ea22
The input system needs to know about the window that has
focus, even if it is on a secondary display. So now we
send it the list of all windows and indicate which display
they are on. We filter the list of windows as necessary
when delivering touch events.
To keep things simple, monitor input channels and input
filters are not supported except on the main display.
We also do not pass the display id to applications; it is
only used inside the input system for now.
Properly scale touch coordinates based on the viewport.
This will be needed to ensure that touch works on external
display as well as when the internal display is being used
to simulate a different resolution.
Change-Id: I1815579a52fcc852c519b5391fc7ab8767c2dc59
The window manager is no longer responsible for telling the
input system about the display viewport.
Change-Id: I932882bae55decef55f25093bb2a7ebac1620bb1
Tell the display manager whenever a given logical display
contains interesting windows. If so, then the display
manager arranges to show that content on a physical display,
otherwise it ignores the logical display and makes its
associated primary physical display mirror the default
display.
Assign DisplayContents when Displays are added, remove them when
Displays are removed, and update the DisplayInfo when Displays
change.
Change-Id: I36e08ec538055acabe1e24cdd12c40de4e47a158
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
Switch from a global mLayoutNeeded to one for each Display so that
we don't run layout on Displays that haven't changed.
Change-Id: Ib65c5c667933cceacc46b94f4e6e6bd613d5cb35
The WindowAnimator loop over each Display contained actions that
only needed to be done one time but were instead done once per loop.
Change-Id: Ia916b08cdb7670686e6295dbcef6a5ff27474099
The inner loop that ran over each display had a few problems:
- The Surface transaction was starting and stopping between each
display.
- The layout change bits were being applied globally so all
displays were layed out when only individual displays needed to be.
- Wallpaper and input actions were being applied each time through
the display loop rather than once only for the default display.
Change-Id: I924252bab28c426222a4bb73693accc4b21cecbe
- Refactor DragState to take Display instead of DisplayContent.
- Rename xxxAnimationLw methods in WindowManagerPolicy to xxxPostLayout
to reflect animation refactoring.
Change-Id: I502f2aa45a699ad395a249a12abf9843294623f0
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
