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
Add a new mode, controlled by sys.use_fifo_ui property, that enables the
top app's UI and RenderThread to be SCHED_FIFO. This eliminates almost
all jank due to scheduling competition with non-UI critical
threads. This mode may not be suitable for all devices.
bug 24503801
Change-Id: I7b8a31830ad80f7efa00236928d5476998ed4e00
* changes:
Fix synchronization error for Seamless rotation.
Disable seamless rotation while animating.
Force CROSSFADE rotation when launching from double tap gesture.
When activity transition triggers a rotation change, the starting
window will normally be the top window at the time we try
to select the window animation. However, these layout params won't
have the apps rotation animation set (as the client code will set that
on the real window, not the starting window). Eventually we would
like to add API to specify rotation animation via manifest to solve
this problem cleanly. In the mean time, we can force a specific rotation
animation from the double tap gesture, and clean up some camera
ugliness. We accomplish this by attaching an animation hint to
ActivityOptions.
Bug: 28838855
Change-Id: If052cd8cbae76651da43f3b4c590cd9dcc1afc0f
With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION. The temporary
permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.
If we do not do this and there is an application that forgot to call
that method then there is no way for IME developers to prevent
permission denial from happening in the application except for relaxing
the default permission of the ContentProvider just because of such an
application.
Although application developers are still expected to explicitly call
InputContentInfo#{request,release}Permission(), forgetting to call
InputContentInfo#requestPermission() does not hurt the user anymore.
With this CL, calling InputContentInfo#requestPermission() after calling
InputContentInfo#releasePermission() is also allowed.
Bug: 29892936
Change-Id: Id955435dd2e72549ee7134f46b3c6951581694ad
This reverts commit c4b8f36de5.
Having InputContentInfo#requestPermission() should not hurt developers,
but we can polish the behavior in a subsequent CL without changing
the API.
Bug: 29450031
Bug: 29892936
Change-Id: I1b43c19417b643d0c269af860db2d309b73a90d5
It turns out that requiring editor authors to call
InputContentInfo#requestPermission() as needed is just confusing and can
cause compatibility issues, because if an editor author forgot to call
that method then there would be no way for IME developers to prevent
permission denial except for relaxing the default permission of the
ContentProvider just because of such an application. This is not what we
want to see.
My conclusion is that the system should automatically call
InputContentInfo#requestPermission() (or do any equivalent operation)
when InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION is
specified, like we have done in Context#startActivity().
With this CL, the system automatically grants a temporary URI permission
to the target application when the IME calls
InputConnection#commitContent() with
InputConnection#INPUT_CONTENT_GRANT_READ_URI_PERMISSION, and the
temporary permission will be revoked by any of the following events:
- InputContentInfo#releasePermission() is explicitly called by the
target application.
- The target application returned false in
InputConnection#commitContent().
- All the InputContentInfo instances copied from the original one are
GC-ed.
Bug: 29450031
Bug: 29892936
Change-Id: I37fb744e4d3d1c59177fb0a9be4ef5c325c9a39f
