Since InputConnection#deleteSurroundingText the design is to delete the
text before the selection start and after the selection end range,
it would be possible that the exception may happened when the obsolete
selection range which is not aligned with the current text content.
Add a check to make sure the text will be deleted when the number of
text before / selection the selection is > 0.
Also, skip the delection when the selection is not yet attached
Bug: 130979263
Test: atest BaseInputConnectionTest
Change-Id: I93b69b71531bcab4ae204c1c1287b8fbe0224ea8
Any pending windowGainedFocus future should be cancelled when IME is
switched/unbound.
Additinally, startInputInner() inside synchronized block blocked
WINDOW_FOCUS_GAIN from executing. Its fine to remove synchronization
here since startInputInner() already has relevant synchronized blocks.
Change-Id: I98cb044d8cbfb80480312a3923f168aefa9b7e7d
Fix: 144103599
Bug: 139806621
Test: Manually using the steps in bug.
Bug: 123338864
Bug: 135150273
Test: run app-launch-perf test (go/platform-startup)
Test: launch apps manually and measure the execution time of
snapshotTask(), writeBuffer(), and loadTask()
Change-Id: I9841c6dad99b1f4d4ba0044b7fe06fe021c295a0
Also remove WindowManagerStressTest because that has been replaced
with proper perf test.
Test: Boots
Bug: 143255833
Change-Id: I1d293cda7c82d0aa1c3a6cc694c74bf7d10cc974
This adds support for registering a single DisplayRotationController
to WMS. It gives a chance for the controller to suggest some
task changes to be executed along with a display rotation. There
is only one because it's a 2-way communication and there is only
intended to be one client for now.
This allows us to move Split and PiP presentation/layout logic out
of WM into systemui because WM no-longer needs to be the one
calculating the new bounds of everything during rotation.
This uses the windowcontainer transaction because all the
configuration changes and the display rotation need to happen
synchronously; otherwise, relayouts can occur after the display
is rotated, but before the configuration changes are applied.
When this happens, apps get incorrect bounds/insets which can
trigger erroneous lifecycle events in the app.
The flow is like this:
1. DisplayContent/Rotation freezes screen
2. DisplayRotationController is notified of a rotation and provided a
callback.
3. The Controller then evaluates/queues some task changes in
a transaction and, when done, fires the provided callback.
4. The callback applies the config change transaction and continues
the rest of the rotation synchronously.
The DisplayWindowController is sys-ui piece that serves as an
interface between system-ui components and display-related wm
logic. For now it just facilitates the rotation calculation, but
in the future it will have more general utility for display logic
like inset/bounds calculation.
Bug: 124011688
Bug: 133381284
Test: Added some wmtests and coretests.
Change-Id: If10695f44fa076725ba17746842f6fbd64da5d20
Any window that sets FLAG_NOT_FOCUSABLE should not be considered IME target.
IME subsystem starts input on a window when it receives focus, if window never
intended to receive focus, it should not considered an IME target either.
Also, fix the broken javadoc for ALT_FOCUSABLE_IM.
Fix: 143898978
Bug: 140641950
Test: atest WindowStateTests
atest FocusHandlingTest
atest WindowManager_LayoutParamsTest
Also manually using steps:
1. Launch gmail compose activity
2. start typing in receipient field
3. verify that suggestions popup window w/ FLAG_NOT_FOCUSABLE doesn't
become IME target.
Change-Id: Ifa8e7345c2c9ad3730df86100003918b12fb533e
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
Merged-In: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
ANR - If embedded windows are slow in handling inputs the system should blame the embedded app.
PointerDownOutsideFocus - if a user taps outside the currently focused window onto an
embedded window, treat it as if the host window was tapped.
Rename blessInputSurface -> grantInputChannel and add a name to embedded windows.
Bug: 134365580
Test: b WindowlessWmTest
Test: atest CtsWindowManagerDeviceTestCases:WindowlessWmTests
Change-Id: If88970cf6ce17669b41fec995535151a492fab12
This patch will update the task description when the app calls
setStatusBarColor or setNavigationBarColor. The status bar is updated
but the information is not reflected in the task description without
this patch.
Bug: 132756841
Bug: 113253712
Test: Test with the test app in b/132756841. The task description is
updated as expected.
Test: go/wm-smoke
Change-Id: I4ba1e5e7dd0f096cba40221450a8861e3d578e3c