This is the first CL in a series of logging-related CLs. Upcoming CLs will
include using Commands (HOME_INTENT, BACK) and "tapping outside" of a container
logic.
Change-Id: I62f0a08c7a9d9fce0baa5c12c67e21f63ab16a7c
- Open animation: shortcuts reveal using modified circular reveal
(so that it reveals in the pill shape instead of a circle);
slight translation away from the original icon; scale icon and text.
- Hover animation: scale the shortcut pill and translate others away.
Bug: 28980830
Bug: 30127368
Change-Id: I8ed05c7a082f2c2a3f6c663da7259f6cd33e394f
b/28917826
b/29469966
b/29542376
- Move state transition to when the finger is lifted and not when
the view settles.
- Refactor the vertical pull detector to use bit operation to define
which direction scroll to allow.
- Fixed many issues regarding screen rotation
- Fixes issue where slowly sliding the all apps goes into overview mode
- Fixes issue where quick slide up leads to animation starting from middle
Change-Id: I2384a0fcc5550e17359a044ef506bcc66507da5f
b/28917826
- nav bar change to light when top of the all apps container
passes y mid point of the status bar
- apps search edit box change when top of the all apps passes
the bottom of nav bar
- Restrict pull up to work only if the ACTION_DOWN event started
from the hotseat.
- Landscape: reverted old padding and margin. Only the interaction
is different.
- Tuning of the motion spec
- Animation duration respects fling speed more agressively.
- and many more small bugs...
Change-Id: Icde4093c41eeab8c9c6d9dc8b7d57adc3b171349
b/28917826
- 2+ workspace page also slides up
- pull up touch interaction doesn't trigger only when yslop > xslop
- animation duration should be set independently when all apps button is used.
- workspace state is correctly set (drag and drop from the trays work)
- after lock screen, hotseat is positioned correctly
- Remove initial jump when sliding up
- Improved tuning on sliding
- Alpha value set differently on backbround and content of all apps
Still not fixed:
- Landscape
- Search edit text box styling
- All apps scroll bar
Change-Id: I817094b0f1ada5052ee604539459f556a99cadf1
> Renaming it to simply DropTargetBar
> Moving AppInfo to the top bar as well
> The workspace pages will extend to the top edge (minus some padding).
Since the QSB is no longer displayed on top of every page, there is
no reason to reserve the space.
> In spring-loaded mode, the workspace cell layout will scale enough
to make room for the drop target bar at the top
Change-Id: I2baf607310335dd576c9d9fcbb75ab708f47ac03
First phase implementation: dragging and animation interaction is implemented
namely in two classes. ScrollGestureDetector and AllAppsTransitionController.
FeatureFlag.LAUNCHER#_ALL_APPS_PULL_UP will be true for only AOSP and
not in the extending builds. This way, we can safely iterate without
turning it on the shipped ready version.
b/28917826
Change-Id: I0501309c0121880ffe0555f82d6ac5a145581bb1
This makes the pinch transition more consistent with other transitions.
One immediate benefit of this is that it updates adjacent overview
panels during pinch, regardless of whether they are completely visible.
Previously the adjacent panels' alphas weren't always reset to 0.
Specifically, if you made a small pinch from workspace, which
canceled and went back to workspace, adjacent pages retained a
slightly visible panel.
Bug: 27676309
Change-Id: I7e79fddec31cd649e0811e4524b9a9a501c627f9
Widget is loaded only when the user enters the overview mode and we keep
the list updated as long as the user is in the overview mode. Once the user
leaves the overview mode, we stop responding to widget updates
Bug: 26077457
Change-Id: I9e4904b8f1300bfe0d77e2bc5f59aa6963fad8d1
Because going to overview mode scales down the workspace, it was
thinking the touch was moving even though your finger was still. If
the "movement" was large enough, it was treated as a scroll, causing
jank. This was especially prevalent on tablets due to their size.
Bug: 25779718
Change-Id: Idb7833e0087bd24ca840f6afc451bf221f6bc047
There are 3 animations that 3 different transitions use; to prevent
future problems, let's put them all in one place. For instance,
ag/781127 added dispatchOnLauncherTransitionStepAnim() to the two
transitions that existed in burnaby-polish, but not to a third,
startAnimationToNewWorkspaceState(), that was added in master. If a
common method existed in polish, the new animation would have merged
into master automatically instead of forcing us to remember to add it.
Change-Id: I7775aaa43a08ae8b8241b0eeb77b6c84167c5ff0
Previously, it was only called at the start and end of the transition;
now it is called as the animation interpolates. Specifically, a dummy
ValueAnimator is played alongside the transition animation and calls
dispatchOnLauncherTransitionStep() as it goes.
One place where this is important is in Workspace, where
mTransitionProgress is used to determine things like whether the
workspace should accept a drop - hence the bug that caused apps dragged
from All Apps to vanish when dropped before the transition ended.
Bug: 24215358
Change-Id: I32cd633c53557305caf84e87c9a4d4f07eef2223
Previously, it assumed that the transition started from an overlay -
either all apps or the widget picker. But this isn't true, because
the transition is also used when transitioning between workspace
states such as from normal to overview. Properly handling this case is
critical for the workspace to correctly manage the transition. For
instance, it wasn't setting mIsSwitchingState to true, causing issues
such as invisible overview panels in landscape mode.
Change-Id: I9c06a345233d366669972359c58c3427a518e2b9
> Removing utility method for isAttachedToWindow
> Moving logic to calculate cell size from workspace to DeviceProfile
> Replacing some constants with xml resource variables
> Saving the item info using content values for better compatibility with other methods
Change-Id: Idd612633d97a6241cb31148df9466031374bd5a0