Keeping all activity=>task changes in master and removing them
from jb-mr2.
Revert "Update histories simultaneously."
Revert "Add null check to setAppGroupId."
Revert "Fix crashing bug in validator."
Revert "Switch topRunning* and moveTaskTo*"
Revert "Begin switch over to task based history."
Revert "Reset and reuse Iterators and don't new() one."
Revert "Remove AppWindowToken lists."
Revert "Fix build."
Revert "Remove unused App methods."
Revert "Stop using AppToken movement and start using Task."
Revert "Replace access to mAppTokens with AppTokenIterator"
Revert "Refactor setAppOpVisibility implementation."
Revert "Add AppWindowTokens to TaskList."
Revert "Make ActivityStack.mHistory private."
Revert "Migrate AppWindowToken lists into DisplayContent."
Change-Id: I5722c9a4956dccb52864207e2967690bc58e4ebb
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
- Convert double iteration over DisplayContents and WindowLists to
single iteration over AllWindowsIterator.
- Use existing change check in show() and hide() to trigger animation
scheduling rather than propagate change state up through calling tree.
Change-Id: Ic703a9fddebacbd0785bd5a186e95f9d0b128c42
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
Do not treat a window that is animating as being onscreen until it
has been drawn. The indication that a window was "gone" was occurring
too soon resulting in windows appearing before the status bar came
back and having to be drawn twice, with and without the status bar.
By waiting for the window to be drawn the status bar appears and the
window does not have to get redrawn.
Bug 7696315 fixed.
Change-Id: Ic93bf6eed03cf12a92a656791725a6d26e0ad0e9
1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.
Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.
The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.
bug:7410464
2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.
To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.
This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.
bug:7344059
Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
After finding a window in the window list we turn around and look in
the AppWindowToken.windows list for it. If it is a child of a window
in that list we should use the parent windows index as the search
result. Instead we gave up and ended up inserting the window at the
beginning of the windows list.
Bug 7357465 fixed.
Change-Id: If77f343b8597bfbb0b7fa41dedf7972d78d03020
- If a window was hidden while the configuration changed and then
changed back WindowManagerService would not know that the change
had ever happened and wouldn't notify the window of this. Most
windows wouldn't care but because Keyguard inflates layouts while
it is hidden...
Bug 7094175 fixed?
Bug 7501099 fixed!
Change-Id: If27f5f1d333602dac7719dd39dbdf3fe7954aa06
...lockscreen sometimes and remains black / blank
The problem was that we were using the animation-side wallpaper state
in cases where it was not updated yet.
The mWallpaperTarget variable is propagated over to the animation
side when the main window manager state updates. On the animation
side, this is used by hideWallpapersLocked() to determine if the
current wallpaper should be hidden.
The problem is that various paths to hideWallpapersLocked() can
come from the layout side of the window manager instead of the
animation side. This causes the problem here because in this case
the wallpaper state may not have yet been propagated to the
animation side, so it could incorrectly decide to hide the wallpaper
because it thinks there is not a target when in fact a target is
set in the layout side. This won't get fixed until some time way
later that the layout side decides that a new window is being shown
that may need to have the wallpaper shown.
The fix here is pretty gross, but as safe as possible -- the
hideWallpapersLocked() function now uses either the animation or
layout wallpaper state depending on where the call to it is coming
from.
Change-Id: I9250bfeae6e11c1761760bcc696fdb33fb5c8a5f
...background for lockscreen sometimes and remains black / blank
There was a bunch of state not being put into the dumpsys output.
In particular, the current wallpaper target of the WindowAnimator
was not being included. I think the problem is that these targets
are not being updated from the main window manager state at some
point where they need to be.
Change-Id: Ic795047f6aea9b6f72d5550bccc9f8d76c6ecb67
Widgets that did not launch Activitys would not display the unlock
screens when they were tapped. Now any window that is shown with
FLAG_DISMISS_KEYGUARD set while the keyguard is locked will
cause the unlock screen to be displayed.
Bug: 7301530 fixed.
Change-Id: I90d11b52d2b63260bdb5f2b6eb7e98eb7a4d9331
When a window is attached to another window use the parent window's
attributes to determine whether the child window should be shown
to all users.
Bug: 7328633 fixed.
Change-Id: I9601c149af87f624378e6895063bb3179d4f845e
Removal of the mExiting test in a previous CL was a mistake leading
to z-order errors. In particular the auto complete dialog was on top
of the IME and was being dismissed due to touches on the IME.
Restoring mExiting alone missed cases where apps were exiting which
don't set mExiting. Adding a test for membership in mClosingApps
fixes that.
Bug: 7327220 fixed.
Change-Id: I3965b8a07080d1347bdada51ffeafe6ef2e32c8e
The query WindowState.isDisplayed did not take into account being
displayed due to app animations.
When an existing input method target was animating away the logic
for detecting if it was still on screen was faulty. This led to
assigning the input method to a layer below its target and obscuring
the input method until the animation was complete.
Bug: 7296703 fixed.
Change-Id: Ib00db4f21b726ed57d25d6a1e796b65a7d45ee97
The new attribute allows an Activity such as the alarm to appear
on all users screens.
Bug: 7213805 fixed.
Change-Id: If7866b13d88c04af07debc69e0e875d0adc6050a
Created a new flag that indicates that a window should be shown
to all users. For the flag to be valid the owner of the window
must have system permissions.
Also separated system window types into those that show to all
users (e.g. StatusBar, Keyguard, ....) and those that appear only
to the owning users (e.g. Drag, ANR, TOAST, ...). Those that appear
only to their owner can override their default behavior using
the new flag (e.g. LowBattery).
Fixes bug 7211965.
Change-Id: I1fdca25d57b7b523f0c7f8bceb819af656c388d4
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
- 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
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
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
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
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
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
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
- 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
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
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
The Starting window was being made visible early because the app
token had the dummy animation set. When the real animation started
the Starting window picked it up and became transparent causing
the underlying window to become visible again => jank.
Fixes bug 6691421.
Change-Id: I95fe88d2887760e6da3adedeb6be300eb6755283
Three problems fixed:
1. When one Activity took over for another Activity not all of the
starting window state was being copied over. Now copying over more
parameters.
2. When the visibility of an Activity was being changed the dummy
animation was overwriting the existing animation. If that animation
was the starting window animating then it started over when the
dummy animation was assigned. Now the dummy animation no longer
replaces an existing starting window animation.
3. The test for whether to animate away the starting window only
looked to see if the Activity had already drawn a window but did
not include the starting window. This caused the starting window
to immediately be hidden when the Activity was removed if no
windows were drawn, thereby exposing the fading window behind.
Now the starting window is included in the hasAppShownWindows test
and is animated away if it is exposed.
Fixes bug 6691421.
Change-Id: I4d32a1546c201652574a44d9e7f2752f1f1eb5a6
...or settings from lock screen
When a window is drawn, the code to determine whether it should now
be shown was calling WindowState.isReadyForDisplay(). Part of the
condition of this function is that it is not ready if a policy is
forcing the window to be hidden -- which is the case when the lock
screen is shown. As a result, we wouldn't show the window at that
point, so wouldn't tell the activity manager that the token's windows
are visibible, and wouldn't tell the lock screen to go away.
This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(),
which is the same as the original method but ignores the policy visibility
for app windows. This allows windows to be go through the complete
path of handling when the window is finally drawn and telling the
activity manager about it, even if behind the lock screen. By making it
a separate function, we don't impact any other code that is calling the
old function and may be relying on its behavior.
Also cleaned up a little of the dumpsys output. Most important, the
new ANR section is now moved to the top, since we want
"adb shell dumpsys window" to still give a nice summary of what we
normally care about -- the window stack and important global state.
Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
