Otherwise the previous active controller will continue to handle touch
events even if it doesn't re-intercept future touches. For instance,
All Apps was handling the swipe gesture after DragLayer intercepted to
close a shortcuts container, which led to the weird behavior described
in the bug.
Bug: 30590854
Change-Id: I247b39b03d336a04659f6ce644380bf3cef8de3f
- Any change to the TextView text will cause mQuery to be set,
which will cause a new search next time refreshSearchResult
is called. We should also be checking there if it is a valid
search query before starting a new search.
Bug: 30606307
Change-Id: I08640c56199211f2aeea2386fcf699810853ab58
- Just skip the animation if we are animating to the same wallpaper
offset (which is the case when we are adding from all apps)
Bug: 28587903
Change-Id: Ib7b1828c1b099a665d68c22cb33ee62693f33f35
- Before we always started the close animation at 0 instead of
the previous open progress, which looked janky.
- Shortened the animations' durations and start delays to
account for the fact that the open animation was only
partially finished when the close animation started.
Bug: 30465231
Change-Id: I958ee5f4543dbf1185f3d0229c55fc1b51929655
- Log as long press with child type DEEPSHORTCUTS container
- Parent type can be one of WORKSPACE, HOTSEAT, FOLDER,
ALLAPPS, PREDICTION, or SEARCHRESULT.
Bug: 30537079
Change-Id: Ie62e4889ee06c845f959ca998781787a7fdaf00e
- We take the first 4 in sorted order, except we remove up to 2
static shortcuts to make room for dynamic ones if they exist.
- Added ShortcutFilterTest with testSortAndFilterShortcuts().
This asserts that the filtered list is sorted and has the
expected number of static and dynamic shortcuts based on
inputs with various amounts of each.
Bug: 28980830
Change-Id: I832b6b21144f17c74bb8b90a840d6620e99911b8
> LauncherApps returns empty list when the user is locked. Not relying on
LauncherApps in this case
> When the user is locked, removing all dynamic shortcuts
> Loading shortcuts from DB when the user is locked
> Verifying the shortcuts again when the user is available
Bug: 30411561
Change-Id: Ib6eb372c5b009cadb86a8f6e781f3f3cbf787ceb
b/29645452
By cancelling the runnable, we are enabling transition:
state1 -> state3 instead of state1-> state2-> state3.
Transition state1->state3 is a viable transition that is
supported by our model.
Launcher Workspace
--------------------------------------------
state1 APPS_SPRING_LOADED SPRING_LOADED
state2 WORKSPACE NORMAL
state3 APPS NORMAL_HIDDEN
Change-Id: If27905567efe439324494e0091a4b42fcbf01448
