diff options
author | Filip Gruszczynski <gruszczy@google.com> | 2015-08-31 08:57:24 -0700 |
---|---|---|
committer | Filip Gruszczynski <gruszczy@google.com> | 2015-08-31 17:32:37 -0700 |
commit | d66af6a65533e86468db402907b35ed3e96e6bec (patch) | |
tree | bb3ab19cbbb1f1bfa30e828b27a2028b630f3b50 /core/java/android/content/RestrictionsManager.java | |
parent | 1e9bfc6461d3fe5455c9d7a21414ec66695b5798 (diff) | |
download | frameworks_base-d66af6a65533e86468db402907b35ed3e96e6bec.zip frameworks_base-d66af6a65533e86468db402907b35ed3e96e6bec.tar.gz frameworks_base-d66af6a65533e86468db402907b35ed3e96e6bec.tar.bz2 |
Don't perform layout while adjusting displays/stacks state.
When we detach the stack from the display we are in an inconsistent
state. We need to finish that operation, before we start laying out
things again. Otherwise we will encounter subtle bugs, where stack is
partially closed, but still used during the layout.
Display detachment was already doing the right thing and scheduling a
layout after it finishes the display detach. However, removing the
stack's windows was triggering immediate relayout and causing a crash.
This CL also adds some missing synchronization around
WindowManagerService.mStackIdToStack, which is in most cases protected by
mWindowMap.
Bug: 22191609
Bug: 23615329
Change-Id: I1e2fc42e1a5b673be808acdec473f85f138d7062
Diffstat (limited to 'core/java/android/content/RestrictionsManager.java')
0 files changed, 0 insertions, 0 deletions