The OverviewCommandHelper conversion to kotlin introduced a bug when using 3-button-navigation to go to Overview when the animation is disabled. A NullPointerException happens in the AnimatorListenerAdapter implementation in OverviewCommandHelper when StateManager.goToState calls onAnimationEnd providing a null argument to a function that shouldn't allow a null value.
The abstract class AnimatorListenerAdapter implements AnimatorListener functions containing @NonNull Animator. However, AnimatorListenerAdapter overrides the interface functions without adding a @NonNull annotation in the arguments. In Java, this is allowed, causing only a warning. In Kotlin, due to the null safety nature, the compiler forces a null check for nullable types and doesn't allow the implementation of a @NonNull argument to become nullable.
To fix this issue we created a empty AnimatorSet to provide to onAnimationEnd instead of null.
For more context when @NonNull was added:
- The @NonNull annotation was added to fix b/206801689, however it was never updated for AnimatorListenerAdapterImproved Commit Message
Fix: 364860731
Bug: 352046797
Flag: EXEMPT bugfix
Test: Manual. Instructions in the bug.
Change-Id: I120af3d75e614581d6ac0f867a8c6f9419ee1bd3
Flag: NONE - abstraction with no logic changes.
Test: Built and ran locally, for launcher3 and third party launchers
Bug: 224595066
Change-Id: I9da15bdd649d3a20e98c6552bb9e9abaec72f97f
- Make the log permanaent behind a DEBUG flag
- Logs are currently enabled with b/279059025 marked as the related bug
Bug: 279059025
Flag: None
Test: Manual
Change-Id: I60a75d73d40d00e7d42292f3d42cc9dd8c9b0825
This means adding the search view to the drag layer, so it can
persist and animate across Launcher states (i.e. Home, All Apps,
Overview, Overview from App).
Some high level things:
- LauncherState now has a flag indicating if the floating
search bar should be visible, as well as a method indicating
how high it should rest when the keyboard is not showing. By
default the height is set negative if the flag is not present,
so the search bar will rest off screen in that state.
- LauncherState also has a new method indicating if the search
bar should show as a pill when not focused. Currently this is
done in phone portrait mode in all apps and overview.
- SearchUiManager now has a method for gestures to hint that
the search bar will be focused or unfocused soon, e.g. for
the app -> overview case, we hint that it will be focused
when crossing the threshold, and unfocused if retracting.
This allows the search bar to animate during the gesture
and take or release focus after the state change completes.
- AllAppsTransitionController lets the apps panel translate in
from the bottom of the screen, for example when coming from
an app and we don't want to pop it in halfway up the screen.
Instead it can slide in gracefully from behind the keyboard
and floating search bar.
- KeyboardInsetAnimationCallback can now notify listeners of
keyboard alpha changes during controlled animations. And
StateAnimationConfig has a new animation type to control
the keyboard alpha during the all apps transition.
- This new ANIM_ALL_APPS_KEYBOARD_FADE is used to pop the
keyboard in at the threshold for going from an app to all apps.
Note that its position moves linearly before this, so the
search bar starts moving up accordingly before the keyboard
alpha is non-0.
Fix: 266761289
Fix: 268845147
Fix: 267683921
Fix: 265849321
Fix: 266446733
Fix: 269301440
Bug: 275635606
Bug: 259619990
Bug: 261866704
Test: Manual with all the state transitions on phone and tablet
(also folding/unfolding foldable).
Flag: ENABLE_FLOATING_SEARCH_BAR, ENABLE_ALL_APPS_FROM_OVERVIEW
(latter just for the background app interpolator changes).
Change-Id: I6f06552e95747348a62260279626cf407bf145b0
This patch fixes a bug where the user could cause a crash by making a gesture during the Overview > OverviewSplitSelect animation.
Within Overview, the user is able to make an upward gesture from the bottom of screen to return to Home. However, if the gesture is very short, the user doesn't go back to Home and instead stays in Overview. Under normal situations this doesn't cause any problems. But if we are in the middle of an animation, the short gesture actually triggers an animation cancel followed by an immediate goToState() to the same state that it was already in. This causes problems with the OverviewSplitSelect transition because reset() is called in the middle, clearing important split select data and causing a crash.
Fixed by changing a conditional to detect if we are this type of situation, and allowing the animation to play out in these cases.
Fixes: 272793237
Test: Manual
Change-Id: I4426204b9c8fc55853cf7df31a336ccaee2f5885
This patch fixes a bug where a user could cause a crash by rotating the device in the middle of the split staging animation.
The bug arose because:
1) Normally, when you rotate the device, reapplyState() is called to refresh the UI. This reloads the state, cancels any animations that happen to be running at the time, and generally works fine in most cases.
2) When animations are canceled within Overview, we also call RecentsView#reset() to clean up loose ends and prevent bugs.
3) Unlike other states, the split select state is unique because it is a transient state that holds the user's choices temporarily. If that information was cleared -- by reset() -- before it loads, it will crash.
Fixed by creating a new function in SplitScreenSelectState, onStateReapplied(), that is called when a reload is occurring. It makes sure that animations do not get canceled by calling end() to accelerate them to completion before the reloading occurs.
Fixes: 249819567
Test: Manual
Change-Id: I70c4651bcb5df81edd25f6e58e21520ebb391d01
This CL fixes an issue where canceling any Launcher animation by entering Quick Switch would cause Overview to appear with all thumbnail tiles blank.
The issue occurred because we recently added a reset() to Overview that triggered on all state transition animation cancels. This fixed some issues, but introduced this bug.
Fixed by tailoring the reset() to only fire on animation cancels within BaseRecentsView and FallbackRecentsView.
Fixes: 246232494
Fixes: 243471493
Test: Manual
Change-Id: I175a22d52597a63e164a6f3b9353c62b199b0712
- Without the call, it's interpreted as a successful animation to the
listener even though it was canceled
Bug: 245829938
Test: Swipe to previous task, immediately after settling touch the
swipe area again
Change-Id: I531cbda0c2bc8168a312a14854a7a73fafd8f678
This commit fixes a bug where the user could cancel animations when transitioning between Launcher states, potentially resulting in a state where Overview elements (task thumbnails etc.) were wrongly hidden or invisible.
The bug occurred because functions such as createInitialSplitSelectAnimation() and createAtomicAnimation() did not carry out any cleanup upon animation failure. This resulted in RecentsView potentially being in a polluted state for the next launch.
Bug was fixed by adding cleanup routines to two onAnimationEnd listeners.
Fixes: 242715097
Test: Manual
Change-Id: I05415ecf515e247aa535e3ca8371e540c3189b01
- Avoid overriding interpolator in AllAppsTransitionController.setStateWithAnimation as it's no longer needed and it'll wrongly override interpolator for ANIM_ALL_APPS_FADE
- Override ANIM_ALL_APPS_FADE to FINAL_FRAME in QuickstepAtomicAnimationFactory for tap deadzone to dismiss animation, also added EMPHASIZED_ACCELERATE for the dismiss animation
- Tuned dismiss animation across form factors to 300ms
Fix: 220336617
Test: manual
Change-Id: I4b3e827b503dcb1dd39f0bd99d4c1dd5ffdba0f3
Context: there was a bug where you could get stuck in HintState if you
did the following (timing is critical):
1. Short swipe from nav region towards HintState, but not far enough or
fast enough to commit before letting go; this cancels the state
animation, returning towards Normal (but, crucially, StateManager
still has state set as Hint)
2. While previous animation is animating back to Normal, swipe up again,
but this time faster/farther to actually reach Hint; this time, the
animation does go towards Hint, but gets stuck there. The reason it
gets stuck is because StateManager thinks we're already in Hint from
step 1, so doesn't call onStateTransitionEnd(Hint) in step 2. Thus,
we never get QuickstepLauncher#onStateSetEnd(Hint), which is what we
rely on to return to Normal.
Fix is to have StateManager change its internal state to
mCurrentStableState (the state the transition started from) if the
animation is canceled. (Also need to keep that state if restarting the
animation, which AbstractStateChangeTouchController does in onDragEnd,
regardless of whether it ends up going to mFromState or mToState.)
Test: short swipe followed immediately by fast fling from nav region on home successfully goes to HintState and back to Normal
Fixes: 228276181
Change-Id: I2e3aeac06d482b57729416d5de55cc6ffc9df23c
Utilities.IS_RUNNING_IN_TEST_HARNESS is used as a condition
for logging in the background NexusLauncher where sDebugTracing is
not set.
Bug: 192018189
Test: presubmit
Change-Id: Ib08656a12c778b7bf968532e3ba899a03031fd7b
This allows the default flag to be 0 instead of PLAY_ANIMATION, and is
aligned with the existing SKIP_OVERVIEW and SKIP_DEPTH_CONTROLLER
flags.
Test: Navigate to various states, works as before
Bug: 175137718
Change-Id: I2af1792e7fbd5bca82afb225290fd6b545368dcf
- Remove PLAY_ATOMIC_OVERVIEW_SCALE and PLAY_ATOMIC_OVERVIEW_PEEK
- Remove complicated parallel atomic animation support from
AbstractStateChangeTouchController and subclasses
- Remove some code related to going between Overview <-> AllApps
Test: Swipe between states in all 3 navigation modes
Bug: 175137718
Change-Id: Ice314d46946c3a983cdc6ccf1a67effb5da9156e
Revert "Revert "Moving insets animation to StateHandler so that ..."
Revert submission 13823490-revert-13810332-insetcontroller-CLXXLCZAUM
Reason for revert: Fixed original error in ag/13823726
Reverted Changes:
Ie19a3fd90:Revert "Moving insets animation to StateHandler so...
I4eb33772a:Revert "Removing insets controller animation as pa...
Change-Id: I7fb395c51ea99081913bc99515257e98c0a32754
Revert "Moving insets animation to StateHandler so that it can b..."
Revert submission 13810332-insetcontroller
Reason for revert: QsbLayout#getEditText() return object is changed, but extended class HotseatQsbWidget wasn't updated.
https://android-build.googleplex.com/builds/submitted/7197042/aosp_crosshatch-userdebug/latest/view/logs/build_error.log
Reverted Changes:
If6a088d14:Removing insets controller animation as part of al...
I296415604:Moving insets animation to StateHandler so that it...
Change-Id: I4eb33772acd887d6e1d92a9ecde41cf1e0687896
This way we mark the the current state as NORMAL at the start of
the animation, and cancel it as part of other state transitions.
This allows us to interact with launcher (e.g. to go to all apps
or pull down the notification shade) during the animation.
Also use OverviewToHomeAnim from RecentsView#startHome() to
ensure the animation is consistent, e.g. doesn't fade out
RecentsView, scrolls to page 1, etc.
Bug: 144170434
Change-Id: I5348565b9e705d8ffba39818dde9efe82b16bb7a
This reverts commit f3bc797182.
Reason for revert: updating upstream, need to wait to cherry-pick until that's approved
Change-Id: I702286dba66fb4582ab682a5b0b8cd80ccebf346
For both NoButtonNavbarToOverviewTouchController and
NavBarToHomeTouchController:
- Have consistent resistance applied such that RecentsView scales
down and translates up slightly (but not as much as from an app)
- Have consistent animation to home if you fling to that state
rather than stay in overview. This is handled by a new class,
OverviewToHomeAnim, which consolidates logic from NBTHTC and
overrides some interpolators such that RecentsView doesn't fade
out or translate downwards during the animation (it just slides
off the screen while the home animation plays).
Also make overview actions not clickable when alpha == 0, so that
you can tap the hotseat/qsb during the transition from home to
overview.
Bug: 144170434
Change-Id: Ic291f285ff2f63c477633c48d4fadb23cf70c28a
This reverts commit a8c08584a7.
Reason for revert: "caused a regression with quick switch from home: if you start the gesture then swipe back to the left, it ends up launching the task anyway"
Change-Id: I8e12e2de46b6fc6a3faeb0336762da08080c61d6
With the second swipe, we never complete the swipe to Overview
NoButtonNavbarToOverviewTouchController#maybeSwipeInteractionToOverviewComplete
- mReachedOverview = true
- mDetector.isSettlingState = false
And then the second swipe starts the state transition to Hint but then
it never gets completed because:
1. The animation starts
2. Gets cancelled
3. Starts again
4. Finishes, but is not marked as success since the cancel in #2 was never
set back to false
Bug: 160759508
Change-Id: I8c3972e6209c3d5a4a0bdd9f9b7683de18105d57
- Don't play any state animation if animComponents == 0
- StaggeredWorkspaceAnim handles depth controller
Bug: 157596833
Change-Id: I6ae4c5da2e837c61b57349e708b7499af8e14aaa
Previosuly we had a different swipe handler for 3P Launcher which
started either recents or Launcher based on the initial interaction
(horizontal or vertical). This was primarily because we had to wait
for recents transition to finish before starting another activity
which could delay going to home.
Now we always start recents transition to recentsActivity. This allows
us to use the same swipe handling logic as QuickstepLauncher. Home
activity can be started while recents transition is running and can be
controlled using onTaskAppeared callback.
Bug: 156924169
Bug: 156398988
Bug: 156295255
Change-Id: Ib9f02e0281e8d674bde2f4a81eca5fc8a5962144
Also applying transform params in DeviceLockedInputConsumer directly
instead of going through AppWindowAnimationHelper
Bug: 156398988
Bug: 155816922
Change-Id: I791e1a9feb07c4fb787130f8d040a4f404faf734
Schneider Victor-Tulias
Jordan Silva
randypfohl
Alex Chau
Anushree Ganjam
Uwais Ashraf
Sunny Goyal
Andy Wickham
Jeremy Sim
Fengjiang Li
Pat Manning
Winson Chung
TreeHugger Robot
Tony Wickham
Jon Miranda
vadimt
Hyunyoung Song
Pasty Chang
