* changes:
Revert "Rotate IMEs (subtypes) by Meta+Space."
Revert "Show toast when subtype is rotated by Meta-Space."
Revert "Shift+Meta+Space should reverse-rotate subtypes."
Revert "Shift+Meta+Space should reverse-rotate subtypes part 2."
Revert "Make sure that Toast is always shown by Meta-Space."
This reverts commit ae61f7118a [1].
Reason for revert: to deprecate Meta-Space short cut.
[1]: I4005692215edfcf8bed3e86b1e07000148f986f5
Bug: 79150878
Test: Manually tested as follows.
1. make -j SoftKeyboard
2. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
3. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
4. Connect a hardware keyboard
5. adb shell settings get secure default_input_method
6. Hit Meta+Space on the hardware keyboard.
7. adb shell settings get secure default_input_method
8. Make sure that the results of step 5 and step 7 are the same.
Change-Id: I5ed0feb5a6d7171564d358644b04ee2a43e4d6b3
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
Currently, it is not possible to use KeyEvent.actionToString(..) in a
CTS test because that API is @hide. However, it would be useful to print
these actions when tests fail. Therefore, add the @TestApi annotation.
Bug: 77803694 36069459
Test: m cts-input-lib CtsHardwareTestCases (under development)
Change-Id: I2d23dbd101cef3f1c6c7a70c521a9dc219797615
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
Bug: 77998709
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: Ibb95a736248643949a7b521368374084f9f133ca
Works around a source of jank when drag resizing in split
screen mode: instead of immediately resizing the (potentially
numerous) invisible secondary stacks, we defer that until
the user lets go of the handle.
Change-Id: I3b9faa83005fa86185d4e51b2849e3a826b7f6a9
Fixes: 78214347
Test: Open a gazillion (resizeable) tasks. Enter split screen. Drag handle, verify there is no jank
Test: atest RectTest
