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
The method has been moved to ThreadedRenderer and the native
implementation has been renamed to better reflect its intent.
Change-Id: I7ee6d578ad0c2ee20111edd424c7560a449f0b39
ThreadedRenderer is not synonymous with hardware rendering, so
remove references to hardware rendering when referring to
ThreadedRenderer.
Change-Id: Ic66a482ccf05f556ebe6ec194ce4f858f75bbb8b
