Removed this constant variable, TextView.ACCESSIBILITY_ACTION_IME_ENTER,
and added more description for new accessibility action,
ACTION_IME_ENTER.
Bug: 139380257
Test: a11y CTS tests & unit tests
Change-Id: I929262aa0046640aafe36a2dc2a8896ee7cab9ff
Some methods should not be called on text toasts rendered by the system
UI, adding logging and updating docs. Check go/toast-block-design for
details.
Bug: 128611929
Bug: 144754526
Test: Builds
Test: atest android.widget.cts29.ToastTest android.widget.cts.ToastTest
Change-Id: I282288afd0be604b2fdaa1348f09fc59e8f33d98
We've decided to gate the text toast move on targetSdk due to an app
crash (b/148438364) but decided not to gate the background custom toast
block (in NMS) on targetSdk temporarily to gather dogfood and DP
feedback. This meant that app-rendered text toasts (which are only
possible for apps with targetSdk < 30) were being blocked in NMS since
they were being considered custom toasts.
This brings back the boolean inside Toast class that differentiates
between custom and text toasts for apps with targetSdk < 30, since both
are app-rendered in this case. This code won't be present on final
version and is temporary to gather feedback on dogfood and DP, since
almost no app currently targets SDK 30+. We'll gate both changes (the
system UI move and the bg custom toast block) on targetSdk later on.
Bug: 148761979
Bug: 148794147
Bug: 144754526
Test: Verify that, while on the background:
App with | Custom toast | Text toast
targetSdk < 30 | Blocked | Allowed
targetSdk 30+ | Blocked | Allowed
Test: atest android.widget.cts.ToastTest android.widget.cts29.ToastTest
LegacyToastTest
Change-Id: Id529028bc463034cd2f64a6f2f97e71bc6ea7c36
For some reason I had added @deprecated inside javadocs but forgot to
add @Deprecated to the method on ag/10117117. Repo-hooks only
warned me now that touched that method for something unrelated.
Curiously even api/current.txt in that CL has the method marked as
@Deprecated.
Bug: 128611929
Bug: 144754526
Test: Builds
Change-Id: I8e4a58ae5ba2204aaced6d7a83746b17573a8c97
And excludes the line spacing when calculating the manifier Y
coordinate.
Test: m -j & manually tested.
Bug: 148737626
Change-Id: Ib592187da4f39e9e30bd3c0e6958e56901910728
We should always send TYPE_VIEW_SCROLLED event when scroll. This applies
to ACTION_SHOW_ON_SCREEN. And we also need the scroll event when the
first visible item and last visibile item don't change.
Fix: 147907655, 147282475
Test: tested b/147282475 is fixed (this bug is not related to
ACTION_SHOW_ON_SCREEN, it is the scroll forward action).
Change-Id: I2069dc3ee692042ff87867db9837e85ac1d8dd26
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
