In Q, the slop is a fixed value calculated based on
TextView.getLineHeight().
In R (before this cl), the slop is a dynamic value based on the height
of the current line.
It's been confirmed as the root cause of the regression bug b/159528374.
This cl changes the slop value back to the fixed value.
Bug: 159528374
Test: Verified locally.
Change-Id: I182d22779f1c1155ae2e0b0deb0455bd270b2fd9
Merged-In: I182d22779f1c1155ae2e0b0deb0455bd270b2fd9
They can be replaced by the public API provided by ICU4J instead.
No extra layer of caching equivalent to the LocaleData cache is
added because ICU4J has caches instances, e.g. DateFormatSymbols,
etc.
Bug: 160606356
Test: atest FrameworksCoreTests:android.text.format
Change-Id: I07048e0e1a4835d2744b7fce6a5ed79a112e456b
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
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
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
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
- In Android Auto, android.widget.cts.ToastTest#testShow_whenTextToast_sendsAccessibilityEvent failed is failed, since AccessibilityManager in ToastPresenter is initialized with the wrong userId.
- ToastUI creates the Context from the uid of the received message, so we can get the correct userId from the Context.
Bug: 154644563
Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest
android.server.wm.ToastWindowTest ToastUITest
NotificationManagerServiceTest LegacyToastTest
Change-Id: I138620a0a52e65429157719f588c4be56b075368
