ActionBarOverlayLayout used to drop WindowInsets, extract the content insets
as a rect, and then dispatch a modified rect to the content view; this because
there was no way to retarget the WindowInsets to the content view, and the
WindowInsets were not truly immutable. That means however, that other kinds of
insets than the content insets do not get dispatched, such as the display cutout.
To fix this, we add APIs to inset WindowInsets, make them immutable. Note that
a similar change is needed for the support lib.
Bug: 79733300
Test: atest ActionBarOverlayLayoutTest
Change-Id: I6a69d8462163ca5e66fdb53f83def6bc4063f8aa
Fixes jank issues where trimMemory gets scheduled during an
animation. trimMemory likely hits code that is not in the
page cache anymore, leading to high execution time because of page
misses. Scheduling it after the next frame has been drawn
minimizes the risk that this page miss actually causes jank.
Test: Boot, switch between a couple of apps.
Bug: 78611607
Change-Id: Ia1fc411fbe6ca07861183ae484124406681118e5
Approach here is to register a content observer that invalidates the
TC settings whenever updates to the settings happen.
This CL also ensures that the TC is invalidated when a settings
update happens. This is because the settings may change what
TC the system returns.
TextView's SelectionActionModeHelper has been updated to not cache
the settings and get them directly from TCM (which caches the settings).
NOTE that we expect TC settings to rarely change.
Bug: 77539576
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - Made changes to TC settings and observed logs / app behaviour
Change-Id: I88bbb6f951708b17323fac1a72385fe808d270a5
Otherwise it could lead to parameters applied in the wrong frame,
leading to jank.
Test: Open notification
Bug: 78611607
Change-Id: Ia7900e753b29187a7a7b81f393666687e8b8e04b
Merged-In: Ia7900e753b29187a7a7b81f393666687e8b8e04b
This way the newest PendingIntent will override any matching ones.
Bug: 78286917
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Change-Id: Ib130fa5979c3dab628e7be668331cb94d23e0829
We use ids to break ties when sorting views just to
guarantee that we won't break sorting. But we don't
want to have our swipe order determined by arbitrary
ids.
Before resorting to such a crude tie-breaker, look at
a view's children to try to break a tie using their
bounds. That sort is more based on what's on the
screen, and will also produce the same result from
the same ui.
Bug: 78348191
Test: Switch access order is much more sensible on
Recents. Also ran a11y cts.
Change-Id: I918eae3b0d27e889a53d05a6ebe925e38ce5d7b4
IME used to allow startInput() *only* when window has focus.
This is no longer the case after we made changes to allow autofill
window to get window focus to receive physical keyevents.
The fix changed precondition of when InputMethodManager can startInput:
(hasWindowFocus() || isAutofillUIShowing()).
Test: manual test:
- install two IMEs
- install autofill sample service and autofill sample service
- launch the Autofill sample app, click on edittext, both
IME and autofill window are showing.
- type "username", autofill datasets are being filtered.
- click "globe" button in IME window to switch IME.
- continue typing "username2" using new IME and autofill window
continues to filtering.
- also try the "IME switch" button in bottom bar to switch IME.
Bug: 79494235
Change-Id: I0d222b5fc13ad46834aa861647d8f2e1649093ec
If we depend on legacyIntent, then TextClassifierService implementations
will have to always popuplate a deprecated field.
To avoid breaking legacy clients, the returned legacyOnClickListener should
represent the first pendingIntent (i.e. primary action) that was parcelled.
Bug: 78340399
Test: atest CtsViewTestCases:TextClassificationManagerTest
Test: atest FrameworksCoreTests:TextClassificationTest
Test: manual check with a TCS that only sets non-deprecated fields vs a
legacy TC client
Change-Id: I41d27a65f1ede6369dd2a66d92b2210edb0d11e2
We were only updating accessibility in View#setAlpha,
but View#setAlphaNoInvalidation would also change alpha,
and accessibility would never find out.
Bug: 78101543
Test: TalkBack now works on nightlight conditional and
battery saver slider.
Change-Id: I1ebb62aa7f4de700b2d7fbaae8dbbd1c84fc4ece
No logs were being sent via the TextClassificationManagerService to
the TextClassifierService.
Also, SelectionEvent.getSessionId() is nullable. Handle appropriately.
Bug: 79418429
Test: manual - manually tested via a debugger. Auto tests coming soon.
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Change-Id: I196885d9b03c0c11cae7686a5835d14791065e78
This field is used on pretty much all Autofill metrics, except
AUTOFILL_USERDATA_UPDATED, AUTOFILL_SERVICE_DISABLED_SELF, and
AUTOFILL_INVALID_PERMISSION.
Test: atest CtsAutoFillServiceTestCases
Test: adb shell logcat -b events | grep sysui
Bug: 79351659
Change-Id: I2e2f3dcc780a3896162b158926f5ee89c7cb342d
The CL fixes the magnifier's behavior when its parent window has
positive insets in its surface:
- we compute the content copy coordinates sent to the pixel copy request
relative to the surface the content is copied from. We were clamping
them inside the visible region of the magnified view as returned by
belonging to the view which is magnified. However, the method returns
coordinates relative to the window. Therefore, the CL offsets the
visible rectangle with the window insets, to account for them.
Otherwise, when the insets were non-zero, on a text line we were
allowing the magnifier to display content from the left outside of the
text line, while a certain region at the end of the text line could have
never been magnified
- when clamping against the visible view region, when the surface we
copy from is a SurfaceView, #getGlobalVisibleRect is still returning
coordinates relative to the main window, whereas the coordinates we are
trying to clamp are relative to the surface of the SurfaceView. In order
to make the visible rectangle relative to the surface of the SurfaceView
instead, this CL negatively offsets the visible rectangle with the
SurfaceView position in the parent surface
- the selection/insertion handles are hidden when they overlap the
magnifier. To check this, we intersect the magnifier rectangle with the
rectangle of each handle. However, when we were performing this check,
the magnifier rectangle was relative to the surface, whereas the
handles' rectangle was relative to the main window. The CL negatively
offsets the magnifier position with the surface insets, to make both
rectangles relative to the window.
Bug: 78621162
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I0d749c1abb38520fe8fc477d22d6523f470e9abc
As this signifies releasing the native resources protected by the guard. See comment
for more indepth discussion.
Bug: 78629612
Test: Manual.
Change-Id: Iee9fe9558b1fee171789580c48f4890c2be1c219
Prior to the implementation of detachChildren we handled this
case via the "mWindowStopped" codepath in SurfaceView.java which this
CL deletes. That codepath however causes confusion due to it's failure
to set null the SurfaceControl, meaning we may not necessarily
recreate it when resuming if we didn't hit any other code-path
to do such as happens in linked bug 78588930. Anyway it seems clearest
to handle all these preserve-child-surfaces-on-tear-down cases via
one mechanism (detachChildren).
Bug: 78588930
Test: Manual.
Change-Id: Iac7c0bc0c6b4da0d405bdc2b57d13d5c881611b0
Problem was RemoteAction(...) takes a non-null PendingIntent but
TextClassification.createPendingIntent(...) returns a nullable PendingIntent.
Bug: 78515224
Test: manual
- Disable Contacts apps in settings
- Select a phone number in a TextView
- Verify that a Phone smart action is displayed
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Change-Id: Icab581d4eef38b4801d1b9ee3af04ffefd1eec6f
1. Define default Themes for autofill window and save dialog.
(http://go/theme_autofill). Phone uses light themes, TV uses
dark themes.
2. Apply autofill theme to RemoteViews passed from autofill service.
So this can make sure the textColor of RemoteViews matches
the background of autofill theme uses.
Updated public javadoc that autofill service should not
hardcode color values.
3. A new TV ux that occupies half screen height (go/autofill-for-tv).
TV autofill now passes unhandled physical keyevent to app window
in the same way phone/tablet does.
4. Fixed ATV autofill window to be SYSTEM_DIALOG, so it wont be
clipped by app activity window (DialogLauncherActivityTest).
Bug: 71720680
Bug: 74072921
Test: CtsAutofillTest
Change-Id: Ib570227b0958b1800e8f0600b8aec36478568d74
Not doing this copy results in us keeping
mOriginalText around. That is a CharSequence that
can contains Spans that reference other Views and
other expensive stuff.
Fixes: 78511639
Fixes: 75602764
Test: make
Change-Id: I977646311167f8d13e1c4a5c8fc38372e6d1ff3c
If a view is suppressing layout, it is probably part of a
transition animation. In this case, we don't want to defocus
a focused view which may eventually have a size.
Bug: 78302781
Test: issue in bug is resolved. Transition CTS tests still pass
Change-Id: I983f41bcd68056d2150d4db29c781b63a2c321c2
Didn't work anymore since the animation refactoring. Doesn't look
like we still need it, and only causing issues with stuck
animations.
Test: go/wm-smoke
Test: Dock task from recents
Change-Id: Ibb3543d15f42fc7689c3ad705aee693eba93e8b7
Fixes: 77993227
