When quickly toggling between two apps, app could be resumed while
it's stopping but not yet stopped. Upon resuming, it could have
surfaces that's marked mDestroying and waiting for the stopped
to be destroyed.
We need to dispose these surfaces properly. If the window is already
removed, we destroy them. Otherwise, clear mDestroying flag so that
the window is ready to be used again. Leaving mDestroying=true makes
the window ineligible for certain things such as receiving wallpaper.
bug: 30255354
Change-Id: Id881653550595ab8e702d6950949bf202ac5a0d9
Provide a way for views to signal that they would prefer not
to have their parents scroll or otherwise rearrange when they
request focus to try to show the full focused view to the user.
In some cases this can be disruptive to the UX.
As of now, framework views do not respect this hint and custom
views such as those found in currently deployed support libs
don't either. The policy is left open to ViewParent subclasses
that implement requestChildFocus.
Bug 30256922
Change-Id: I55194de888fe2b8129be9a9aa21aa5e18cbb8296
Apps are told to query AccessibilityManager#isEnabled before
calling sendAccessibilityEvent. If accessibility is disabled
between the two calls, an app can crash. We can guarantee that
this won't happen on a process's main thread, but guaranteeing
it for all threads is messier. Rather than add the complexity
of tracking the state for all threads, only log an error in the
corner case that an accessibility event is requested on a
thread that doesn't have the process's main looper.
Bug: 28985452
Change-Id: I8369deefd83b0a6b04936ddfce55c53147756f1f
Also, standardize on a set of possible modes for the displays to
enter and separate the configuration of the color mode from the
configuration of the display mode.
Bug: 29044347
Change-Id: I6af0a7d1f11bc72d4cefc380f115c1fb00788864
In some corner cases, ViewRootImpl#setAccessibilityFocus
can be called twice for the same view. Make sure we're
actually changing views before clearing accessibility focus
to avoid inconsistent state.
Bug: 29637593
Change-Id: I5dc6f05bdeaec55c352417bfca92c11bd03c3c10
(cherry picked from commit da4692774c)
Alternative fix for b/29391054 ag/1152795 sends an MOVE message to
client which also force a layout, so we no longer need to force
it after the insets change in the traversal.
Reverting the following two related fixes as it does more
measures than necessary.
bug: 29391054
bug: 29533997
bug: 29634368
Revert "Fix layout issue after insets changed"
This reverts commit 76fdbb72c9.
Revert "Do a forceLayout if pending insets is changed after relayout window"
This reverts commit 71f2c31469.
Since they're recorded as floats, we should keep the
precision from the attribute values.
BUG: 30109000
Change-Id: I07e6a3ff771198bcb24d32e3dd06a79f10e51a7e
Document that getClipDescription() and getLocaState() do not return valid data
when getAction() == DragEvent.ACTION_DRAG_ENDED.
Bug: 30016099
Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
