- Always launch workspace card if it's focused when quick scrub ends
- Previously it would get stuck if quick scrub end was called on
a background thread (since it was trying to touch RecentsView)
- Prevent user from being able to get to the workspace card if
starting quick scrub from an app by introducing bounds checking
- Prevent getting stuck in overview when ending quick scrub
- There was a race condition where the task wouldn't launch if
the animation to recents hadn't yet finished. Now there is a
callback to ensure that launchTask() is always called after.
Bug: 70180755
Change-Id: I3c131011634880a97de8c2935c3ebdab26494b48
These records are required by “Transition Delay - Hot Launch From
Recents” test. It doesn’t look at transition times for this event. They
are just a part of its expected sequence of events.
I generate transition delay times as zeroes because no one is looking at
them.
Bug: 72967764
Test: atest google/perf/app-transition/app-transition-from-recents-trace
Change-Id: I4a5b76b95c6c4b54e7fb620951342a3ed8564aed
Add OverviewInteractionState to handle setting OverviewInteractionFlags.
Hide back button when in NORMAL state and launcher's window is focused.
Show it when in other states or when launcher's window loses focus.
Change-Id: I35919561b9972789e995f1cc434c23e2afe9e77c
The fix is quite hacky and should be re-done soon. I’m not leaving TODOs
in the code, but I’m tracking the cleanup elsewhere.
We also need a fix in the server to make the test work, but that will be
another CL.
Bug: 72967764
Test: atest google/perf/app-transition/app-transition-to-recents
Change-Id: Ia21c308caa81bd5502f4a4587ae445928f6eca17
Bug: 73242451
Test: Swipe up over back with suitable launcher build and ensure that we
don't start the recents animation on touch down
Change-Id: I98314611eaeeabfaa47280157300ea20f0571a61
Launcher's window doesn't have focus when on minus one. In this case, we
tell the minus one overlay to hide and add a window focused callback to
start quick scrub/switch after launcher regains focus. Since the
transition from minus one takes longer than for launcher to get window
focus, we also defer until the overlay is completely hidden before
starting the quick scrub transition.
Bug: 70180755
Change-Id: Ifcf85aaf1942b51394e68e209b89807fa4007afe
When we get the onQuickScrubStart() or onQuickSwitch() callbacks, we go
to the overview state with a quicker duration (the same used from apps).
Then we follow the same logic as starting quick scrub/switch from apps
except that we allow you to scrub back to the workspace card.
Bug: 70180755
Change-Id: Iebcdcc4c4ad1e1210e2d1c11e5007c27d3c1eef3
When animating the wrospace, we skip the properties if for start and end are same.
But after creating the animation, if the property changes, the final property is
never applied.
Bug: 72257542
Change-Id: Id408c7820476273958e835ae99a3a934ad5a4700
- Clean up the consumer when starting quickscrub/switch in addition to
motion up
- Defer invalidating the handler until after quickscrub ends
- Ensure that we always finish the remote animation
Bug: 67957962
Bug: 70180755
Change-Id: Id5af5dc9917638f1dfb8e4a04c358aadb19fd67a
Intead of finishing the entire animation (launcher animation and
window animation), we finish just the launcher animation.
Bug: 73071035
Change-Id: Ied84cb641f3cedc367433ad99d21ab1b258ae7f8
* This ensures that the current time is used for the clock icon.
* Also switch from ImageView to View, to avoid an alpha bug.
Bug: 73000086
Change-Id: I6576d76b95fb157d0bfe8db4fda899e644773bfa
- Make use of app/home insets and minimized home size to calculate the
proper clipping and target bounds for the task view in home.
Test: Swipe up when in multiwindow
Change-Id: Ibef7a6dc319ded7867ee559dd31c5e87fd76cadb
> Resetting the state to NORMAL on every onStop so that the user
never starts on the overview screen
Change-Id: If3c17693b7125a3969809e60891a2ab978fe83bc
The app transition might change an object that the new
state depends on, causing an inconsistent state.
Bug: 72816542
Change-Id: Ia6dd52971b52be5589c88f4f6d93d06146fbadab
