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
On some devices it's very likely that we fall into GL comp during
app transitions. However, SF offsets are chosen in a way such that
the time to finish a frame is just too tight to be completely jank
free when hitting GL composition in SurfaceFlinger. Thus, we
introduce the concept of a separate early offset, and wakeup
SurfaceFlinger at that time if we think that hitting GL comp is
likely, or we already hit GL comp in the last frame.
Test: Open app, check vsync offsets in systrace
Test: Open many dialogs/apps to fall into GPU comp.
Bug: 75985430
Change-Id: I461fdcd573583f3ea0348c8b23cc9945d33f8976
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
autofill should use relative location to app window as PopupWindow
is based on relative location.
The fixed reverted changes made in compatibility mode CL that made
autofill window TYPE_SYSTEM_DIALOG.
Changing PopupWindow to use absolute screen location is another fix
choice, but it does not allow autofill window to be automatically
moved when app window changes location (e.g. adjust split window
separator or bring up IME)
The autofill window switches to TYPE_APPLICATION_ABOVE_SUB_PANEL with
IME disabled. So it still appears above IME and most other app
windows, unless app window is TYPE_APPLICATION_ABOVE_SUB_PANEL too.
Fixes: 73555917
Bug: 77587135
Test: manually tested compability mode with chrome amazon login
manually tested splitted window
atest CtsAutoFillServiceTestCases
Change-Id: I6b8ecf3fe7a91cebea1f7a868f4b15fbed8b0051
- Brings by old deleted APIs and hides them
- Except parceling and hidden APIs that won't have been called anyway
- Option holds a reference to the Request object so we don't have to
rebuild it
Bug: 77523413
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: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextSelectionTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextLinksTest
Change-Id: I4277c48a950c3334439649373885ed7fe54f898e
Simply put there is nothing ensuring PopupWindow's stop using
the Surface before the app is stopped. Since PopupWindow's are
detached from the main View Hierarchy teardown of the main window
provides no such guarantee. It seems enough to forward the "WindowStopped"
signal from ViewRoot to other ViewRoot's using the token of that ViewRoot.
Bug: 62536731
Test: Manual
Change-Id: Ib431f49be7e06a6397a40c11ec7e842a8bc5caf9
* changes:
Reparent recents animation task leash to app animation layer
Allow recents animation to override divider minimized state
Prevent unnecessary reordering of the home stack
