Bug: 62196835
Test: Created an accessibility service that displays a system
and a toast overlay, confirmed that it disappeared when we
reached the accessibility permission screen that uses this
flag.
Change-Id: Ic51ead670fc480e549512ba1d02f49d9c13bc3f0
Fix a bug where a malformed Parceled representation
of an AccessibilityNodeInfo could be used to mess with
Bundles as they get reparceled.
Bug: 36491278
Test: Verified that POC no longer works, a11y cts still passes.
Change-Id: I10f24747e3ab87d77cd1deba56db4526e3aa5441
(cherry picked from commit 687bb44b43)
from AOSP: https://android-review.googlesource.com/#/c/183305/
On the critical path of the cold launch of applications
the main thread of the started application tells the RenderThread
to create a surface. This process is synchronous and blocks
the main thread of the application until the creation
of the EGLContext is complete.
As a consequence the launch time of the application is delayed
by time spent allocating the EGL Context in the RenderThread.
With this optimization the launch time of any application
is improved (for example settings by 20 to 40 ms).
Change-Id: Ibf47aaa0abb8dedf7aa00693073db3785d9d6b08
Signed-off-by: Thomas Buhot <thomas.buhot@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
Fix issue #30766518: Document what targeting N does
Also small documentation cleanup in a few other places.
(cherry picked from commit b34cbedb4e)
Change-Id: I9560b29faa4f2674277349272af8193122a1f95e
The onKeyMultiple() event captures simulated, not actual, presses of
the same key in rapid succession. Adjusted the method definition to
include this clarification.
Bug: 2335983
Change-Id: Id01182d81dafe98df9e559ff24f9e1d5a1f949c3
Explicitly state that "local state" is local to the window
which has started the drag operation.
Bug: 31372686
Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
The following changes are in this commit:
Avoid destroying TextureView surfaces for onStop
bug:30238922
TextureViews will hold onto their backing surfaces, which will allow
them to resume gracefully when the app's surfaces are saved.
Now only resources that are destroyed for onStop are DisplayLists.
(cherry picked from commit 391d560402)
TextureView: destroy layer on destroyHardwareResources event
bug:30468770
(cherry picked from commit 1c16c37d86)
Fix NPE in TextureView
Bug: 30651595
(cherry picked from commit 3c2587f26e)
Fix NPE in TextureView
Bug: 30779663
(cherry picked from commit 7e237189c2)
Fix maps resume being blank
Bug: 30889568
Fixes an issue where mLayer didn't have
the mSurface set on it in certain resume
scenarios.
(cherry picked from commit 03df0834e6)
This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d)
Document that getClipDescription() and getLocaState() do not return valid data
when getAction() == DragEvent.ACTION_DRAG_ENDED.
Bug: 30016099
Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
Previously the DisplayMetrics passed to a new ResourcesImpl
object would be generated from the default DisplayAdjustments.
We now use the correct DisplayAdjustments for the ResourcesImpl
and make sure to update them for things like rotation changes.
Bug:29619314
Change-Id: If2ba0d7670a4554dcd3fde9766e2337f20a191fd
(cherry picked from commit 8e8d23214a)
Fix a regression where a change in insets would forceLayout on the
view hierarchy but not run the measure/layout as a result. This would
cause layout requests to become stalled until a window-level relayout
event.
Bug 29634368
Change-Id: Ia3f32f5891c8b32c06c13f95ebd0572233572b04
Bug: 29586513
Also gives BackdropFrameRenderer a direct-destroy
of Choreographer since it's hammering on new Threads
and we don't want to wait for the GC to release
FDs.
Change-Id: Id2ec0af2ee4d5304961c4ab87a104ccb92f35fc2
Bug: 29547000
Instead of shifting the window off screen fall
back to the UI-thread calculated values. This fixes
a race issue around tear-down where we stop
drawing long before our window is actually no longer
visible, as well as fixes a funky issue with
PRESERVE_GEOMETRY during first draw.
Change-Id: I792d1966f5aaee1e703295ae79166c723b97a1dc
Make sure that when our Resources get updated, that DisplayAdjustment
and Display properly reflect the potentially new screen dimensions.
Bug:28388969
Change-Id: I340550ea094ece87abc8790dd46aaa60ab3cedd3
No longer release permissions in finalize(), so that
apps do not have to maintain a reference to the
DragAndDropPermissions object.
Also make it parcelable, so that permission instances can be
retained across activity instances so that they can be
manually released.
Bug: 29162822
Change-Id: Ie604dd3e83ee45a8665d743449b91857dd54e896
We might have a pending MSG_RESIZED_REPORT, but if it's executed after
relayoutWindow, mPendingInsets will already be the new value and it'll
not forceLayout. So we need to forceLayout here to make sure the measure
cache is cleared.
bug: 29391054
Change-Id: I73793b1427b89e75700369ec3b37053a6a732f0d
Fixes: 29223302
If the surface only changed we want to just call onSurfaceChanged,
not onSurfaceCreated.
Change-Id: I65c8b210a7e34eaa2862020335ee7f6ef56eeac2
Un-reverts ag/1057448, but uses a version of Resources#getText
that returns null rather than throw an exception when no title
is available. This is the same call made before, so this change
should be safer.
Bug: 28744278
Change-Id: I8c123f4f6d74f796ab9e8ffcf955aaf881770da1
At the end of the animation (when going from larger to smaller),
we are left with a scaled surface, that we want to seamlessly
resize to an unscaled surface of the new size. Because we have scaled
the shadow region of the surface, the position of the content
will differ before and after the resize applies. We use new
SurfaceFlinger API to cause position updates to apply after
resize. Because we have to switch into SCALING_MODE_FREEZE,
we could end up prematurely cropping the window, so we
switch to using screen space crop for the pinned stack.
Bug: 28899837
Change-Id: I9b762a237413e4fa3d432e67d30c7125bfef484c
When calculating scroll amount, we should check whehter focus
is visible using before-scrolling position.
It's possible that the view is already scrolled, then visible
insets changes (eg. IME went away). Previous scroll position
still makes the focus visible, but it will leave the focus
in a bad position when it should be scrolled back.
bug: 29025892
Change-Id: I091f16bebc4c1e5ba831616c51ab2ac75d4c4b3c
