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
The flag indicating that the Starting window is displayed was not
being cleared when the Starting window was removed. That caused the
goodToGo indication to falsely indicate that all windows were drawn
when in fact the destination activity had not yet been drawn. This
caused the animation to begin when it was still black behind the old
animation.
This fixes bug 6764727.
Change-Id: Iacef73b0335b9bde2cdc8d0b072034222cd728e8
Add a one way method to notify Views that the window has moved
on the screen. Fixes issues arising from the IME popping up and
translating the window that uses it. Accessibility was left unaware
of these movements and was drawing the box around the wrong widgets.
Similarly PopupWindow used getLocationOnScreen to determine how
much screen real estate was above and below the anchor point to
determine where to put an anchored window.
Fixes bug 6623031.
Change-Id: I4731a94d5424c1ec77bf1729fba8fc9ea34cae46
When launching only core apps, the wallpaper service
is not started. Without this change the WM waits
up to 30 seconds for the wallpaper window to be created even
though it will never happen. This introduces a significant
delay before the boot animation is dismissed so the user can
enter a decryption password.
Bug: 6263070
Change-Id: Ia975127a0bf09cf99818f7cc4fd6c0264b740ec6
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
In the course of the window manager refactoring into a separate
layout state, we introduced a bad interaction between the two
sides of the world. This resulting in multiple hops needed between
the two sides after an application has said it is finished drawing
its window, until the window/app transition is actually started.
Especially since these hops require going through the anim side
which is vsynced (so will delay its operation until the next frame),
this could introduce a notable delay until the window is first shown.
Fix this by re-arranging the code to make one straight path from
when a window reports it is shown to us starting the app transition
that is waiting for it. This change also includes various improvements
to debugging code that was done while working on it.
Change-Id: I7883674052da1a58df89cd1d9b8d754843cdd3db
Set up the Choreographer call from the animator, not from the
layout side. Introduce new class for transferring information from
layout to animator.
Change-Id: I7da032990f4b5eaeefcf92185901d896f25db3d2
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
This normally shouldn't noramlly happen, but it can in the case of
bug 6647334 (crash in LoadedApk.makeApplication) where the package
manager information becomes inconsistent, and it could also happen
if an app was uninstalled or started updating at just the right
time during a launch.
Bug: 6647334
Change-Id: Iba22efe1d646cdac46099b2135466309577dfa54
...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
Was counting on moving the app to the top to clear the flag
indicating that the app was being sent to the bottom. Since this
did not always happen the sendingToBottom flag was occasionally
left set. In this case the focus was skipped for that app and
consequently input was never propagated to it.
This fix clears the sendingToBottom flag each time the app
animations are completed.
Fixes bug 6691421.
Change-Id: I6f851dc5bedca95182db8490d87c876a71ad5fde
- Create class to transfer state from WindowAnimator to
WindowManagerService.
- Detached wallpaper state was shared between the two classes. This
CL isolates it.
Change-Id: I7bcee348bf9f9f8f0228f36c53d75e5c92fd84cb
Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
