Framework has supported (ag/20876922) sending back progress on cancel. So no need to re-do the work on app side.
Bug: b/267664388
Test: manual, this CL has no visual change
Change-Id: I47c751d12a9b2c602ac6f3028665b996990fbd7e
Persistent taskbar background is always dark regardless of device theme,
so we should make the icon always light for now.
Test: Manual
Fix: 262837720
Change-Id: I8f66af874e07f68e1943245e9cd49c3b3107915f
This will make it explicit in a trace when we're waiting for one additional frame after onResume to start processing unfold animation related progresses
Bug: 267287854
Test: recorded trace locally after unfolding
Change-Id: I3b13842f018c6f23cbb5bc1c1cfd77e5c38dad98
The AnimatorPlaybackController from createLauncherStateFromSuwAnimation
does not ever get started (it's all user-driven) and thus some internal
state is not updated properly, namely mIsStashed is never set to false
even though the animation unstashes visually. This will break the first
"real" unstash animation after SUW. Thus, when the animation from SUW is
completed, we now dispatch onAnimationStart() and End() to ensure the
proper state is updated.
Test: adb shell am start -a android.intent.action.MAIN -n com.google.android.setupwizard/.SetupWizardTestActivity
Then, skip to the end and swipe to home; ensure first app launch
properly stashes taskbar
Fixes: 263533070
Change-Id: I9553b8a884fb84303e2e97f14b9a7051e9de4709
This patch makes it so that the correct task will be chosen when selecting a second splitscreen app via Taskbar.
Prior to this patch, the Taskbar app selection function -- which attempts to match the tapped icon to a running TaskView -- assumed that the TaskView in question was always a solo (non-grouped) Task. This resulted in the wrong app being selected for split when the desired Task happened to be the secondary app in a pair.
Fixed by checking to see if the desired app is primary or secondary, and returning the correct Task, IconView, and ThumbnailView for the split operation.
Fixes: 265244769
Test: Manual
Change-Id: Ie1122d1b49151d70dec9711fe558fba7752b7d8e
- After SUW, registerPredictor is called for hotseat, and then BaseLauncherBinder will call bindExtraContainerItems with empty items. A subsequent registerPredictor will then be triggered by LoadTask, but handleUpdate will skip the update due to no diff in PredictorState targets. As a result, HotseatPredictionController always have no items after SUW
- Clearing PredictorState when it's re-registerted will allow the respective prediction controller to receive new prediction items that comes with the registration.
Fix: 265340241
Test: Factory reset, pass SUW, prediction items are in hotseat
Test: Reboot, prediction items are in hotseat
Change-Id: Ie6e219028e7fde42854459d34806a04052dc41ba
Fix: 260655218
Test: manual. Create second user, switch to three button nav, set lockscreen password, lock and show IME on lockscreen.
Change-Id: I1d874196afc24d5bae86d525a81ae199152fc750
This patch fixes the following user flow:
1) App is already running
2) User initiates splitscreen from Home with that app
3) User selects the same app from Taskbar or AllApps
Previously, this caused a crash because the split-from-home initiation removed the corresponding app tile, causing a null pointer exception when the same task ID was used as a split target.
Fixed by adding a null check: if the target TaskView can't be found for any reason, fall back to launching the second app via Intent instead. If the app doesn't support multi-instance, the UI will now show an attempted split, followed by the message "This app can only be opened in 1 window."
Fixes: 263041522
Fixes: 266218404
Test: Manual
Change-Id: I39ed60c9ac758ac215391f0618f44f7fcee4f32c
There have been new developments in the design of download apps to have better colors with better contrast. We will guard this progress under this flag.
Bug: 267272201
Test: N/A
Change-Id: I905436f32daeb62bed26b483773283ce38f66923
We didn't handle such case if transient bar enable and divider is
hidden by split side so it will have a delay.
Catch up it on handleNormalGestureEnd if end target is home.
Fix: 265755388
Test: manual
Test: pass existing tests
Change-Id: I09ac2a3a57c51473daf2b6887cd23bca505378f7
- Make temporary taskbar background behind assistant non-touchable
(fail-safe in case the window isn't removed for some reason)
- Give temporary taskbar background a different window title and
add a couple more dump statements to help debugging
- Only show the taskbar background for persistent taskbar; transient
taskbar can skip most of the special casing and just hide it
- Fix bug where we weren't drawing the separate taskbar background in 3
button mode
- Fix bug where we weren't actually synchronizing
separateWindowForTaskbarBackground with TaskbarDragLayer, since the
former wasn't attached to the window yet; now we wait until it is
attached before calling synchronizeNextDraw()
- Also added dump logs for TaskbarDragLayerController alpha channels
Test: manual in 3 button and gesture nav (with and without
FORCE_PERSISTENT_TASKBAR enabled)
Fixes: 243652789
Bug: 262664266
Change-Id: I865871e57dd4cb255a916317a7e5d35cfde97df5
Rather than use a feature flag for this feature, the on/off state will
be stored as a system setting and will be changed via a QuickSettings
tile.
Bug: b/264452057
Test: Verified that the new QuickSettings tile doesn't crash via normal
interactions (pressing, long-pressing, etc.). Also verified that
ViewCapture is turned on when the QuickSettings tile is in the enabled
state and is turned off when it is in the disabled state.
Change-Id: I90551511ac2766dc30c51a25aec2c96e3e552ce9
- This is to fix a regression from http://ag/20968628. Instead of returning null and change the behavior, return null and do null checks on callers
Fix: 266109700
Test: Swipe AllApps from home on tablets, no flicker on taskbar, for gesture and 3-button
Change-Id: Ic1900ef396b00187ce9eced906c4628436481213
