1. Remove the internal using argument, ACTION_ARGUMENT_IME_ACTION_ID_INT.
2. Add more descriptions about this accessibility action, ACTION_IME_ENTER
Bug: 150831470
Test: atest AccessibilityTextActionTest
Change-Id: Icfebdf280e3441bf7b2b6f55c3febbe3a1d98de6
Both showSoftInputUnchecked() and closeCurrenInput() rely on rootView to
obtain window token. If view root is null, window has already gone away
and IME control had been revoked. Trying to show or hide at this time
would be a no-op.
Bug: 149900693
Test: Manually using the steps mentioned in bug and verify that there is
no NPE.
Change-Id: I294bb2ec5395d7502a855bafbac672af069e9b4a
Merged-In: I294bb2ec5395d7502a855bafbac672af069e9b4a
(cherry picked from commit ba9b716a70)
Provide a recording insets controller before the window gets
created, and replay the commands once a view gets attached. This
allows the client to use the controller in Activity.onCreate.
Test: WindowInsetsControllerTests
Bug: 118118435
Change-Id: I1a825ecc4367c02b27f2d08cd5442325315d4f89
* autofill will cache the inline suggestions response until it receives
a start input view event from IME
* the data flow from IMS point of view is:
IMS#startViews and IMS#doStartInput (before calling onStartInputView)
->
[async] InlineSuggestionsRequestCallback#onInputMethodStartInputView()
--- process boundary ---
->
IMMS.InlineSuggestionsRequestCallbackDecorator
#onInputMethodStartInputView()
->
InlineSuggestionSession.InlineSuggestionsRequestCallbackImpl
#onInputMethodStartInputView()
* similar data flow for IMS#finishViews()
* this CL should not block IME's UI thread because it's only issuing a
new async IPC from IMS start/finish input view call that's running on
the UI thread.
* there should not be performance impact on IMEs if autofill inline
integration is not active
Test: manual verification, atest EditorInfoTest
Test: atest android.autofillservice.cts.inline, with two failing cases:
InlineAugmentedLoginActivityTest#testAugmentedAutoFill_twoDatasetThenFilledSecond
and InlineAugmentedLoginActivityTest#testAugmentedAutoFill_oneDatasetThenFilled
due to the test itself being broken, I'll fix the test in a separate patch
Bug: 149522488
Bug: 149442582
Change-Id: I2faa3577b9f95a122f26a6d7fa7822a769a51e34
The InlineContentView uses the SurfacePackage instead of the SurfaceControl
for accessibility and UiAutomation supporting.
Bug: 149194105
Test: manual
Change-Id: Ib10f37a58dde7dc09d0ea16d1a121088dab4738e
By the compatible logic in DisplayPolicy.layoutWidnowLw(), if a regular
window (non-TYPE_STATUS_BAR_PANEL, non-TYPE_TOAST, and
non-TYPE_SYSTEM_ALERT) doesn't extend into any of system bars, it should
fit IME.
The logic was implemented by pf.set(displayFrames.mContent) in the
legacy insets mode, where mContent would be adjusted after processing
IME.
Fix: 149838078
Test: Steps in the target issue
Test: atest ViewRootImplTest
Change-Id: I6eb685fa1e3ad9789621e5647fc490300054db8b
With this CL, the public developers can interact with display cutout via
insets APIs.
Bug: 118118435
Test: build
Change-Id: If5ccacddb079bc5513ccb5820ea1c371e95fe562
This CL creates InsetsType and InternalInsetsType for display cutout.
With this CL, WindowInsets.getSystemWindowInsets() can be compatible
with the legacy insets mode.
Fix: 149932355
Test: Open an app which has LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
and hides navigation bar on the display which has double display
cutout. And check if the app can get the correct result from
WindowInsets.getSystemWindowInsets().
Change-Id: I381a083d8c30e1678c835eaf5341e941139aa0d7
Accessibility framework default enable prefetching accessibility
nodes in application, when an accessibility service is trying to
query a node on the screen. These nodes are stored in the
AccessibilityCache which is in the accessibility service to save
the IPC between accessibility service and application on screen.
This mechanism does not help performance in some scenarios. For
example, an application with thousand nodes on screen and user
needs to scroll the content frequently. In this case, the
AccessibilityCache will be cleared frequently, and the prefetching
behavior also happens frequently. It becomes an extra effort and
drop the performance.
In this patch, we stop prefetching for a little time while a
scrolling event is detected. This can mitigate performance drop
symptom while user is scrolling.
Bug: 143730839
Test: Manual
Change-Id: I336ee2907ba63c32c6e53259589817dfd14b99e1
Merged-in: I336ee2907ba63c32c6e53259589817dfd14b99e1
(cherry picked from commit 1be8809974)
* So it can be checked against the autofillId from autofill manager
service
* Currently not checking due to race condition, will find a fix in
follow up CL
Test: manual verification
Bug: 149522488
Change-Id: I49457e33c7a1acb028023cb70f248805a96c5346
Currently there are two bugs in the close-guard behavior:
Bug 1:
a. Create surface control from parcel, close guard opens
b. Import new parcel, last object release close guard closed
c. Close guard not reopened, now we have a resource but no close guard
Bug 2:
a. Construct "new SurfaceControl()" but don't do anything with it
b. Now we have a close guard but no native resources
This CL ensures the state of the close guard matches the ownership of
native resources.
Bug: 150128124
Test: Existing tests pass
Change-Id: I0155854213ac64be3ac9a5d264815dbd43018fca
If IME is already visible, requestShow() is immediate.
If animation is finishing and IME is hiding, notify IME process of the
visibility.
Bug: 111084606
Test: Use test app [1] and verify that swiping up and down multiple
times opens and closes the IME respectively.
[1] I4320871bdc8184fac38921616e1a1322f8dbc804
Change-Id: Icf202b56c0bc3833e86ee70c43fedd418e27b140
When calling to SurfaceFlinger to set the display config spec, the
default configId needs to consider the config group of the config.
Bug: 149784270
Test: Simulate multiple config with debug change ag/10355181
Change-Id: I50dce6e31e8cc842a221baaa69e128428f67be99
Need to point to the other method, not just infinitely recurse.
Seems to imply that the tests aren't running in CTS anymore either (this
method doesn't have any real users yet). Following up on why the tests
aren't running seperately.
Bug: 150338132
Test: SurfaceControlViewHostTests
Change-Id: Ie43a6affaac3616164c892713b4bc7fc4b775aa1
Fixes an issue where PhoneWindow and thus Activity can be leaked through AttachInfo through
the OnContentApplyWindowInsetsListener.
Fixes: 148799801
Test: make droid; atest WindowTest
Change-Id: I1de5518c84fd7e6d1aa1542a9252b1c600f5712d
Add ImeFocusController#onScreenStateChanged callback for ViewRootImpl to
callback the screen state for ImeFocusController, and then check the served
view to finish input connection when the screen state is off.
With this change, we can remove InputMethodManagerService#setInteractive
related codes, since we still can finish current input connection
once the device is screen off, ensures the security behavior remains
the same.
This change is expected to reduce accumulated technical debt introduced
by [Prior works] to address multiple edge cases [1][2][3][4], especially
around window focus changes and display-off events.
[Prior works]
[1]. Re-start input when the IME is deactivated but window is focused
(Bug 6188159)
I9189e6d2ac90aa8c621fdb44989728101e00329d
31e4e14994
[2]. Fix a crash in InputMethodManager when switching the IME in the
system process
(Bug 6789252)
I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929
[3]. Call startInput on return from sleep mode
(Bug 17558972)
I95d05110bc1cf310fad23ea1bcbc5890f642d1fc
82ae3ff4cf
[4]. Make IMM more robust to spurious window focus-in
(Bug 26851566)
I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd
Note that one behavior change is that when the screen is on and window focus
back to the app, if the app previously did't request show soft input explictly,
InputMethodManager will not request to show soft-keyboard explicitly for the
next served view.
Fix: 26851566
Bug: 141738570
Bug: 9216494
Test: atest SearchViewTest, FocusHandlingTest
Test: atest ActivityViewTest, MultiDisplayClientTests,
MultiDisplaySystemDecorationTests
Change-Id: Ic11956fe745a829da1ec7c09ea214e9b3961c8e0
Pipe the windowToken of the window requesting hideSoftInput just like we
did it for showSoftInput [1].
This calls hideInsets on the correct display when control target is
different from IME target e.g. ActivityView.
Also hideInsets should be called on InsetsControlTarget instead which was
originally attempted in [2]
[1]: Ia49e23dd077d264a58d28a7b8acffde54b7db187
[2]: I7133e151a1037c42b275b97857936437a7a6725f
Bug: 149870112
Bug: 133381284
Test: Manually using steps mentioned in bug.
Change-Id: Ia596a392eb73ae46debd097151c8c9a7edd59833
* add isPinned() to InlineSuggestionInfo so IME can choose to pin the suggestion
* allow augmented autofill service to set inline actions in the response
* non-api change: pull the autofill hints from the Slice in the InlinePresentation
Test: m -j; atest InlinePresentationTest, atest CtsInputMethodTestCases:InlineSuggestionInfoTest CtsInputMethodTestCases:InlineSuggestionTest
Bug: 137800469
Change-Id: I63b6b843ef056df18c317299e617b8fe21907374
When IME is no longer shown, notify IMS to hide the window surface.
This reclaims the memory allocated to IME window surface.
Fix: 150163310
Test: atest CtsInputMethodTests
Manually:
1. Open any app that has editor and run
adb shell dumpsys SurfaceFlinger | grep Total
2. Note down total memory
3. Tap on editor and IME shows. Note down memory
using command in #1. It should go up by ~27MB
4. Hide IME and note down memory again.
It should revert to original value in #1.
Change-Id: I6c2a13dd40b22d3fd62b4763ba369992e5ff1138
