Fix issue that prevented user switcher from opening on tap
Bug: 186244907
Test: With config_keyguard_user_switch_opens_qs_details=true, check that
tapping user icon opens the user switcher QS panel
Change-Id: Idf3c5154b87b13ea046a89f3fd2ed2a4fafcc28c
Previously, after toggling dark theme on/off, the keyguard user icon
would not update until it was clicked.
Also, remove unused private field mDarkAmount
Bug: 184204785
Test: With config_keyguard_user_switch_opens_qs_details=true, toggle
dark theme on/off and observe keyguard user icon
Change-Id: Ic47ed44c0c970d050178ce2c26aaccb661286ece
This enforces stricter rules on the SkSL at effect creation time, and
ensures it's valid as an SkShader (vs. an SkColorFilter). Also updated
some SkSL that was already (or would become) illegal:
- Child shaders must be declared 'uniform', not 'in'
- sampling a child requires coordinates
Bug: skia:11813
Change-Id: I743b985b5012723186a43e58e9e3ccf29d809d2b
(cherry picked from commit 7556777511)
Also, do not show dialog if there are no elements to show.
Test: atest PrivacyDialogControllerTest
Bug: 186033456
Change-Id: Ia860c63f2bb46beb80ca86cf9260ffeaafedb32d
As previously InputMethodManager#toggleSoftInput is designed to tell
InputMethodService directly through IInputMethodSession to toggle
soft-keyboard visibility, this could be happened some unexpected IME
visibility issues that when the app calling this method in the wrong
state like the app toggling IME visibility when the app is off-screen
but unexpectedly it ends up showing soft-keyboard when the IME is in
invisible state.
To minimize the app compatibility without changing the public API
surface and reducing unexpected IME visibilty been toggled behavior
especially happens when switching the apps, changed the internal IPC
protocols to call IMMS#showSoftInput or IMMS#hideSoftInput directly
according the previous IME consumer requested visibility state,
so that in IMMS side can validate to see if the token user is
still focused and ready to toggle the IME visibility to show or hide.
As the result, we deprecated toggleSoftInput and
toggleSoftInputFromWindow to state the reason as the above, and
recommand to use showSoftInput or hideSoftInputFromWindow instead,
so that framework side no longer has to call {InputMethodSessionWrapper,
InputMethodSessionImpl}#toggleSoftInput.
Bug: 182071625
Test: m checkapi doc-comment-check-docs
Test: atest KeyboardVisibilityControlTest#testToggleSoftInput
Change-Id: I390dc029e7bcc30c200926a9bfbbbd0268a1f714
When the magnifier content moves relative to the parent surface,
it will call setPosition on the content surface control. This conflicts
with position updates called by the BlastBufferQueue adapter
causing a flicker on screen. Fix this by providing a wrapper surface
to BlastBufferQueue adapater to send buffer updates.
Fixes: 186072574
Test: Select text and see magnifier surface does not flicker or move
around
Change-Id: Idfcc06a5d90f400f69e5cbe91008a0cb59fd4646
Putting empty values for now to cope with proto changes. Will replace
the place holders with real values in follow-up CLs.
BUG: 184844615
Test: atest android.cts.statsdatom.incremental.AppErrorAtomTests
Change-Id: I5a6adcf91c67f331a43e76ee706fdb5f2ffe67d6
Add window container transaction APIs to indicate launch root for task
launching with FLAG_ACTIVITY_LAUNCH_ADJACENT. If launch adjacent flag
root is available, consider to launch to its adjacent task if the launch
is coming from the same root task.
Fix: 169271875
Test: atest WMShellUnitTests
Test: atest TaskDisplayAreaTests
Test: manual test FLAG_ACTIVITY_LAUNCH_ADJACENT behavior with adjacent
root.
Change-Id: I1716aaa48745d2c32cd413c8eac0b1d17810f0de
Previously we relied on ConfigurationListener for
rotation, however, this relies on portrait / landscape
rather than the actual rotation of the device (e.g. 90
vs 270) so if the device was rotated from 90 to 270
(both 'landscape') we wouldn't be notified to update the
position of the bubble.
Fix is to use onDisplayChangingListener to get the exact
rotation. This is notified *before* the layout has
happened for the new config so updates to the positioner
have moved into BubbleStackView where there's a layout
listener in response to the orientation.
Fixes: 182172825
Fixes: 172530640
Test: - Have a bubble
- Put device in landscape
- Rotate it to be landscape again but on the other
side
- Rotate back to portrait
=> Note that the bubble is always along the edge
of the phone & never goes off screen or is in
the middle of the screen
=> Also expand the stack in each of these steps to
ensure the bubbles are at the top in portrait
and at the sides in landscape
Test: - Have a bubble, expand it
- Rotate the device several times, make sure the
position of the bubbles & expanded view are
correct
Test: - Have bubbles on left edge
- Change the screen size
=> Notice that the bubbles are placed correctly
Change-Id: I76e97529d991102e5b052176bff29e1063537273
In the current implementation, ret.complete will still be called after
ret.completeExceptionally is called. Although the second call doesn't do
anything right now since the implementation of AndroidFuture ignores
consecutive attempts at calling complete on an already completed future,
it is better to avoid these kind of behaviors in the first place.
Bug: 186237458
Test: manual
Change-Id: I65e44c28ded947d499ba74aafd9a2686f02a9f18
