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
There are not a small number of files that import InputMethodUtils
just to use InputMethodUtils#isSystemIme() is necessary.
In order to make InputMethodUtils purely an internal utility library,
it would make much more sense if the logic is implemented as a private
API of InputMethodInfo, like methods like
InputMethodInfo#isAuxiliaryIme(), rather than in a static method of
InputMethodUtils.
This is a purely mechanical refactoring. There should be no behavior
change.
Bug: 77730201
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest
Change-Id: I9c8518988787b748ebb35fc86fe6beee1d6c633d
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
The root cause of both attached bugs was the tree-merging algorithm in
ViewRootImpl.SendWindowContentChangedAccessibilityEvent converging on a
common predecessor that is marked not View#isImportantForAccessibility.
As a result, such unlucky content changed events were discarded.
Fixes: 72378611, 72950579
Test: ensure attached bugs are fixed
Change-Id: I3c3c66151b6cd4773de4eadd417709e9a61a7cf2
(cherry picked from commit 3fb3c59040)
willNotCacheDrawing as intermediate caching layers are obsolete since
hardware accelerated rendering was introduced in API 11
ImageView's current implementation of setScaleType would manually
disable it's cache if the ScaleType provided was CENTER. This was end up
not drawing the ImageView if View.LAYER_TYPE_SOFTWARE was configured on
the ImageView as the cache no longer existed. Removed the logic to
conditionally disable the drawing cache and marked
setWillNotCacheDrawing/willNotCacheDrawing as hardware accelerated
rendering makes these facilities obsolete
Fixes: 77653694
Fixes: 72139649
Test: Created a test application with an ImageView and manually set a
ScaleType of CENTER and forced the ImageView to render in a software
layer to confirm that it would render properly with a drawable of the
test application's launcher icon
Change-Id: Ie73b1e0708a265e3cc2cc74ed13539f4219dbd7d
(cherry picked from commit 2ac86880d6)
The root of this bug was in the fact that Selection.removeSelection
removes two spans, the start index and end index of the selection.
Each span removal triggers Editor#onSpanRemoved, which in turn tries
to set a selection. This meant that if we started with selection
(100, 120), then removeSpan(start) was called, so we had (-1, 120),
then the onSpanRemoved code tried to set a selection so set it to
(120, 120), then removeSpan(end) was called, ending up in (120, -1).
There are two stages to this fix
1. A lot of our code assumes that when either start or end selection
are larger than -1, both are valid. Therefore when we have one of them
out of sync, we crash. Fixed this assumption in all the places I found
2. We didn't have a mechanism to use FLAG_INTERMEDIATE when removing
spans, only when adding them, so this CL adds a remove with flags. This
allows us to not trigger onSpanRemoved when only one of the selection
indexes is removed.
Because this is an added method to an interface, the default just
calls the existing method. The new method is implemented in
SpannableStringInternal and SpannableStringBuilder to read
FLAG_INTERMEDIATE and avoid sending a spans changed event.
Selection.removeSelection then uses FLAG_INTERMEDIATE when removing
the first of the two selection spans.
Note that 2. would be enough to fix the current bug, but we want to
avoid other implementations of Spannable from crashing in the wild.
In general, it seems like a good idea to verify both selection indexes
are valid whenever they are used.
Bug: 72101848
Test: atest FrameworksCoreTests:SpannableStringBuilderTest
Test: atest FrameworksCoreTests:SpannableStringTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Test: atest android.text.cts.SelectionTest (note new test as well)
Test: atest android.view.inputmethod.cts.BaseInputConnectionTest
Test: atest android.text.DynamicLayoutTest
Change-Id: I0d647fad152d0bef0f2115a46c3d17ebd8642281
New hidden constants added to HapticFeedbackConstants.
Test: m update-api shows no changes
Bug: 74882420
Merged-in: I164a944b23e958e89b8d3064cb512cee739b27fd
Change-Id: I164a944b23e958e89b8d3064cb512cee739b27fd
