diff options
author | Dianne Hackborn <hackbod@google.com> | 2012-10-05 18:37:54 -0700 |
---|---|---|
committer | Dianne Hackborn <hackbod@google.com> | 2012-10-05 20:38:31 -0700 |
commit | 4c1e3183baf39ab69c0289c1511877a8bb0b0f75 (patch) | |
tree | c92b0102185b0b767a96db712d08ebdcd82892b7 /services | |
parent | f948500239803b2b7247ff5058e39e4d645c5b70 (diff) | |
download | frameworks_base-4c1e3183baf39ab69c0289c1511877a8bb0b0f75.zip frameworks_base-4c1e3183baf39ab69c0289c1511877a8bb0b0f75.tar.gz frameworks_base-4c1e3183baf39ab69c0289c1511877a8bb0b0f75.tar.bz2 |
Fix issue #7296314, issue #7296314.
7296314 Crashing dreams are stuck
7296510 Transition from lock screen to dreaming is really bad
The window layer for dreams is now moved down below the keyguard,
so that some of the expected stuff like crash and ANR dialogs can
be seen on top of them. While doing this, I reorganized how we
define the layers so the constants are just in the switch statement,
so it is much less crazy-making trying to read how things go
together.
We now have some special cases for when a dream is being shown
to turn off its animation if the keyguard is currently shown.
Since we know it will be hiding the keyguard we need it to be
shown immediately so that you don't see whatever is behind it.
Cleaned up some handling of when the lock screen is displayed
while a FLAG_SHOW_WHEN_LOCKED window is displayed, so that the
lockscreen doesn't transiently get shown and mess up the fullscreen
or system UI state. This also fixes problems with any normal
activity that is doing this.
Hid the methods on DreamService for setting lights out mode. It
doesn't make sense to have such methods on DreamService, because
you can just as well do that on your own View that is showing the
dream content, and when you can do that you can fully participate
in the (required) interactions about it such as being told when
the mode goes away.
The DreamService method for going fullscreen now uses the window
flag for doing this, which is what you want, because you want this
state to persistent on that window and not get knocked out if
something above the window tickles the system UI state.
Also fixed the problem where dreams that hid the status bar would
have a jerky animation when going away, since they were causing the
activity behind them to be layed out without the lock screen. This
is a kind-of ugly special case in the window manager right now to
just not layout windows that are behind a dream. Good enough for MR1.
Change-Id: Ied2ab86ae068b1db0ff5973882f6d17b515edbcd
Diffstat (limited to 'services')
-rwxr-xr-x | services/java/com/android/server/wm/WindowManagerService.java | 23 | ||||
-rw-r--r-- | services/java/com/android/server/wm/WindowStateAnimator.java | 2 |
2 files changed, 22 insertions, 3 deletions
diff --git a/services/java/com/android/server/wm/WindowManagerService.java b/services/java/com/android/server/wm/WindowManagerService.java index 0089046..545d1a9 100755 --- a/services/java/com/android/server/wm/WindowManagerService.java +++ b/services/java/com/android/server/wm/WindowManagerService.java @@ -8237,7 +8237,9 @@ public class WindowManagerService extends IWindowManager.Stub int seq = mLayoutSeq+1; if (seq < 0) seq = 0; mLayoutSeq = seq; - + + boolean behindDream = false; + // First perform layout of any root windows (not attached // to another window). int topAttached = -1; @@ -8247,7 +8249,8 @@ public class WindowManagerService extends IWindowManager.Stub // Don't do layout of a window if it is not visible, or // soon won't be visible, to avoid wasting time and funky // changes while a window is animating away. - final boolean gone = win.isGoneForLayoutLw(); + final boolean gone = (behindDream && mPolicy.canBeForceHidden(win, win.mAttrs)) + || win.isGoneForLayoutLw(); if (DEBUG_LAYOUT && !win.mLayoutAttached) { Slog.v(TAG, "1ST PASS " + win @@ -8282,6 +8285,12 @@ public class WindowManagerService extends IWindowManager.Stub //Slog.i(TAG, "Window " + this + " clearing mContentChanged - initial"); win.mContentChanged = false; } + if (win.mAttrs.type == TYPE_DREAM) { + // Don't layout windows behind a dream, so that if it + // does stuff like hide the status bar we won't get a + // bad transition when it goes away. + behindDream = true; + } win.mLayoutNeeded = false; win.prelayout(); mPolicy.layoutWindowLw(win, win.mAttrs, null); @@ -8306,6 +8315,8 @@ public class WindowManagerService extends IWindowManager.Stub mAnimator.mUniverseBackground = universeBackground; } + boolean attachedBehindDream = false; + // Now perform layout of attached windows, which usually // depend on the position of the window they are attached to. // XXX does not deal with windows that are attached to windows @@ -8323,6 +8334,9 @@ public class WindowManagerService extends IWindowManager.Stub // if they want. (We do the normal layout for INVISIBLE // windows, since that means "perform layout as normal, // just don't display"). + if (attachedBehindDream && mPolicy.canBeForceHidden(win, win.mAttrs)) { + continue; + } if ((win.mViewVisibility != View.GONE && win.mRelayoutCalled) || !win.mHaveFrame || win.mLayoutNeeded) { if (initial) { @@ -8338,6 +8352,11 @@ public class WindowManagerService extends IWindowManager.Stub + win.mContainingFrame + " mDisplayFrame=" + win.mDisplayFrame); } + } else if (win.mAttrs.type == TYPE_DREAM) { + // Don't layout windows behind a dream, so that if it + // does stuff like hide the status bar we won't get a + // bad transition when it goes away. + attachedBehindDream = behindDream; } } diff --git a/services/java/com/android/server/wm/WindowStateAnimator.java b/services/java/com/android/server/wm/WindowStateAnimator.java index 817a234..43f7a08 100644 --- a/services/java/com/android/server/wm/WindowStateAnimator.java +++ b/services/java/com/android/server/wm/WindowStateAnimator.java @@ -1500,7 +1500,7 @@ class WindowStateAnimator { int attr = -1; Animation a = null; if (anim != 0) { - a = AnimationUtils.loadAnimation(mContext, anim); + a = anim != -1 ? AnimationUtils.loadAnimation(mContext, anim) : null; } else { switch (transit) { case WindowManagerPolicy.TRANSIT_ENTER: |