After rotation, the divider should always in middle if not in
minimized mode, so it should use middle position rather than
divider current position to resize split on rotation callback.
Fix: 192219057
Test: manual
Test: atest WMShellUnitTests
Change-Id: I255c1d6aad9a796ca3ec722f45977eb360fe3805
When device (factory)boot, controller regsiter settings
'one_handed_mode_activated' will receive callback, and
the shortcut do not enabled by default, the flow will
go to auto enable one-handed mode feature and leading
unexpedted UX(disabled by default) and testing issue.
Solution:
- Add additional check for shortcut enabled when
onActivatedActionChanged() callback.
- When setting is pull screen, notify shortcut
one_handed_mode_activated to reset and align current
mState when function enabled.
Note:
The setting provider one_handed_mode_activated could set
2 different values when shortcut button pressed
- "0" mapping to pull screen STATE_NONE
- "1" mapping to pull screen STATE_ACTIVE
Since show notification do not have state, whenever
onChange callback, we trigger expand notification.
Test: atest WMShellUnitTests
Test: manual factory reset | reboot check Log should show \
"Shortcut not enabled, skip onActivatedActionChanged()".
Test: manual disable both OHM & shortcut toggle in settings \
'# adb shell settings --user 0 put secure \
one_handed_mode_activated 1'
should not auto enable OHM main toggle.
Bug: 191736174
Bug: 191831415
Bug: 191950195
Fixes: 191812697
Change-Id: Ib9d66fbbcc7e6a52a37bb47efebf90c9d2644508
Add back the divider bar view's visibility checks which was removed by
ag/14318188 in order to prevent caching IME status while the split is
not activated.
Fix: 188807172
Test: lock and unlock the device with password keyguard while split
activated, observed the split divider handler is visible.
Test: rotate the device while showing IME, then dock two apps to enter
split mode, observed the split divider handler is visible.
Change-Id: Iaa4a68f98bab6a832f4b2cbd448cb42b1ecb9bbb
As CL[1] removed the delay time to remove starting window in shell,
even the benifits is to make good touch responsiness when launched the
activity, but may easier cause flickering since removing the starting
window when the activity allDrawn doesn't means the UI are all set.
(like some apps might needs adjust the surface frame or even IME
needs more time wait for animation finish, if the snapshot window
has these previews).
In case flickering happens when the Shell removes the task snapshot
window too quickly, partially reverts CL[1] delay removal logic
in TaskSnapshotWindow#remove, and use TaskSnapshot#hasImeSurface
to set a proper delay removal time:
- General (no IME visible): 100ms
- IME visible: 350ms
[1]: I5fb0fa3a1e6a5e6210d3baf400a84c5892bd2e34
Fix: 189825624
Test: manual switch tasks with/without ime window, also test
with some market input methods.
Change-Id: I7865e17b57961e12a0cdcf068e412195123a6ec7
Previously, leashes would be only released by GC in some cases, but the
timing could be late. This CL proactively release them as long as they
are not needed. The cases were:
1. The leashes in DisplayImeController. It didn't release leashes while
receiving a new one.
2. The leashes returned from addWindow/relayoutWindow. The leashes would
be copied to prevent others from releasing them before writeToParcel.
The copied leashes could be redundant after writeToParcel.
3. The leashes held by the client whose window is removed. If a window
is removed, the server won't invoke mClient.insetsControlChanged, so
the client would never get notified about losing control to release
the leashes. This could happen if the window doesn't have an exiting
animation.
Fix: 175851610
Test: Steps in the bug.
Test: Show and dismiss a dialog which doesn't have FLAG_ALT_FOCUSABLE_IM
or any window animation. Repeat this thousands of times. And see
if there are many insets leashes as offscreen layers in `dumpsys
SurfaceFlinger`
Change-Id: I5eb774ac071154a8d7205dbd1ab4a5f8eca215c3
In previous design, we only get the display bounds once when the first
time the hide cutout is enabled. But if user selects "Hide" first and
then switch to "Render apps below cutout area", the display bounds we
get will be incorrect.
Add a listener to monitor and update the display size.
Bug: 191273507
Test: atest HideDisplayCutoutTest
Test: manual - 1. select "Hide"
2. select "Render apps below cutout area"
3. observe the result
Change-Id: I0ff1c4b822615d6bd43adb2e9e9d17d6bd9b91a8
When create view with Context, there will also load some view
attributes from the Context and pre-set to the View object, to ensure
the splash screen view not affected by those attributes, clear padding
and background after create those view objects.
Bug: 191339594
Test: manual launch several apps from Launcher/Notification.
Tets: atest SplashscreenTests
Change-Id: I05be9c296a04cd49a0896ad8aef57643720d60ce
When Device boot and SystemUI servies starting, settings provider
may callback onChange() when OneHandedController register observer.
If the callback timing earlier han mEventCallback registered by
WMShll#initOneHanded, then the NPE will happen.
The simple fix is to add NPE check in
OneHandedController#notifyExpandNotifcation()
we can just ignore the callback during init time since the singal
is to expand notification and come from shorcut after user enable
and tap shortcut.(No need to act for the signal during boot progress.)
Test: manual reboot device and observe
Test: atest WMShellUnitTests
Bug: 191600033
Change-Id: I73849afa9904031759da304298221dbb222aeaaa
After first launched activity start remove starting window, there start
a second activity with a new task, so there will trigger a open/close
task transition while playing starting window exit animation, but since
the first launched activity is going to destory, there will goes to
clear all window for that activity.
For client side we can ignore the animation after it was detached from
window.
Bug: 190040281
Test: manual
Change-Id: Idd939feb72163d585e14db480b1e374e41597928
If the Task is already in PiP mode and fixed rotation is happening, we
still need the onMovementBoundsChanged callback to go through in
PipTaskOrganizer.
Note that there seems to be an existing bug that Launcher shelf height
is ignored with the following steps
- Enter PiP and open another app to fullscreen
- Rotate screen and swipe the other app to home
Video: http://recall/-/aaaaaabFQoRHlzixHdtY/gs08EEyHyNcn86lsIcbIRe
Bug: 191143521
Test: follow the reproduce steps in bug, see the video
Merged-In: I601c7493794316883445e9c69e5cdd6a808e8933
Change-Id: I601c7493794316883445e9c69e5cdd6a808e8933
onActivatedActionChanged() was invoke When setting
ONE_HANDED_MODE_ACTIVATED update, the root cause is
onRotateDisplay() in OHMDisplayAreaOrganizer and go
to finishOffset() and callback onStopFinished(), then
OHMController#onStopFinished() invoke reset settings
through notifyShortcutState(STATE_NONE) which reset
settings key ONE_HANDED_MODE_ACTIVATED to 0.
At the meanwhile reset key cause observer invoke
onActivatedActionChanged() to expand notification again.
The simple solution is directly return if current setting
is "Swipe notification" in OHMDisplayAreaOrganzier
onRotateDisplay() to avoid finishOffset() called.
Test: manual tap OHM shortcut to expand notification,
rotate to check if notification expanded
Test: atest WMShellUnitTests
Bug: 191337996
Change-Id: I697dbabce070249f0a5e513abd514f9e02b8aa16
1. Sets LockedDisabled when onStartedGoingToSleep()
2. Reset LockedDisabled when onFinishedWakingUp()
3. Update keyguard showing state to controller through
onKeyguardVisibilityChanged(showing)
The flow changes:
1) POWER-KEY going to sleep(AOD)
2) onStartedGoingToSleep() <--New timing for LockedDisabled
3) onFinishedGoingToSleep()
4) onKeyguardVisibilityChanged(true) <--Legacy LockedDisabled
---------------
1) POWER-KEY waking up to HOME
2) onStartedWakingUp()
3) onFinishedWakingUp()
4) onKeyguardVisibilityChanged(false) <--Reset LockedDisabled
Screen OFF to AOD flow takes about 1800ms:
POWER_KEY---(400ms)---> onStartedGoingToSleep()---(100ms)--->
onFinishedGoingToSleep()---(1300ms)--->onKeyguardVisibilityChanged()
Screen ON to HOME flow takes about 700ms:
POWER_KEY---(50ms)---> onStartedWakingUp()---(160ms)--->
onFinishedWakingUp()---(500ms)---> onKeyguardVisibilityChanged()
Test: Manual PowerKey going to sleep > Trigger One Handed mode
Test: atest WMShellUnitTests
Bug: 191149165
Change-Id: I557ab4736d0f77b38334fb95d89dcf0875fc5be2
- WindowManagerGlobal has a shared lock which means that code in the
shell main thread can deadlock with code running on the sysui main
thread in rare cases (ie. display changes when folding/unfolding).
Ideally there are no blocking calls between SysUI/Shell so this
change caches state changes from the Bubbles side for querying from
SysUI. In particular, the expanded states and the suppressed states.
Bug: 190453559
Test: atest SystemUITests
Change-Id: I4e60b168a84618033604e7d097599b048a5886a1
