Removing one window causes its subwindows to also be removed.
We have to be careful when traversing the window list
because multiple windows may be removed at a time so we
don't get IndexOutOfBoundsException due to the window
list changing in unexpected ways.
Bug: 7273702
Change-Id: I0ed9ba00c325ad178ab28919ce2e763cb6fd38ba
Includes telephony, WindowManager, PackageManager, and debugging
settings. Update API to point towards moved values.
Bug: 7231764, 7231252, 7231156
Change-Id: I5828747205708872f19f83a5bc821ed0a801cb79
Added a new WindowManager.LayoutParams inputFeatures flag
to disable automatic user activity behavior when an input
event is sent to a window.
Added a new WindowManager.LayoutParams field userActivityTimeout.
Bug: 7165399
Change-Id: I204eafa37ef26aacc2c52a1ba1ecce1eebb0e0d9
WindowManager was notifying DisplayManager of content if any window
existed on a display. Now the window must be visible and we must not
be showing a Dream or the Keyguard.
Bug: 7214060.
Change-Id: I9ce4a49aabfbac22ff1e39a837199ce35b9f7503
...#testScreenLayout failures on JO
This doesn't actually fix it; I have concluded that the test is broken
(the platform is correctly reporting that this is a NOT LONG device
because in portrait once you account for the status bar and system
bar our size is 880dp high and 600dp wide, which is not enough for us
to be in the LONG config).
However while working on this I noticed that the code for computing
the configuration of the external display was wrong. I have fixed
that by putting this code for computing these parts of the configuration
in a common place that both the window manager and external display
code can use.
Change-Id: Ic6a84b955e9ec345a87f725203a29e4712dac0ad
- Restore test of hidden to isGoneForLayoutLw(), without that
we return false when setAppVisibility(true) is called which leads
to early layout of windows. Particulary on return from full screen
to non-full we lay out once before recognizing that the status bar
should be back and then again once the status bar appears causing
a jump. Fixes bug 6470541.
- Add a new test for configuration size changes to gone or hidden
windows. This forces a layout call to these windows which informs
them of the new size even though they are not shown until later.
In particular this keeps windows that were in the background
during a rotation from using their old boundaries on return.
Fixes bug 6615859.
- Consolidate WindowState.mConfiguration tests into WindowState.
Change-Id: I7a82ce747a3fcf7d74104dc23f1532efe64bd767
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
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
- 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
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 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
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
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
