`MyDepthController` in `QuickstepTransitionLauncher` assumes that we
want the background to always animate the same way, matching the rest
state of the workspace (depth == 0). However, in Taskbar All Apps the
background is visible, and depth != 0. We now initialize the one-off
`DepthController` for launches to take into account the latest depth set
by the top level `DepthController`, so there is no jumpcut at the
beginning of the animation.
Note that in my opinion we should use the same `DepthController` for all
cases, rather than having this one-off. I'm looking into the feasibility
of that change, but for now this fixes the issue at hand.
Fix: 292959100
Flag: N/A
Test: manual, see videos in the bug
Change-Id: Id90e8e728cc3e2ccf7d92148fbb0d6ff3e6fd6ca
Flag: None
Test: adb logcat -b events | grep jank_cuj_events
- Verified quick switch from home gets begin and end
- Verified quick switch then swipe back or up to home
gets begin and cancel
- Verified quick switch then swipe up to overview
gets begin and cancel
Fixes: 290323639
Change-Id: I4f1991251b111c0531b30c48ba610ce85dcafdd3
ag/23852178 introduced a clean up for launcher state when invoking
transient taskbar. It was checking launcher activity resumed state with
`isResumed()` method. This breaks transient taskbar for desktop mode as
we are marking the launcher activity to be paused using the launcher
flags. `hasBeenResumed()` method is the one we can used instead as it is
checking the launcher flags and not the resumed state of the activity
itself.
Bug: 292266259
Test: open transparent activity on top of launcher
unstash taskbar
go home
Test: move an app to desktop, unstash taskbar
Change-Id: I98d14dbfdde4b857f50e62206fc0f308e8f54231
ag/24138143 made the rule to produce empty captures in many cases.
ag/24138143 aimed to fix a leak that was caused by a local var
alreadyOpenActivity still referring the activity when the leak check
executes.
Fixing that by moving the variable to a method startCapturingExistingActivity.
Bug: 291638593
Test: local, presubmit
Flag: N/A
Change-Id: I281202488c6c85e2e2c5b5b3300e26d808167104
- There seems to be test corruption that is coming from the TwoPanelWorkspaceTest as they are getting marked ignored from assumption exception.
- We are branching the logic of asseting taskbar depending on taskbar variant until we figure out how we can run test with TaskbarSwitchMode test annotation and pass it on first attempt. This is cunrrently not working for above reason.
Test: Presubmit
Bug: 286084688
Flag: not needed
Change-Id: I77a141455eceffd11fa8f74a7e204de9b36384fd
If floating search is active in Overview (flag enabled and we are
the active Launcher), these buttons will be aligned to the search
bar relative to the bottom of the screen. Otherwise, the buttons
will be aligned below the active task like before.
Demo for Launcher3 build:
https://drive.google.com/file/d/1fVzRRnW5AFDMPkW-E8_w4BOCzTAOURQ_/view?usp=drive_link&resourcekey=0-6-EbFZXkBqcu0rw7uuEzjw
Bug: 292000892
Test: Manual with floating enabled/disabled and
SEPARATE_RECENTS_ACTIVITY enabled/disabled (simulating not being
the active Launcher). Also tested with a 3P Launcher, Nova.
Flag: N/A; this change is enabled by default, but also verified
UI looks correct with ENABLE_FLOATING_SEARCH_BAR.
Change-Id: Ia45f88d2c691c4525b1e73cca4707498d058a917
- The second start activity was causing issues with 3p launchers which
may not expect another new intent (ie. if it handles gestures at
the bottom of the screen). We can't completely remove this logic
because for button navigation we don't want to fall through to the
launch-next-task animation below, but we can can continue to
finish the recents animation immediately.
- With shell transitions, leashes for opening apps are always hidden
by default so when transitioning to a 3p launcher from
RecentsActivity we also need to show the surface if we want to
animate it in
Bug: 289609734
Test: Set 3p Launcher as default, in both gesture & button navigation
- Go from 3p home -> overview, then overview -> 3p home
- Go from app -> 3p home
- Go from app -> overview, then overview -> 3p home
- Quickswitch from app
Change-Id: I6875083931de63a8097d23d180553885ed7cfb01
Signed-off-by: Winson Chung <winsonc@google.com>
* In ag/23680185, a null check was removed that was
checking if individual mLastAppearedTaskTargets were null;
we check if the array overall is null, but individual
elements can also be null, ex 3P launcher
Bug: 289609734
Test: Repro steps from b/289609734 don't cause crash
Flag: none
Change-Id: Iddfde6d9ac2b708380b70b5fb6301b629506619c
Launching the gesture nav tutorial in portrait mode on tablets causes fragments with the wrong layout file to be inflated (uses the default phone layout).
Reinflating fragments whenever they need to be switched. Added a new rotation prompt fragment
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fixes: 291062054
Test: Launched the tutorial in portrait mode and landscape mode, then rotated the screen several times. tried with the flag disabled as well.
Change-Id: I0215d7589285007d04ef81d3a63e404c2cda3895
When the first bubble is added we set the visibility of the bubble bar
to VISIBLE if the stash controller is unstashed. The issue is that once
bubbles are gone we no longer update the stash state in the controller,
so it becomes stale and can't be used when the first bubble is added.
This change introduces a new method for handling the transition from
the state where both bar and handle are invisible into the state where
one of them becomes visible. We can't use the existing stashBubbleBar
and showBubbleBar methods because those transition from one to the other.
Using them when both are invisible results in one of them becoming visible
and then invisible again.
Fixes: 290992144
Fixes: 291074646
Test: Manual:
- Add bubble in the test app by double-tapping on a chat (non expanding notification)
- Observe that the handle becomes visible and the bar is invisible
- Dismiss bubble
- Add bubble in the test app by tapping on the button on the right (auto expanding)
- Observe that the bar becomes visible and expanded
Change-Id: I61334c67c255a6ed074fa8c834f4a5a1547539bf
This patch makes it so that Overview will return the correct GroupedTaskView even when the set of taskIds passed in is in the opposite order.
Previously, we didn't account for order variation when checking for a GroupedTaskView, which would cause bugs when the GroupedTaskView had had its ordering swapped.
Fixed by modifying getTaskViewByTaskIds() to return true even if the order of ids was swapped.
Fixes: 290135090
Test: Manual
Change-Id: I2d94fadfee3cd478801b25cdbc699295179c8bd1
Treehugger Robot
Luca Zuccarini
Bill Yi
Ats Jenk
Tracy Zhou
randypfohl
Tony Wickham
Schneider Victor-tulias
Greg Kaiser
Jagrut Desai
Andy Wickham
Vadim Tryshev
Stefan Andonian
Alex Chau
Winson Chung
Vinit Nayak
Brian Isganitis
Helen Cheuk
Fengjiang Li
Sunny Goyal
Liran Binyamin
Anushree Ganjam
Pat Manning
Jeremy Sim