Original logic applies a 4x6 mesh for the fisheye effect.
Due to the mesh width is an integer, the ramp width cannot be adjusted,
instead, it is calculated based on the zoom and mesh width.
e.g. zoom = 1.5, mesh width = 4, the ramp width must be 0.125x of width.
That causes the inflexibility of adjusting the ramp width for potential
UX experiments.
This cl breaks the original pixel copied bitmap into 3 parts.
- For the middle part, it just be drew scaled to the middle of magnifier.
- For the left/right parts, it applies a 1x6 mesh to mimic the fisheye.
Because the mesh only applies the left/right parts, the ramp width can
be configured separately.
Test: m -j & manually tested.
Bug: 148763951
Change-Id: I7afe7e4b8d006b2b3a46513eadfea9fa8bf0515f
In order to do that, NotificationManager now calls
StatusBar.showToast(), which is in SystemUI. StatusBar then calls a new
component, ToastUI, which is responsible for rendering the toast. The
code for rendering the toast was extracted from the Toast class, so it
should behave identically.
Also refactored the code a bit on NotificationManagerService, creating
two children of ToastRecord (one for custom, other for text toasts).
The change is gated in Toast class in this CL, but it's also gated on
the system server, so apps can't circumvent the background block.
Bug: 128611929
Bug: 144754526
Test: atest android.widget.cts.ToastTest
Merged-In: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460
Change-Id: Id0021cdc6f72f41b55ff1c5a4f09ae7687586460
Bug: 129694386
Test: No change in behavior, no new tests
EdgeType is only used as a parameter to quickReject, but it is always
ignored. Deprecate it and the existing quickReject methods. Add new
versions of quickReject without EdgeType parameters. Switch clients to
the new versions.
Change-Id: Id932f10915a8c4959fe0e85f507ce7fd2da8a576
Previously when IMEs want to get initial input text for advanced
prediction featues, it will take up to three IPC calls. Once we provide
the initial text in the EditorInfo object, it would be available right
after the input connection setup and no IPC overheads will be
introduced.
Bug: 122691437
Test: atest FrameworksCoreTests:TextViewTest
Test: atest FrameworksCoreTests:EditorInfoTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsInputMethodTestCases:EditorInfoTest
Change-Id: Ie04f2349b1157408aa8ed9044aea12ce99132cb4
onProgressRefresh() is only called when the progress changes. So we should set
stateDescription during initialization.
Test: tested with talkback test app. Without this change, the
stateDescription is not available when we focus on the seekbar. After
the change, the stateDescription is avaiable.
Change-Id: I56071ed28e6917c6bd14162884b10440c6955751
- The delta height & opacity for the insertion handle.
- The zoom factor & aspect ratio for the new magnifier.
Test: m -j & manual tested.
Bug: 145558249, 145550493, 145545591, 145555868
Change-Id: Ie69bd606ff738b19f3af166e7beeac2c32c705ba
- Uses drawBitmapMesh to mimic the fisheye effect.
- Avoids any logic changes to the old style magnifier.
- The new magnifier is not exposed to public.
- Creates the magnifier instance lazily.
- Minor code cleanups suggested by IDE.
Bug: 145555868
Test: manually tested.
Change-Id: I6f6f6b353e2ce53bdc97fb36dd25cafa14d3d779
Deprecating custom toasts as discussed, the reasons are:
* We're blocking background custom toasts for security reasons
(go/toast-abuse).
* This means custom toasts are only possible if the app is in the
foreground. In the foreground the app has control over its own view
hierarchy and is capable of creating any visual elements it would
otherwise use custom toasts for.
* If we were to declare ongoing support for foreground toasts the
developer would be in a situation where they either check for
foreground status of the app before posting a custom toast or they
accept that the information they want to display may not be shown at
all. This is not great.
* There is also a desire to avoid custom toasts altogether since they
hurt UX consistency
(https://docs.google.com/presentation/d/1r5WEofZ_G3B9M65nS37uD4RqA4iV9HUmngyE6ZpBSsw/edit#slide=id.g7b69852da2_0_0).
Also added a recommendation to use Snackbars while the app is in the
foreground.
Bug: 128611929
Bug: 144754526
Test: Builds
Test: atest android.widget.cts.ToastTest
Change-Id: I4ed0bd671e308491590c28ff24087c76d0623f13
In preparation for text toasts, which won't contain a
ITransientNotification object associated with them, indexing toasts
by an IBinder token provided by the app.
Bug: 144754526
Bug: 128611929
Test: atest android.widget.cts.ToastTest
Change-Id: I8ec649066154f59bc28bcb49bb6f156eadb796d8
So that the logic of double-tap & long-press to select words can be shared to InsertionHandleView.
Note:
- This requires to work with the cursor dragging feature, otherwise the InsertionHandleView cannot move.
- InsertionHandleView needs to handle touch up events to toggle the insertion menu as expected.
- The event coordinates need to be modified in order to make the touches on handle equivalent to touches on text at cursor.
Bug: 145547052,145535934
Test: m -j & manual test & automated tests
atest frameworksCoreTests:EditorCursorDragTest
atest FrameworksCoreTests:TextViewActivityTest
Change-Id: Ic025700eb06addd67a2abcfff97eaf0e8a196718
Providing a new A11yNode action for ime actions:
ACTION_IME_ENTER
1. TextView will expose this action and store the ime action id
if it is editable and has focus.
2. This A11y action which would have default text “Enter” if the
developer didn’t set a custom ime action label, otherwise the label
would be what the developer provided.
3. This A11y action which would have default id,
IME_ACTION_UNSPECIFIED if the developer didn't set a custom ime
action id, otherwise the id would be what the developer provided.
4. TextView will perform this action by calling its onEditorAction
with stored ime action when populating this node.
Bug: 139380257
Test: a11y CTS tests & unit tests
Change-Id: Ifba432f8fda732f8335c40fe27f5e74499621d47
Cursor drag without the handle is only for touch and should not trigger
for events from a mouse. This was already the case before this CL but it
was not explicit: SelectionModifierCursorController happened to trigger
first so the cursor drag would not get activated. This change updates
the cursor drag logic so that mouse events are explicitly excluded from
the feature.
Bug: 145535274
Bug: 143852764
Test: Manual and automated tests
atest FrameworksCoreTests:EditorCursorDragTest
atest FrameworksCoreTests:TextViewActivityMouseTest
Change-Id: I3ccf5106b8e9a9e3c271dff38a4d6a0c0aa19597
Calls to SelectionModifierCursorController must be guarded by
hasSelectionController() because it's possible to have a TextView
with an Editor but no selection controller if the TextView is
configured to have non-selectable text.
Bug: 147366705
Bug: 145535274
Bug: 143852764
Test: Manual and unit test
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: I7fdec754e6fa51561b08fab024ea672c43f2c8f5
When testDragAndDrop_longClick() performs the long-press, the events
triggered are ACTION_DOWN, ACTION_CANCEL, ACTION_DOWN, ACTION_CANCEL.
It's not clear why there is the additional ACTION_DOWN / ACTION_CANCEL
pair; performing the same gesture manually only produces a single
ACTION_DOWN / ACTION_CANCEL pair. Still, Editor should be able to handle
this scenario since ACTION_CANCEL is a valid event.
Previously there was no handling for ACTION_CANCEL in EditorTouchState
at all, so the sequence of events triggered by the test would end up
getting treated as a double-tap scenario and drag-and-drop would not be
started.
This CL adds handling for ACTION_CANCEL in EditorTouchState, attempting
to follow GestureDetector as closely as possible (essentially resetting
state whenever ACTION_CANCEL is received, so that subsequent events
start a "fresh sequence").
Bug: 29591177
Test: Manual and ran tests
atest FrameworksCoreTests:TextViewActivityMouseTest
atest FrameworksCoreTests:TextViewActivityTest
atest FrameworksCoreTests:EditorTouchStateTest
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: Ia0ee531af64083a4f670842188bdc7e35b617397
In preparation for moving text toasts to system UI, we need a new way of
telling if a toast is being displayed or not since the view won't live
in the app's process. This is needed for our CTS tests and good to have
for developers so we don't take the functionality away from them, so
making it a public API.
Also updated tests in topic CL.
Bug: 128611929
Bug: 144754526
Test: atest android.widget.cts.ToastTest
Change-Id: I41ff1ed11d5af66e415c772c2e5f611a3d1b17fc
This change removes some code from SelectionModifierCursorController
in favor of calling EditorTouchState instead.
Bug: 143852764
Test: Manual and unit tests
atest FrameworksCoreTests:EditorTouchStateTest
atest FrameworksCoreTests:EditorCursorDragTest
atest FrameworksCoreTests:TextViewActivityTest
atest FrameworksCoreTests:SuggestionsPopupWindowTest
Change-Id: I40f0ad8bd4eb0d4af33d0e2cd1a79c99812a9c40
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I41e12e425284e74561c6b61663241df364ae54a1
Once a selection drag starts, the cursor drag logic should be
skipped (short-circuited) until the selection drag ends.
Bug: 143852764, 146811252
Test: Manual and unit tests
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: I8da82d5c197d8dcaa8d407ae11fac9a5b8521949
When the EditText component is wrapped in a ScrollView or another
scrollable component, vertical scrolling works without any explicit
logic to suppress the cursor drag. But if the EditText component is
not placed in a scrolling container, swiping vertically will trigger a
cursor drag instead of scrolling unless we add some explicit logic to
suppress the drag for vertical swiping.
The change here implements explicit logic to disambiguate dragging the
cursor vs scrolling. This is done using the following heuristic: the
swipe direction angle must be greater than 30 degrees from vertical in
order to trigger the cursor drag. Otherwise the existing handlers will
pick up the gesture (e.g. scrolling).
Bug: 143852764, 145833335
Test: Manual and unit tests
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: Ibc5b2317e06cc36b221609c716c858ad0a70d577
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I5be7335b23a92b8ac80d2fd890198273b66ad644
