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
We should set the state description whenever textOn and textOff are
updated. Setting it multiple times doesn't hurt because the
setStateDescription method won't do anything if the state description is
the same.
Test: tested with talkback test app. Without the change, a toggle button
with textOn and textOff set won't have them announced as the state
before a click happens. After the change, a toggle button with textOn
and textOff set has them announced as state.
Change-Id: Ia1cc6218c8cd0125c123c9b650bb4963825db23a
Introduce new APIs in Window/WindowManager.LayoutParams for developers
to decide which types of insets at which side a window should avoid:
setFitWindowInsetsTypes(@InsetsType int types)
setFitWindowInsetsSides(@InsetsSide int sides)
setFitIgnoreVisibility(boolean ignore)
The existing logic in DisplayPolicy.layoutWindowLw uses combinations of
window types, window flags, and system UI flags to decide what frames a
window should have, which is very complex, difficult to maintain, and
should be replaced with the new APIs.
Bug: 118118435
Test: atest InsetsSourceProviderTest InsetsStateControllerTest
InsetsPolicyTest WindowStateTests CommandQueueTest
RegisterStatusBarResultTest InsetsFlagsTest
LightBarControllerTest RegisterStatusBarResultTest
ViewRootImplTest DisplayPolicyLayoutTests
DisplayPolicyInsetsTests DisplayPolicyTests
TaskSnapshotSurfaceTest
Change-Id: I06ddc9d0d2887ba4ded7bb8adbf9c9c0da4bf7b4
RadioButton
Allow RadioGroups to be recognized as groups of
objects by accessibility services. This lays a foundation to better
describe these groups by exposing the number of buttons and the position of
each.
Bug: 144591511
Test: Tested on various app permission fragments in Settings and in the
time picker in Clock. Added cts tests.
Change-Id: Ie0c41d8c9b131ca29bba5387171a85dfdbb8db7e
The caller can hold on the Cancellation signal even after the task
completes which stores a reference of the original RemoteViews and
all the resources associated with it.
Bug: 145829442
Test: Verified Appwidget functionality
Change-Id: I6998980b5bf64dd59fa1b53240440b29df0fb866
The goal of these changes is to consolidate the state that needs to be
tracked for user motion events (touches, clicks, etc), in order to make
it easier to add/update functionality in the future.
These changes are intended to fully preserve existing behavior from the
user perspective. For the most part, the logic is completely unchanged
(just that the code is pulled out), but it's worth calling out the
following subtle changes to the logic. These changes don't affect any
user-visible behavior.
1) In Editor.onTouchEvent, the recorded position of the last down event
is now updated before SelectionModifierCursorController.onTouchEvent()
is invoked.
2) In Editor.updateTapState (now in EditorTouchState.update), instead
of using SystemClock.uptimeMillis() for the event time, we use
event.getEventTime().
Bug: 143852764
Test: Manual testing and unit test
atest FrameworksCoreTests:EditorTouchStateTest
Change-Id: Ic40b5e53412294d365bc9d787e7013a44fe11ffa
Previous CL (ag/9699132) broke CTS ToastTest and was reverted (ag/9754500).
This was because the test was posting a background toast and verifying it
wasn't clickable. Test has been updated to use a foreground toast in ag/9754274
and I will also look into having it be executed in presubmit.(b/144810971).
-- Previous CL description (updated "Test:" lines)
To assess app compatibility problems early on, this CL blocks background
custom toasts in a non-secure way. We create a new method in the AIDL called
enqueueTextToast() that now contain the same parameters as
enqueueToast(), receiving the view created inside the app's process. But this
method will, in the future, contain a CharSequence instead of
ITransientNotification, for window creation inside the system.
We use PlatformCompat infrastructure to check if the change is enabled.
I learned with this change that if user blocks notifications for an app, it
won't be able to show background toasts, allowing me to re-use the foreground
check that was already in place.
This change will display a text toast (from the system) in case the app's
custom toast gets blocked, this is temporary to get feedback from
dogfood.
Test: With sample app, verify that:
1. Posting text toast in bg works
2. Posting custom toast in fg works
3. Posting custom toast in bg does NOT work
Test: atest CtsToastTestCases CtsWindowManagerDeviceTestCases:ToastTest
CtsWidgetTestCases:ToastTest CtsToastLegacyTestCases
Test: Working on CTS
Bug: 128611929
Change-Id: I25c6339c6adeb907878596332f57e2fa229bfda9
