ClipboardService previously used noteOp for all clipboard operations,
but this leads to the data being polluted by non-access methods like
getClipDescription and hasPrimaryClip. Move those methods to checkOps
instead.
This also moves the app op check to the end to avoid logging in
scenarios we would have rejected access anyways.
Fixes: 160791050
Test: atest ClipboardManagerTest
Change-Id: Ibb9299f918fcb5ef406f35405769099d179bdcd3
Was using just the window target, but we need to actually use
the inputmethodinputtarget since that has an activity that can
actually be checked for split-screen mode.
Additionally, we need to force-update the Wm configuration
because we skip doing so when divider is "hidden" by keyguard.
Bug: 159457357
Test: open split with pip running. Open keyboard in secondary,
lock screen, then unlock.
Change-Id: Idbc0c3b90c18a55cc664c6958546994cbb8549ee
After the StateMachine has quit, getCurrentState()
returns null, which will throw an exception in dump().
Bug: 160283853
Test: atest StateMachineTest
Change-Id: I4f9906eef6210b037d2170904a7c3aa483f5b4e9
This reverts commit 39f818c76c.
Reason for revert: Breaks LIGHT_STATUS/NAVIGATION_BAR with LAYOUT_IN_CUTOUT_MODE_NEVER
Bug: 152273579
Bug: 159627574
Bug: 156301377
Test: Receive call on device with a cutout, verify status bar has icons
Change-Id: I4de084c86ba234fec586e9cd140138a47ed5d87a
- Attempt to mask an issue with the menu window resizing before the
reset transform is applied by delaying the start of the menu
animation after the pip expands and extending the duration of
the animation.
Bug: 160826797
Test: Expand pip repeatedly
Change-Id: I1f8d524f2221b8bfb18a918b192b3e1c20dd6030
We won't ever disable it and it's ok to ship it.
Deleting the flag will be done in master given it's a much larger CL.
Bug: 160826507
Test: manual
Test: systemui tests
Test: atest PreferencesHelperTest
Change-Id: I142e7af6316fd9b31cbee2d92df7d89ff42bbc4c
internal_private_accessTopLayerRenderTargetContext does not
guarantee that a GrRenderTarget is created. Moving flush before
internal_private_accessTopLayerRenderTargetContext resolves that
issue. GrRenderTarget was often nullptr, when drawing WebView in a
layer.
Test: Passed CtsUiRenderingTestCases. Ran two tests apps attached to the bug
Bug: 156413480
Change-Id: Ib3e23c4ab58eb3d02daa05979f545b75a8bfea07
AAOS uses multi-user model, and apps become queriable after user is
unlocked. Thus we need to make sure that the querying happens at the
right time with the right user with resolveActivityAsUser.
In order not to affect the stability, we can use the null check +
Automotive check for R.
This null check + Automotive check can be removed when resolving
Activity as User is implemented in S+.
Bug: 158508455
Test: Manual
Change-Id: I58e37f795136508ef7bb53c40214ed3c76f588bf
As CL[1] we introduced WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR start
input reason to ignore start new input when the focused view is
same as current served view and the input connection remains the same for
prevent additonal onStartInput / onFinishInput callback to
InputMethodService.
The main idea in the CL is good but how to judge whether the input connection
remains the same is not accurate.
CL[1] only checking if IMM#mServedInputConnectionWrapper self and its
input connection instance is stil exists, that breaks the following cases
to start new input:
Case 1:
- When device screen off / on to go back to focused app, this case will
fit WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR use case, so
IMM#mServedInputConnectionWrapper won't be deactivate and clear, this
makes wrong when user taps IME picker dialog to switch IME, will hit
again WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR and never start new
input for new IME.
Actually, in InputMethodManager has an ad-hoc check mRestartOnNextWindowFocus
to start new input when device screen off / on case and switching IME,
we should not ignore start input since that will conflict with the above
case.
Case 2:
- As served view is now tracked by ImeFocusController which is per-window
based instance from the IME focus handling refectoring CL[2],
but InputMethodManager instance is still per-display based, so
IMM#mCurrentTextBoxAttribute might be changed when the same app clinet has
multiple IME focusable window focus changed, because focusing to the next
IME focusable window will start new input connection and changes
IMM#mCurrentTextBoxAttribute, so when focusing back to the
original window, the served view in the original window's
ImeFocusController will same as focused view, in that case if we didn't
check if IMM#mCurrentTextBoxAttribute is really aligned with the given
focused view, will mis-judge start new input timing and caused user can't
type because the input connection state is obsoleted.
Those cases can be addessed by using new introduced method
IMM#isSameEditorAndAcceptingText, if the focused view is not aligned
with same editor or the editor is inactive, we should start new input
for Case 2, that also can fix Case 1 that we previously ignored starting
new input when switching IME.
Beside, we also found CL[3] leverages
InputMethodManager#mRestartOnNextWindowFocus to start new input when window focus
changed, since originally this ad-hoc check is only used to re-start input
for Case 1.
As we re-visited the necessary start new input scenerio is only when:
- Device screen off -> on
- Switching IME
- the input connection obsoleted
(this also includes when window focus changed)
As the result, we can remove all unnecessary logics in IMMS
instroduced by CL[1] and remove unnecessary
InputMethodManager#mRestartOnNextWindowFocus from CL[3], and preserve
the behavior is almost same as Q.
[1]: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
[2]: Ib455704fe1e9d243f93190a84f230210dbceac2a
[3]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 160391516
Bug: 158624922
Bug: 152373385
Test: atest FocusHandlingTest
Test: atest InputMethodServiceLifecycleTest
Test: manual for case 1
0) pre-install 3rd party IME app
1) launch message app and taps Search bar to focus.
2) turn off screen
3) turn on screen to back to focused app
4) press IME switch icon from nav bar
5) choose next IME, expect the IME should be changed.
Test: manual for case 2
0) Sample app with 2 activites, each activity the layout has
EditText
1) Launch activity A, focus EditText
2) Launch activity B and focus EditText
3) Press back key to back to activity A
4) Verify if typing with keyboard is workable.
Change-Id: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
