- Play the nav bar fade-out animation at the same time when the app
launching animation starts and make the fade-in animation ends at the
same time when app launching animation ends.
- To make the nav bar fade-in animation looks like it's attached to the
app, apply crop rect and translation that the app targets apply to the
nav target.
Bug: 181638132
Test: manual: click app icon on launcher to launch an activity and
observe the navigation bar animation.
Change-Id: If7e610eca5fccbb747a76c87335a600b018195a6
- ClearAllButton's width is 0 before it's laid out, making the calcualtion incorrect
Bug: 184570027
Test: Restart device or change screen size, ClearAllButton is in correct position
Change-Id: I2cefccbe18925cb3d9dac705b333400639b7049e
This reverts commit 17ba630cd9.
Reason for revert: For unknown reasons, the problem had fixed itself
Change-Id: Ifdf884a4ca0e3cd96d85da2725216fd34bfdcbe0
> Merging overview and all-apps scrims into a single View
> Decoupling TaskMenuView from taskView
Bug: 184676497
Test: Manual
Change-Id: I49f7249eaa2a800054385ab8e73a441d6a1b5e16
There was previously two different onTransitionCancelled(), one in
BaseActivityInterface and one in AnimationFactory. They are pretty
similar and the differences seem subtle and not necessary. In this
bug, the AnimationFactory version was going to mStartState instead
of StateManager#getRestState() (which is the same, unless mStartState
disables restore). Instead, always use the mActivityInterface
implemenation, which seems more robust.
Test: Open app A, open app B, quick switch from B to A, swipe home
during that transition, then touch nav region during home transtion;
ensure we don't goToState(BACKGROUND_APP) in the subsequent
onTransitionCanceled().
Fixes: 184583037
Change-Id: I315a5087b12413d88c3ccc1e3245a55a76a73e62
Explicitly use DeviceProfile#heightPx instead of getShiftRange(),
which might be less depending on AllAppsTransitionController
Test: swipe up from bottom on home, ensure workspace scales down
as the gesture goes all the way to the top of the screen
Change-Id: I9c2988d361c22d437c7eb9bea8ed715d06054c59
This regression is caused due to getExpectedHeight relying on view visibility state while AlphaUpdateListener.updateVisibility was reseting the views visibility.
Bug: 184211402
Test: local
Change-Id: Ib756f5eb8f6356a18a025626008b97fd7c77fec9
- Store the possible parallel animation to cancel/end in
AbsSwipeUpHandler#endRunningWindowAnim()
Test: 1. remove taskbar during transition, ensure cleaned up properly
2. open a second app during transition to home, ensure taskbar
maintains correct visibility
Bug: 182512211
Change-Id: I71a6b6ce624113d43ad5a599cb5cfec28a555310
- Remove obsolete visibleInsets hack and isDraggingItem() check
- Have TaskbarController determine whether taskbar is touchable,
rather than TaskbarContainerView.
- Disallow touches during transition to home (can potentially
improve this later)
Test: Swupe home, tap taskbar folder during transition, ensure
don't end up in broken state with the uninteractable folder open
Bug: 182512211
Change-Id: Id625ce8b9b876a8a1b450b7d6fb771540e23bc08
Update Clear All and Empty message to use primary color, not workspace
color, as they are drawn on floating background now, not wallpaper.
Bug: 184260454
Fixes: 184260454
Test: local build, flash and run
Change-Id: Ie8ef4b7ace3053c2068a27b7cbedbbb039fc36d8
This makes it more clear which taskbar view is expected for particular
code flows. Also makes it easier to set it to null in cleanup().
Test: call cleanup() while taskbarOnHome is invisible, ensure hotseat
icons go back to being visible
Bug: 182512211
Fixes: 183633496
Change-Id: I680a15582c8034a049b20e035b4d54f5ea5aee04
shawnlin
Alex Chau
Winson Chung
Sunny Goyal
TreeHugger Robot
Vadim Tryshev
Alex Johnston
Samuel Fufa
Tony Wickham
Zak Cohen
Becky Qiu