Reduce potential lock contention during start input
IMMS#startInputOrWindowGainedFocus invokes several WM internal methods
to check if the IME client and its windowToken has IME focus:
- getDisplayIdForWindow(windowToken)
- Checked at beginning of startInputOrWindowGainedFocus to know if
the displayID of the client window is same as the client reported
displayID.
- isInputMethodClientFocus(uid, pid, displayId)
- Checked next to getDisplayIdForWindow invoked, it's to know if the
client is focused on the display.
- isUidAllowedOnDisplay(displayId, uid)
- Checked in startInputUncheckedLocked, used to see if the client's
uid is allow to access on the display.
As calling these methods requres holding WM locks, if the lock
contention takes longer time, it may impact the UI
performance since startInputOrWindowGainedFocus is a sync IPC
call that requires the remote client to execute on the UI thread.
To Remove/reduce unnecessary internal module calls that requires
holding lock by followed ways:
1) Remove isUidAllowedOnDisplay & getDisplayIdForWindow validation
check & combine these checks into isInputMethodClientFocus with
adding windowToken parameter, to reduce the timing of being blocked
by WM lock.
2) Make startInputUncheckLocked as private method and add documentation
- as all call points of startInputUncheckedLocked is inside of
startInputOrWindowGainedFocus, even though 1) removed calling
isUidAllowedOnDisplay, it still be checked in the combined version of
isInputMethodClientFocus without any visible change, and adding the
documentation for invoking startInputUncheckedLocked requires
the focus check must done before.
2) Refine WindowManagerInternal#shouldRestoreImeVisibility to
smaller the synchronized block since WMS#getTaskSnapshot should
not be called when holding WM lock.
Bug: 197848765
Test: atest CtsInputMethodTestCases
Change-Id: Ie850a67c116466c46bd62d44f4fbdd5584eda5de
3 files changed
