- 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
- When launcher starts up, onCreate() triggers the launcher model loader
to start, which calls bindScreens() to add the workspace pages.
However, layout does not happen until the device is unlocked, which
means that even though the default screen index and children are there
the page scrolls are calculated incorrectly, and even in RTL, the
page scroll for the 0th screen is zero (it should be at the right
most edge of the workspace). This CL works around this by deferring
until the first layout after bindScreens() to unlock the wallpaper
offset from its default bounds. The workaround is only applied when
the launcher activity is first created.
Bug: 28795125
Change-Id: I33da0d7f934f5337d26e69f068f579a32897a837
- Ensure that we map the scroll offsets to the full wallpaper offset
range
- Default to either edge of the wallpaper (depending on RTL) to match
the default system wallpaper behavior (ag/1265418)
Bug: 28795125
Bug: 29398681
Change-Id: I36c316095057912d2dda0beb43bd1e6aaeac3fdc
