There was a race condition that caused the new color to not be
applied. For example, here's how the hotseat would become transparent:
1 Launcher is loaded for the first time; as such, there is not yet a
color defined for the hotseat, so we start animating to the provided
default (Color.TRANSPARENT). Meanwhile we start the color extraction.
2 When the color extraction finishes, we set the hotseat to the new
color. However, if launcher is paused at the time (perhaps some
retail mode content is showing), then we don't animate the change.
3 If 2 happens before the animation in 1 is complete, the color from
2 will be overriden by subsequent animation frames and thus the
hotseat remains transparent until the wallpaper changes.
Bug: 30956221
Change-Id: Iddf72379b0162f1b32883ad26ce267473e172849
> Allow touch events on hotseat while in accessible drag as drag now
happens in spring loaded state.
> Allow drop target buttons to ignore thershold check when in
accessibility drag
Bug: 30900444
Change-Id: I88274367983fc027b2ddde3a719ca943f4f48587
> Pending widgets whill show a loading progress while the app
is being installed.
> Extra bind options can be defined using the tub tags
<extra key="key-name" value="key-value" />
These are sent as widget options when the widget is bound.
> If the widget has any config activity, it is not shown
> Required attributes:
className, packageName, x, y, spanY, spanY & screen
Bug: 30279609
Change-Id: I1338618bfa5d86967339dffb68c12b1add6eb5d7
Before, everything is set to APP_ICON
With this changed, pinned shortcuts are set to DEEPSHORTCUT
Change-Id: I3e17de63f58693525236290ef5cb1f909f1d6098
(cherry picked from commit 8ce6063c4a)
When touching down within the drag handle's bounds, we remove the
onClickListener temporarily (restored when touching down outside
of the drag handle's bounds). Long clicks still start the drag.
Also increased drag threshold from 12dp to 16dp.
Bug: 30816665
Change-Id: I0b33dc34bf95c0532376f2f7cf50865fa50093de
This will allow drag controller to optinally defer drag, based on some
threshold, by simply deferring the callback onDragStart
Change-Id: I17c06a15e2092b9797c7e57529b12a53d2acae6e
This makes the logic for accessing various properties consistant and
and ties it to the UI of the DeepShortcutView.
Bug: 30817556
Change-Id: I09536b9f91b2a9969fcc286f83dd2b17e16cd9ce
- We only want to log when the container is opened and potentially
used, not when a long press is followed by a drag-and-drop.
- Also cleaned up code that was determining the container of the
app icon, since LaunchSourceProvider.fillInLaunchSourceData()
can do that instead (it's more robust and consistent).
Bug: 30791570
Change-Id: I05b6750f26182fda8a9940ac66f1371c2d228ca9
> Check for permission on every onResume
> If the permission is different than last known permission,
reload and rebind workspace.
Bug: 30789422
Change-Id: Idfa445815e29e2336505779545507d106b33a253
mBgDeepShortcutMap is only accessed on the background thread. But
the same instance of list of values was getting passed to the UI
thread, instead of being cloned.
Change-Id: Ie7d0442d895304489ce9323ea872b9091d668ae5
This change makes the padding consistent regardless of where the app
is (e.g. folder vs workspace vs all apps) by ignoring the app's
padding and adding our own to the shortcuts container.
Also note that this padding is relative to the icon, excluding the
text beneath it. So we also hide the text when the container opens
downwards, and re-show it when the container closes.
Bug: 30604007
Change-Id: I6e51c4983a8b5d495833f86e483ebaa229ed2099
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
Hyunyoung Song
Sunny Goyal
Tony Wickham