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: I3460c45ea6da772a4ff76bb016de7aa4b051a673
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
Only force hide windows when the keyguard is animating in.
Fixes bug 6721572.
Change-Id: Iad7b8b811bcf0840726cbf6c6f279dabd08a3aba
Conflicts:
services/java/com/android/server/wm/WindowAnimator.java
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
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
Currently just grabbing the window state but we could grab
other things as part of the last ANR report.
Bug: 6680398
Change-Id: I23aa70907b1bdcb21c8acc556fde196ca790ef6a
People generally expect, if they are using FLAG_KEEP_SCREEN_ON,
that the screen won't immediately dim after it is cleared, even
if it has been passed the user activity timeout since the last
user interaction. So include the flag to reset the user activity
timeout when releasing its wake lock.
Change-Id: If7a8fea8faef3edbf13dff10a2f248adc9e3ff0b
- Sometimes the black background would flash; changing
animation durations to make this much less likely
- Fixing issue in Recents where we sometimes forgot
to disable drawing caches on views after enabling them
Call the Window client method dispatchAppVisibility when hiding or
showing wallpaper rather than wait until the next call to
performLayoutAndPlaceSurfaces.
Fixes bug 6645473.
Change-Id: I363f69f8db0affff92308e11ce52546401959d8f
The transition from clock to keyguard when restarting the device
was janky. The cause was that the clock app was animating away
which kept the adjustWallpaperWindowsLocked() method from setting
the keyguard as the new mWallpaperTarget. At the same time the
WindowAnimator saw that the keyguard was readyToDisplay() which
set mForceHiding true causing the clock to become hidden. Since
the clock was mWallpaperTarget the wallpaper was hidden at the
same time.
This fix does not allow mForceHiding to hide an animating
window.
Fixes bug 6649988.
Change-Id: Ie5cb0dfcc987d5ee1ad2351cf520629b8e301a2b
This keeps the background wallpaper from disappearing when expanding an
app that has a wallpaper background (e.g. clock).
Fixes bug 6649988. The second half of the bug, the first half will be
reissued as a new bug.
Change-Id: I209c9038469e4133586a927c92ef64ae43fb937f
Was canceling ongoing animations when starting a new animation which
caused the window of the first animation to restart. This looked
janky. The original cancellation was put in to stop the incorrect
animation being selected when quickly switching between an incoming
app and the homescreen. Reversing the cancellation no longer exposes
the original problem it was put in to fix.
One way to duplicate what this is fixing.
1. Slow down animations to 10x.
2. Run ApiDemos/App/Alert Dialogs/List dialog
3. Tap outside the list dialog and then tap the home button.
Tapping outside the list dialog causes the list dialog to animate
away. Tapping the home button then causes the app to animate away.
Before this fix the list dialog would revert to full size before
the app animates away. With this fix the list dialog continues its
original animation as the app animates away.
Fixes bug 6600726.
Change-Id: I29c940254808a321c3b6c2e4f4b7c78a72b47899
It turns out that sometimes the wallpaper target is migrated to the
bottom of the window stack and then mWallpaperTarget is set to null.
In particular this happens when the launcher all-apps screen is
brought up. When this happens the layer of the wallpaper is
correctly set below the previous wallpaper target.
An optimization in WindowAnimator was keeping the layer update from
propagating to the Surface object. This fix removes that optimization.
Fixes bug 6631717.
Change-Id: I800dd043ce8df83b4e5edbf710503135396bc01e
Bug: 6490204
-Fading to black in the recents layer
-Tweaking duration and interpolators
-Removing some unnecessary debug exceptions (Bug: 6642072)
Change-Id: Iba18fade7f874078111fc1d79a81830ee07617d4
1. Rotations do not go through standard closing of animations so the
wallpaper was not being hidden when the wallpaper target surface was
destroyed. This fix adds hiding the wallpaper when the wallpaper
target is destroyed.
2. The wallpaper target is nulled when switching from launcher home
screen to launcher all apps. In this case the wallpaper remains
visible but below visible layers. It should be hidden so that when
those layers adjust it is not exposed. (Separate fix for adjusting
wallpaper in this case will come).
Fixes bug 6629464.
Change-Id: I522f97dafc0cdcc0f933a825ec9a29d8f63590b5
Another location that potentially hides the wallpaper target while
leaving the wallpaper itself still visible. Causes the wallpaper to
show up when upper surfaces are transparent all the way down.
Fixes bug b6621986.
Change-Id: If75053160f041eb78868eda36b7820fb2110d069
Dimming was only turning off immediately for app-animated windows.
For removed windows dimming wouldn't turn off until the window was
completely gone.
Fixes bug 6628057.
Change-Id: I3ba6501b10a31b6f8c91012e17ad8734a84050c4
1. If the last touch explored location is within the active window we
used to click on exact location if it is within the accessibility
focus otherwise in the accessibility focus center. If the last touch
explored location is not within the active window we used to just
click there. This breaks in the case were one has touch explored
at a given place in the current window and now a dialog opens *not*
covering the touch explored location. If one uses swipes to move
accessibility focus i.e. to traverse the dialog without touching
it one cannot activate anything because the touch explorer is using
the last touch explored location that is outside of the active
window e.g the dialog.
The solution is to clear the last touch explored location when a
window opens or accessibility focus moves. If the last touch
explored location is null we are clicking in the accessibility
focus location.
bug:6620911
2. There is a bug in the window manager that does not notify a
window that its location has changed (bug:6623031). This breaks
accessibility interaction with dialogs that have input because
when the IME is up the dialog is moved but not notified. Now
the accessibility layer gets incorrect location for the
accessibility focus and the window bounds.
The soluion is when the accessibility manager service calls
into the remove thress to obtain some accessibility node infos
it passes the window left and top which it gets from the
window manager. These values are used to update the attach info
window left and top so all accessibility node infos emitted
from that window had correct bounds in screen coordinates.
bug:6620796
Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
Make sure that the wallpaper target exists and is visible before
exposing the wallpaper.
Fixes bug 6570335.
Change-Id: I1dddfe26683e84fd813e7bee884ba2bd4bb85272
Check to make sure that the closing wallpaper animation isn't used on
an opening app token. This can happen when a previous animation hasn't
completed when the next animation is starting.
Fixes bug 6557751.
Change-Id: Ib8bd4dd7de1e361f6fc0cab11d0997e70f9ddd0b
Incorrect animation was introduced with CL 196207 (perhaps in
combination with a later CL). Reverting part of that CL fixes
the incorrect animation and so far has not reintroduced the jank
that was fixed by that CL. If the jank reappears it should be
fixed in a different fashion than in CL 196207.
Fixes bug 6597505.
Change-Id: Ie8012237a8d49810ede51bd8d78ef8c2fd91ddd4
Add a new variation of ActivityOptions that allows you to
supply custom animation resources and get a callback when the
animation starts.
Use this in SearchPanelView to determine when to start hiding
the search panel instead of having a fixed delay.
Fix some issues in the activity manager where we would cancel
the options in cases where we should actually keep them to give
to the window manager for a transition. (Basically when the
activity being started is not actually ending up launched, but
just results in a shift in the activity stack.)
Note that this is not quite what the design calls for -- the
entire search UI is waiting and then disappearing when the
animation starts, instead of the ring first disappearing while
waiting for the time to fade out the circle.
Change-Id: Iee9a404ba530908d73cdbd4a9d0d2907ac03428f
Previous fix exposed an existing bug where we were using mAnimLayer to
determine the highest Surface layer. This fix uses mSurfaceLayer to set
the layer limits for making the screenshot.
Fixes bug 6586168.
Change-Id: Iaa3b43867aef795ca617ff4b8076428dfc91eaf2
