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
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
This is partial merge of aosp/Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09. Telephony greylist cleanup has been done separately. Note that annotations outside of frameworks/base/ have been merged from AOSP.
Bug: 137350495
Test: m
Exempt-From-Owner-Approval: merge
Change-Id: I015c466e8b69cc0fed5e9d394ba865aad11d8ba6
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 targeting SDK 29, 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: With sample app targeting SDK 28, verify that 1, 2 and 3 above work.
Test: Working on CTS
Bug: 128611929
Change-Id: Icecbbeff081fa5e7c4329bf3b383d6859520b517
When the progress changes, instead of sending TYPE_VIEW_SELECTED event,
CONTENT_CHANGE_TYPE_STATE_DESCRIPTION event sent. Developers can
override onInitializeAccessibilityNodeInfo() and call
info.setStateDescription() to provide customized state description.
Bug: 123346875
Test: The default implementation of StateDescriptionFormatter maintains
the current format talkback uses. Also tested on talkback_test to set
customized state description based on progress.
Note: this change should not be merged until CL/275509401 (google3) is merged.
Change-Id: I8f1a0c91c55a498593c360483827ed050656d943
This will get rid of the RemoteViews leak caused by ViewStub keeping
reference of LayoutInflater. But subclasses of RemoteViews won't be
affected to avoid breaking overriden usage.
Bug: 141699084
Test: Manually test. Leak disappeared. atest RemoteViewsTest
Change-Id: I1b287a166df92e424208ae35eb84bfd6aa553ddf
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
