Previously we were using OnGlobalLayoutListener, which is only called
when AllAppsContainerView or a child is re-laid out or visibility
changes to or from GONE. Since we no longer relayout when already
scrolled to the top, we need a better hook to check whether all apps has
changed visibility for the purpose of updating predictions.
Bug: 140823188
Change-Id: I7c4a0d94c529eb86b55729c75843c8b0bd673d8c
value, refresh icon cache
Bug: 135638690
Bug: 138964490
Test: manually toggled feature flag UI on/off
$ adb shell device_config put launcher APP_SEARCH_IMPROVEMENTS [true|false]
when launcher is in foreground and also when it is in the background
Afterwards, saw if "bank" would show BofA app or not
Change-Id: I98b62bd07b14a225168217d7eb9bfdfc7f74435d
- For app open, the icon text remains where it is and only the icon moves.
- Similarly for app close, the icon text remains where it is and fades in
with the rest of the other icons text.
- With this change, the original view is always "VISIBLE"
(if BubbleTextView/FolderIcon) but we hide certain elements.
Added video to bug.
Bug: 137200188
Bug: 139885365
Change-Id: I3d20c5f05bc7c0b9d052d8074ac3bfc21531c83d
Merged-In: I3d20c5f05bc7c0b9d052d8074ac3bfc21531c83d
Calling scrollToPosition on RecyclerView internally calls
requestLayout() (to cacluate where to scroll and then go there).
Therefore, we should avoid calling that whenever possible, especially
during transitions. In particular, we can optimize scrollToTop() to not
scrollToPosition() if we are already at the top.
This makes some other workarounds unnecessary, namely setting All Apps
to GONE during system gestures.
Test: Open an app, swipe up, ensure AllAppsRecyclerView doesn't get
onLayout(). If we had scrolled to an app first, we get one layout
in prepareRecentsUi(), but not during the transition.
Bug: 140308849
Change-Id: I62ee341bf5893c121cfc013cc6542559f79d2a42
We already set the all apps content visibility = GONE at the start of
the gesture to prevent relayouts, but when animating home we were
inadvertently changing it to INVISIBLE, causing a relayout and jank.
Bug: 140308849
Change-Id: I285746f8ac8f3f857282e22ebec8eebd0b98647f
Test: manual
Bug: 137777105
Log result for swiping in and out of -1 screen.
data {
elapsed_timestamp_nanos: 597609736235111
atom {
launcher_event {
action: SWIPE_LEFT
src_state: HOME
dst_state: HOME
is_swipe_up_enabled: true
}
}
}
data {
elapsed_timestamp_nanos: 597610569783111
atom {
launcher_event {
action: SWIPE_RIGHT
src_state: HOME
dst_state: HOME
is_swipe_up_enabled: true
}
}
}
Change-Id: Ic84d3c32d1c9f780f13ec5cd6320e9f1d610f018
Bug: 138964490
TL;DR;; need this to be part of QQ1 or QD1 to verify if DeviceConfig
can be supported for launcher toggleableFlags.
Not handled in this CL:
- When flag is locally modified, that will override the flag value
How that scenario is handled should be discussed separately and is not
within scope of this CL.
Change-Id: I2e6694a40bee9202ed0b0d559e3b5607634071bf
It was possible to invoke the assistant accidentally. This change
adds a minimum distance threshold before we register a fling (the
same distance as used for drag, 55dp).
Bug: 137106918
Test: manual; tested that accidental flings were much more difficult,
but intentional invocations were still easy to register
Change-Id: I40c8bd43c1a28c7b161467804a1e44746b8e92ef
Before starting split screen animation, we dismiss the task view, which
can detach the clicked view immediately, if animations are dissabled.
That will cause NPE as view.getDisplay will be null
Bug: 138793362
Change-Id: I611f6a824f756eceeed57aac5afdf38f421ff8d2
The janky animation that ends on the home screen with an invisible
task on top is caused by the following scenario (for example):
- Quick switch from task A to task B
- After landing on B, but before we get the callback that it was
successfully launched, switch back to A (or you could go to C)
Now we are animating back to A, but we are still waiting to hear
whether B was successfully launched. If we hear that the launch
was indeed successful, we dutifully clean up after ourselves by
returning launcher to its default state. Unfortunately, that
clobbers the current animation that is scrolling back to A, and
we end up in the bad state where we are showing the default
launcher state even though we just launched task B and were
about to launch task A.
Normally we avoid cleaning up the state animation if the user
is still controlling it. The reason we weren't doing that here
is because we ended the launcher animation early even though
the window animation was still running. Instead, we should keep
the launcher animation running for the full duration, so that
it prevents a cleanup from occurring in the middle.
Bug: 138620399
Change-Id: I959e62a52638a5b974ef9b406555078c928b91f1
Now floating headers get 2 interpolators: one for the header content
itselt, and one for the all apps content that follows. That way, they
can choose to intperolate part of their content as if it were part of
all apps instead of the header. Currently, we do this to animate
predicted icons quickly, followed by the all apps icons, predictions
text, all apps scrollbar, and all apps divider as you continue swiping.
Bug: 132455160
Change-Id: Ib3e373c291e174e1306a53854d0ad4dc29eb4b76
- Refactor some basic scrim logic to Scrim class and have
WorkspaceAndHotseatScrim and OverviewScrim extend it
- Draw OverviewScrim under recents unless predictions are disabled, in
which case draw it under hotseat (since that is in recents)
- Remove sysui scrim (behind status bar and nav bar) when overview is
peeking
Bug: 132455160
Change-Id: Ia5d6f54582a4c5a70e3b2d4a98281567edd68519
Tony Wickham
TreeHugger Robot
Hyunyoung Song
Sunny Goyal
Miranda Kephart
vadimt
Jon Miranda
Andy Wickham
Becky Qiu
Felipe Leme
Pinyao Ting
James O'Leary
Tracy Zhou
