Apply the test for configuration change to all windows. A year ago
this was the test but CL ag/247731 which fixed b/7428221 limited the
test to just Keyguard windows. A week later CL ag/248223 which fixed
b/7444971 applied the test to Wallpaper as well. Then two days after
that CL ag/249762 which fixed b/7453222 reverted the wallpaper. This
fix reverts the Keyguard qualification and restores the test to all
windows.
This fix has been tested against the repro steps for all three bugs
above. In addition this fixes bug 11033407. The fix for the bug is
described in the bug.
Change-Id: Ie0f4c7cd4697c1689c4f331d572359cf7ce934cf
A final layout pass should be done whenever the status bar has
completed its incoming animation.
Fixes bug 10387660.
Change-Id: I48c19015c53116b58cf73e20be32d1f64dd682ca
Activities launch starting windows before they are resumed. If another
activity is started after a first activity has launched its starting
window then it was possible that the starting window will never be
removed. An earlier fix, ag/368411, solved this by posting a delayed
message that would remove orphaned starting windows after 10 seconds.
This fix immediately removes starting windows that have been orphaned
through the above sequence.
A few code cleanups are also included in this CL.
Fixes bug 11029212.
Change-Id: I7a9befca92888aefe4000b90716c57c2aa572634
Windows were previously ordered by TaskStack/ActivityStack order. This
change provides a data structure in DisplayContent that tracks task
movement. Previously Recents and Home activity windows were always
adjacent because they were on the same stack. With this change windows
from other activities can be placed between the two.
Fixes bug 11338594.
Change-Id: Ie34443ff22f330d015141d97db79370c54920d28
The previous jank improvement only worked when closing
an app, not when bringing one forward (hitting home button).
This should cover the specific case that is being missed: Having the
Home task being brought to front over a translucent window, with
a wallpaper behind both tasks.
bug:11253262
Change-Id: I200ef6fe2dda8d9ab4e1f82059b4f888c59007f4
The WindowManagerService member mLowerWallpaperTarget is not stable
throughout an app transition. Relying on it to be stable causes the
intra-wallpaper animation to start out right but after the windows
have been relayed out there is no longer a lower wallpaper target.
This causes the wallpaper to start tracking the animation of the
current wallpaper target rather than remain stable.
Switching to a new variable that saves the state of wallpaper
animation at the start of the animation fixes bug 11240590.
Change-Id: I336a59c47665fcf61019f567b8663956ff0e4940
When a translucent window is closing, the transition
animation to Launcher is janky because Launcher is
expected to be 'opening' but it has always been open
underneath the translucent window. Therefore, the
animation applied to the translucent app appears
janky.
bug:11253262
Change-Id: I9b6af3291d119e6927401f63785b12f25573f4eb
If the keyguard is the wallpaper target the wallpaper cannot sit at
the bottom of the stack and must be directly beneath the keyguard.
Otherwise keep it at the bottom of the window stack.
App animations when the keyguard is showing should not be disabled if
the keyguard is also animating.
Fixes bug 10858941.
Fixes bug 10932680.
Change-Id: I8399837f6510ea16003f68b165e67439f3571ef4
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
Simplification where wallpaper was behind all apps didn't work when
keyguard and associated wallpaper needed to be above phone screen when
phone screen animated in and out. Instead phone screen was instantly
hiding the wallpaper.
Fixes most of bug 10932680.
This fixes the wallpaper disappearing as soon as the animation begins
when going from keyguard to phone. There remains jank going from phone
to lockscreen where the animation is not occurring and the phone
blanks out immediately.
Change-Id: Ie5f464acb2f6cefd2fb91f3b920a687ec7c15d76
- Include dreams in the conditions that disable transition animations.
This way there is no visibility of activities that are closing
behind the keyguard when an activity that dismisses the keyguard
starts up.
- Do not notify the keyguard mediator when the keyguard is dismissed
because a dream is starting up. This keeps activities from resuming
just because the keyguard is being dismissed.
Fixes bug 11064847.
Change-Id: I9d32fc96d518b1cdab511e187226a3cb889cf6d4
Rearranging the order of operations allows a newly added task to be
bumped to the top during window sorting. Also, redundant calls moving
the home task to the bottom when moving an app task to the top are
removed.
Maybe fix 10858941.
Change-Id: Ic42d2e7045175384591644675dd0e8013a7c7528
The requirement that a window that is invisible will not be drawn is
incorrect. In particular the test fails before a surface has even been
added (mHasSurface == false) or shown (mPolicyVisibility == false).
This was causing the screen to turn on before Keyguard had been drawn
and exposing surfaces that would have normally remained hidden.
Also, don't pass null into KeyguardServiceDelegate.onShown() or we
will immediately turn the screen on before Keyguard is drawn.
Fixes bug 11062635.
Change-Id: I964c7ef186d0a94678020b9c27ca6b79e5433350
Specifically, ignore any flags that alter the visibility of the navigation
bar and transparency.
BUG: 11082573
Change-Id: I17264dc55a1c6c3cb9b9cf92d5121799cecee5b8
Was skipping over the default assignment due to new null value for
windows (ag/361266).
Fixes bug 10987178.
Change-Id: I89efd41ab54b42de384eec84c5e937cc2a59d099
Bug: 10918599
Reduce the number of recent tasks to 10 on lowram devices
Use RGB_565 on low ram devices for thumbnails instead of ARGB_8888
Combined this saves ~9MB across system_process and systemui
Change-Id: Ieddcb512c7341a90097bc7cbc72d7355a775b416
Only use the stack bounds for the DimLayer bounds if there is more
than one stack on a layer. Otherwise cover the entire screen (and
more) with the DimLayer. This way there are no exposed regions when
rotating.
Fixes bug 10428085.
Change-Id: I7bfff12b69d59e86610621c498dab35cf0db8eb5
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
