The issue occurs because TextView#isFromPrimePointer assumes multi-touch
events are happening on the same TextView and relies on
ACTION_UP/ACTION_CANCEL to reset the Prime pointer id.
consider following scenario:
1. ACTION_DOWN (pointer 0) landed on ViewA,
ACTION_DOWN (pointer 1) landed on ViewB.
2. ACTION_MOVE landed on both ViewA and ViewB, triggering a drag.
3. When all fingers are released, ACTION_CANCEL (pointer 0) will be
landed on both ViewA and ViewB, so the prime pointer in ViewB is not
reset due to pointer index mismatch.
This CL always reset prime pointer id whenever ACTION_UP/ACTION_CANCEL
is triggered.
Bug: 157399040
Test: manual
Change-Id: Id35d9eac939378482fa50e85bb5cda58469240ad
Don't construct a new locale-specific NumberFormat every time a progress
bar's state is refreshed or updated. We now do this only when necessary
due to a locale change.
Bug: 161264248
Test: atest ProgressBarTest
Change-Id: I349ec28268a3471184e5746b164f81428ad80cc8
In RV, a view could be temporarily detached in one draw cycle.
Accessibility events sent during this time will be lost. To prevent the
events from being lost, we will set a flag when a view is detached by
parent. And when sending accessibility events for detached view, we will
delay it a little by
ViewConfiguration.getSendRecurringAccessibilityEventsInterval. This way,
if the view is attached in one draw cycle, the events will be sent out.
Also add more setStateDescription() in CompoundButton to for safer code.
(this is not the cause of this bug though).
Fix: 151125936
Test: tested that the bug is fixed.
Change-Id: Iffca8c87bad4fa2f66862b966e351562d77d6d76
The methods can be implemented with ICU4J directly.
Bug: 160606356
Test: atest android.text.format.DateFormatTest
Test: atest CtsTextTestCases:android.text.format.cts.DateFormatTest
Change-Id: I3d5f639a94026c599b487563c95bf9d165adfeec
The new added API for rich content(ag/9884022) denies to autofill
empty text. However, Autofill allows us to fill an empty text. We
should not cause a compatibility issue.
Bug: 159035197
Test: atest android.autofillservice.cts.AutofillValueTest#\
autofillEmptyTextValue
Test: atest FrameworksCoreTests:AutofillValueTest
Change-Id: Ieb5b82bfe4bf77abd151c61ea4cf9125b8fe61f5
When user types some text and then long presses on end of empty area
to open context menu, if user opens Gboard and selects text from the
reverse direction, SelectionEnd will be less than SelectionStart. The
IllegalArgumentException occurred because TextClassification does not
allow SelectionEnd is less than SelectionStart. We swap the start and
end index if end index is less than start index.
Bug: 150916165
Bug: 157452302
Test: Manual. No crash occurs.
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
(cherry picked from commit cb3c97db0c)
Merged-In: I8dbc92f0f31e64b7e3a45ae91762e1b741629a8e
Change-Id: Ie0e2b5840e147f98174cae4521eb777e1a080706
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Merged-In: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
SurfaceView doesn't respect the visibility of its ancestor so we need to
update it accordingly inside InlineContentView.
Test: manually
Bug: 158714351
Change-Id: If482747d6ae5d7628b46de837c11b6232406120c
When an inline content view is reparented its surface is
getting offset and not being under the view itelf. This is
because the surface views manage the postion of their
surface and are assuming a location based off the window's
surface position. However after a reparenting the inline
content view's surface position becomes relative to that
of the new parent surface view. For example, two surface
views at position (10, 10) being reparented would reslut
in the surface of the parent being at (10, 10) while the
surface of the child being at (20, 20) while both views
would still be at (10, 10).
To address this we are intecepting when an inline content
view's surface is reparented and get a weak reference to
the view that owns the new parent surface. We then position
the inline content view's surface relative to the view that
owns the new parent surface, i.e. we position the surface
such that its location would not change because of the
fact it is being reparented.
While at this make sure the inline content view is marked
as not important for a11y to ernsure the a11y plugins don't
try to click on the view tree in the app's process but
insted on the views in the remote proccess, i.e. on the
embedded view tree.
bug:153826463
Test: atest android.widget.cts.inline.InlineContentViewTest#testReparenting
Change-Id: I2cff4b88d404a740bc447668e948eabccad084d2
This restores the logic removed from SelectionModifierCursorController
in ag/9994946. A quick sequence of "tap", "drag", "tap" events (such
as when quickly scrolling a small input field) should *not* be treated
as a double-tap.
Bug: 158948887
Test: Manual and unit tests
atest FrameworksCoreTests:EditorTouchStateTest
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: I9fb9cb06b1e208946566a0f70697c62ee7684ca0
Support clipping for InlineContentView's backing surface
to enable suggestions clipping that does not require re-
parenting which has side effects.
bug:153826463
Test: atest android.widget.cts.inline.InlineContentViewTest#testReparenting
Change-Id: Ia2988ebd660323bf65f0141b4b542a9c4320e178
