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
It is possible that sometimes when PiP menu is not showing, it is not
updated correctly.
Bug: 190210447
Test: Enter PiP
Change-Id: I87639a6d568e96e26d4b79ba68a6349ec0ae29e1
1) Add OneHandedEventCallback for WMShell to register
callback, and if one handed mode settings set show
notifications, when user tap one handed mode shortcut
notify WMShell send KEYCODE_SYSTEM_NAVIGATION_DOWN
through OneHandedEventCallback with SysUIMainExecutor.
2) Add isReady() flag in OneHandedDisplayAreaOrganizer
and Simplify the flow of onActivatedActionChanged()
to prevent potential race problem while auto-enable
One-handed and immeditately startOneHanded(), however,
DisplayAreaOrganizer#onDisplayAreaAppeared() may not
ready for transtion yet, and result mState keep in
unfinsihed STATE_ENTERING.
3) Adjust the transiton duration from 800ms to 600ms
800ms is a little bit long to affect timing of
apply runtime overlay package.
4) DelayExecute setEnabledGesturalOverlay() until
transition finised and at most delay once.
- onSwipeToNotificationEnabledChanged() : DelayExecute
- onEnabledSettingChanged() : DelayExecute
- Ctor setupGesturalOverlay() : No DelayExecute
- mState.isTransitioning() : DelayExecute
Test: WMShellUnitTests
Bug: 182425480
Change-Id: I2615c3b30ad95a858510b4bcc73d8f343843fc96
The PipResizeGestureHandler was previusly signaling a start
of the pinch resize without checking that both pointers were
within the PIP bounds region. This caused the TouchState to
be reset with a single tap outside the PIP window while
drag-moving it with another finger, which led to PIP becoming
stuck without snapping to the edges.
With this CL, we make sure that both fingers are inside PIP
before starting resetting the touch state and allowing the
pinch resize to start.
Bug: 188640607
Bug: 186607893
Test: move the PIP with one finger and while still holding it
tap anywhere outside of PIP with another finger - verify you
can still keep moving the PIP with the first finger normally.
Change-Id: I2137180ea1f333fe2e0b67e52d57da5ff9a2d094
The SurfacePackageViewHost was never release, leading to a leak of its
surfaces.
This CL ensure it is released:
- Directly in the shell if the SplashScreenView was not copied
- From the client, through the window manger and then to the shell if
the splash screen was copied in the client process
Test: Manually tested with app setting by checking if the surfaces
are actually removed (winscope + logs) in the following scenarios:
- When the application registers an OnExitAnimationListener
and calls remove(),
- When the application registers an OnExitAnimationListener
and dies without calling remove()
- When the applicaiton does not register an OnExitAnimationListener
and the shell removes the splash screen
Bug: 189759180
Change-Id: Ib68bfffad6720911368739d7dd87d8a03034c589
There were a couple of issues:
1) onActivityRestart wasn't checking for bubbles in the overflow
so there were cases where we could open a bubble but weren't
2) delay opening the bubble until after the transitions have
happened when launching from a widget, the transition could
alter the placement of the bubble's surface resulting in
weird UI.
Test: atest LaunchConversationActivityTest
Test: manual 1) have a bubble & convo widget for it
2) tap on the widget => bubble opens normally, close
the bubble & repeat that a bunch
1) have an unopened bubble & convo widget for it
2) get enough bubbles to push it out of the stack &
out of the overflow
3) tap on the widget => bubble opens
1) have a bubble & convo widget for it, dismiss bubble
2) tap on the widget => bubble opens normally
Bug: 188306336
Change-Id: Id68ccbfbfc6fc6949cfc257df4706b470fb78569
