This method recursively looks up the view hierarchy for a suitable view
to animate. The wrong variable was causing an infinite loop by never
updating the object being checked for the end condition.
With the fix, the animation behaves as expected.
Fix: 302568434
Flag: ENABLE_SEARCH_RESULT_LAUNCH_ANIMATION
Test: see video in the bug.
Change-Id: I123e50f1618a1e48256c0c976eeb46c93e8391b2
Merged-In: I123e50f1618a1e48256c0c976eeb46c93e8391b2
- adding more logs to TaskbarManager to investigate taskbar being present in folded state of the device.
Test: Presubmit
Bug: 254119092
Flag: not needed
Change-Id: I81c475f1c6bbc8d5b7874ddc45e8778861b61cd0
Previously [1] we removed the explicit insetsSizeOverride from the
Taskbar for the IME window, as we now [2] enable hiding the IME nav bar.
This would now send the normal insets the taskbar reports. When running
on pre/postsubmit, with test harness setup, the non-transient taskbar
would show, which is bigger than the IME's navigation bar height.
Due to the current logic in InsetsSource#calculateInsets, this leads to
the IME window receiving top navigation bar insets instead of bottom.
As the IME nav bar is now treated as a (fixed on bottom) caption bar,
the two would no longer overlap, and thus lead to a double insets
dispatch, and also a (temporarily) bigger IME window, for IMEs that set
their decorView height to WRAP_CONTENT (e.g. MockIME used in testing).
This instead keeps the previous insetsSizeOverride for IME, and uses the
stashedTasbarHeight when in gesture nav, which should account for both
transient and normal taskbars.
[1]: I86079cb6670a2ae3b6fa883694f8af81df212408
[2]: I8793db69fb846046300d5a56b3b0060138ef4cd5
Bug: 297000797
Test: atest WindowInsetsControllerTests#testDispatchApplyWindowInsetsCount_ime
Change-Id: I102a8bc1f8869ebbce9f8f1fefa651d49a9538ec
Test: can no longer repro incorrect orientation when launching apps from all apps
added logs to verify recents activity -> view were the same while rotating
turned off auto rotate and verified state matched
Bug: 288984663
Bug: 301024104
Change-Id: I7fc3b47bff0a99756aaf877bf634e2d162838d6f
Fixes: 300247322
Test: invoke omnient via long press nav handle
Flag: ENABLE_LONG_PRESS_NAV_HANDLE
Change-Id: I5d7cd1d0a2a50da26a881a6daa203806bf857909
Before this change, the configChange was processed when launcher becomes visible. However, this happened during animations (e.g. swipe to home after unfold to app).
With this change, the onConfigChange received by TIS (so, it's received also if the activity is not visible), is used to preload overview, moving a ~100ms block to unfold instead of during the animation.
Bug: 294352799
Test: recorded a perfetto trace and checked jank decrease
Change-Id: I35a7036887cc9ea490f27d5ccd47fe423775350b
Merged-In: I35a7036887cc9ea490f27d5ccd47fe423775350b
(cherry picked from commit 11ce5f85c9)
when result was null but getTaskbarUIController() is not null, we don't setPauseUIUpdate to false. This CL ensure we always end up setting pauseUIUpdate to false so that the hotseat suggested apps show up.
Fix: 295892343
Flag: no flag
Test: verify hotseat icons don't disappear
Change-Id: Id872f3174df276cb7a4ed7f6672523d0851a11dd
If we do the reverse, there is a change onAttach will occur before the
callback is registered and invokable (e.g. overlay window already exists
for EDU).
Test: Manual
Fix: 299335210
Flag: None
Change-Id: Ic4befe900c9582e1b01c2bc4699b431f95efa617
ActivityLaunchAnimator.Controller.fromView requires an instance of LaunchableView, however findViewWithBackground had no checks to return one. updated the check to make the exception less likely.
Flag: not needed
Fixes: 297564681
Test: ran launcher and launched apps
Change-Id: Iddbe55c1ff66b067f8456d058cbc60a2a698c4ae
Merged-In: Iddbe55c1ff66b067f8456d058cbc60a2a698c4ae
The lottie animation in the gesture nav tutorial wasn't scaling correctly for certain devices
leading to gaps around the animation. This change uses animation's scale transformation to ensure it fits the
dimensions of the device.
Flag: ENABLE_NEW_GESTURE_NAV_TUTORIAL
Fix: 295809541
Test: Went through the tutorial on different types of devices and ensure
the animation takes up the entire screen.
Change-Id: Iadee0d0389a11aa38c9e947b4b40466acd8f4422
Previously we set the corner radius just once when TaskView is
constructed, but this doesn't work when reusing the TaskView on a
different display that has a different corner radius.
Flag: none
Test: FullScreenDrawParamsTest
Test: kill launcher, open Overview on one display, then switch to
another display with different corner radii and ensure task radii
have updated while quick switching
Fixes: 293224095
Change-Id: I5f0697a4697400ec0e003c116774d74a945ee59e
It looks like from the stack trace that there is an NPE during the setApps() call. So adding nullable and null checking
to make sure mApps is not null.
bug: 296920692
test: presubmit
flag: n/a
Change-Id: If402c0b68db159f7a698e8e2e139d9bd5041b1c1
Previously, users used to be able to swipe down near the
bottom of the screen to leave overview. This was causing the taskbar to
animate to home while still in overview (and causing jank). Since this isn't expected behavior for
how to leave overview, this change removes that method.
Flag: N/A
Fix: 284416178
Test: Completed multiple transitions (ex. Overview to home) with 3
button nav and gesture nav. Ensured swiping down from below the recents
task does not go to the home screen while not affecting other
transitions.
Change-Id: I8cdfde71117dd947174d9c3c3a7f834fbeaddcca
finishRecentsAnimation calls cleanup immediately which removes all the
callbacks. This prevents any callback previousy added from getting
the cancelled callback.
Bug: 298069218
Test: Verified locally
Flag: N/A
Change-Id: I54b9a4529870d771f2eff8fd7cb6f2f376f9e112
* Previously the CUJ was ending after only the launcher side
animation was completing, before we actually made the
call into shell to launch the tasks
Test: Compiles (no baseline to test metrics/latency off of)
Bug: 285578568
Change-Id: I958e4a5265cb2fd81f2358343846385058b4465a
Gesture library has a threshold for 3-finger swipes, and if it's recoginized as one, it only reports movement in one axis. There is no point waiting for it to pass the initial threshold, unlike gestures on the screen.
Bug: 291771975
Test: swipe up slowly, observe the smoothness of the gesture nav animation.
Change-Id: I0904efb1d5cd26f6566da46279d0153e19a9618c
