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
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
Imagine we have a ViewRoot for a PopupWindow so it's view visibility
will not directly be affected by the stopped state, but we still
will end up destroying the surface. We could see a handler queue like this:
("handleStopped", "performTraversals"). If there were no size changes
we won't call relayout and we won't notice we have lost the Surface
and it seems there is nothing to prevent us from continuing in to draw.
However, if we have handled STOP then the surface is now destroyed. Ensure
we respect the stop signal and the released state it sets on the Surface. The
original intent of this code-path should be preserved in the case that
the client receives a new surface from relayout even if it hasn't yet received
setWindowStopped(false).
Bug: 62536731
Test: Manual
Change-Id: I0eccd4dbfd00f9f61ad37086299f986463082a1f
As per the referenced bug, we're running into issues where apps are
being fired with stale intents. The reason is because we need intents we
fire to be unique by Intent.filterEquals. Some of the intents we
generate put unique data in the intent extra which is not considered by
filterEquals. The solution here is to create PendingIntents with unique
request codes (using classifiedText.hashCode()).
See more info about this in
https://developer.android.com/reference/android/app/PendingIntent.html
Bug: 77930684
Test: manually tested broken scenarios. See referenced bug
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Ib7275f94ca5ada51e4ba191742d4b614df12e1ea
Suppresses app transitions when an activity finishes due to crashing.
Fixes: 70640329
Test: "Dev Tools" > Bad Behavior > Crash main thread, verify there's no transition.
Change-Id: I51c4b98b793794b013c266a1dee3fb2e7faf4bd7
Otherwise, we may attempt to reinitialize the ThreadedRenderer with
a Surface which is not actually valid, e.g. from handleWindowFocusChanged.
Entering a code path where the threaded renderer does not heed the
stopped signal. This change ensures isValid returns false when the Surface
is not valid preventing us from calling initialize/initializeIfNeeded, or
udpateSurface. Unlike a previous iteration of this CL, we take care to do so
after invoking the WindowStopped callbacks so that SurfaceView has
a chance to tear down.
Test: go/wm-smoke. More extensive manual testing.
Bug: 62536731
Change-Id: If5e51f8aef7957ad87a23015fe100095f9502bc9
Change-Id: Ibe16ffd792040e753d54d7085ba74e8880de111e
Fixes: 77961334
Test: Set density to Very large, enable simulated cutout, verify it still looks reasonable.
Otherwise, we may attempt to reinitialize the ThreadedRenderer with
a Surface which is not actually valid, e.g. from handleWindowFocusChanged.
Entering a code path where the threaded renderer does not heed the
stopped signal. This change ensures isValid returns false when the Surface
is not valid preventing us from calling initialize/initializeIfNeeded, or
udpateSurface.
Bug: 62536731
Test: For the monkeys.
Change-Id: I65939a29db4db70c6eb6bc4b258a9ed09a86e0ce
To do so, we cannot use the Region from DisplayCutout, because it is conceptionally
a binary Bitmap. Instead, we need the exact curve as a Path.
Also fixes a theoretical bug where the DisplayCutout
was cached even though the display height changed.
Change-Id: I9356f4589186fedc5dc95010c7bd1a1fa20edf5e
Fixes: 77868940
Test: Enable display cutout in developer options, verify the edges look smoth and not jagged.
Test: atest DisplayCutoutTest
When entering split screen, the secondary window changes position so
it's below the primary split screen when minimized. The WSA at the same
time is also changing size to fit the area. However, the size doesn't
change until the client requests a new size and a frame with the correct
size comes in. This causes the stack to update position before the
resize which causes content to get cut off and then a jump when the resize
completes.
This change updates the WSA position as soon as it recognizes that the
stack changed position due to entering split screen secondary. The WSA
sets its position as the negative of the stack position, making the
calculated window position at (0,0). When a relayout is requested, the
WSA's position is requested back to (0,0), deferring until the new frame.
This will put the WSA position at (0,0) when a frame with the correct size
is drawn. This places the window position at the stack's new position in
the same transaction that a WSA frame with the new size is drawn.
Change-Id: I8c88d7784f827d66926fb5c382af2346028dc48f
Fixes: 74354855
Test: Entering split screen with quick step is smooth
Test: Entering split screen with old launcher still works
I put it on TextView to try to scope it as narrowly
as possible, but an ImageView could be a heading, as
could a LinearLayout that holds a TextView (like a
preference).
Bug: 77726494
Test: atest CtsAccessibilityServiceTestCases
Change-Id: I9313ce6de25b5893db450f23499b151a4f08afda
Migrate DefaultLogger implementation to SelectionSessionLogger.
This cleans up after the API refactor and fixes two bugs:
- All events are currently logged twice.
- Interfaces accept a null signature, but it currently crashes the legacy logger.
Bug: 73392698
Bug: 77659305
Test: atest FrameworksCoreTests:TextClassificationManagerTest
Test: atest FrameworksCoreTests:TextClassificationTest
Test: atest CtsViewTestCases:TextClassificationManagerTest
Test: atest CtsViewTestCases:TextClassifierValueObjectsTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Test: Manually examined logs
Change-Id: I0d2b925abf5cab12d71fc2cc0fa527530c86ab10
This bug means we never received logs for events like 'Web Search'
Bug: 77659305
Test: atest FrameworksCoreTests:SelectionEventTest
Change-Id: I6f79897f548d0d19710578e309e0b645bb78e1e3
