Test: Sideload Google dev clock and verify the 5x5 widget preview is
rendered correctly.
Verify conversation widget preview is rendered correctly in the
full widgets picker and priority flow (aka pin widget flow).
Bug: 189975670
Change-Id: I4b0212ae347044c970ba40b9b33439448a6aa941
Also, scale down the preview size if it's wider than the target cell.
The intrinsic padding prevents the corners of the preview from being
rounded correctly and can lead to clipping or no rounding, especially at
larger sizes.
Bug: 187141692
Test: verified locally
Change-Id: Ie57ad57ba7c102330324bd0439acc55ff4fd83ff
Test: Check work profile badge no longer shown on work widget in the
full and bottom widgets pickers.
Bug: 177675123
Change-Id: I0e5e32e18df832c1919749404094d68805c30556
Test: Pin a conversation widget from a notification. RemoteViews are
rendered with the default size. Drag-n-drop from the pin widget
dialog works fine.
Bug: 185934141
Change-Id: Idb76cce2807e55e7b42e2e044712519857beb202
1. Before this CL, preview layouts are not rendered in both the
BottomWidgetSheet and SearchPopupSheet because the preview
width & height are not set correctly.
2. Also applies the right padding to preview layouts.
Bug: 185374336
Test: Drag-n-drop preview layout from the full widgets picker,
the bottom widgets picker and the search widgets picker.
Change-Id: I2b6303bfe4eb86a4935a5569f6107e9d46448902
The behavior of the framework when we try to do so is undefined. In our
case, it almost work, but no clipping is applied, which is a problem for
Android S (before that, widget couldn't use clipping in the first
place).
Instead of drawing the view through a drawable, this really add the view
and adds also a badge ImageView for badges instead of drawing them
indirectly.
Note that, temporarily, we have to re-allow drawing the view after it
has been attached, but the underlying framework bug being fixed, this
should be fine (I tested it and it really seems to be).
Bug: 183609936
Test: Using hand designed app (see bug)
Change-Id: I929ef8fc81c98c49406f2d940cd5efc28319886d
This applies to the widget picker and the initial Widget drop.
Bug: 183615331
Test: Manually using top preinstalled widgets
Change-Id: Ib7ce422dc485396c2aceec6f43e83529d642ecc7
Update the tapl test logic to scroll a smaller distance to avoid the
search bar blocking the target touch area.
Test: Open full widgets sheet and observe the widget recommendations
shown at the top.
Run AddConfigWidgetTest
Bug: 179797520
Change-Id: I6d53bbb46e2cb928ed7d015aaac604be17d33178
This is a preliminary work for local color extraction. In order to
apply local colors extracted from wallpaper to AppWidgetHostView
during drag, we need to hold a reference of the dragging
AppWidgetHostView.
In this CL, the following changes are made:
1. Instead of using bitmap image directly for icons, folders, shortcuts,
legacy widget drawable preview, a BitmapDrawable wrapper is
introduced.
2. Introduce a WidgetHostViewDraggableDrawable which draws
LauncherAppWidgetHostView directly to canvas. No more bitmap
generation overhead.
3. Remove drag outline from the drag logic because this will be replaced
by a new grid color hint UI: https://screenshot.googleplex.com/7jBEVeuxFecFKKT.png
Test: Add: add widgets, shortcuts from widgets tray.
add icons from all apps.
create folder.
Drag: drag existing widgets, shortcuts, folders and icons around
Bug: 182282587
Change-Id: Ia45ff756ea5bb80cf0761f0727a9453d50c204c0
The fixes are:
1. For widgets shown in TableRow, aligns them center vertically.
This is useful when widgets of different height are shown in
the same row.
2. Remove background color from WidgetCell
3. Re-enable swipe in FullWidgetsSheet
4. Use the WidgetCell image as the single & long press area because
1. Previews are now scaled to their default size. The touch area
should already be larger for widgets that are bigger than 2.4
cells
2. WidgetCells also render description. If the user long press the
description area, the drag view will not align in the middle of
the user touch / drag area.
Test: Drag-n-drop widgets from FullWidgetsSheet, BottomWidgetsSheet
and pin widget flow.
In FullWidgetsSheet, swipe left and right to switch work /
personal tab.
Video: https://drive.google.com/file/d/1Ur7PwF1a7iwGGRTZczfc0BSVu-Ta6-Vm/view?usp=sharing
Bug: 179797520
Change-Id: I6fe4bc88d1e1b35b1819d8d7f046105f5ed27043
Also fix a bug which LivePreviewCells are not used in full widgets
sheet.
Test: Temporarily replace the previewLayout with initialLayout
from the code. Then, open both the full and bottom widgets
sheet. Observe initial layout is rendered correctly for both
personal and work profile.
Screenshot: https://screenshot.googleplex.com/BgJycVjzeoU3PNf.png
Bug: 181061277
Change-Id: Id635ee778008b6f94009f50bf4373d3b0f545417
1. Show widget previews in their expected cell sizes.
2. Update the bottom picker to use a table layout rather than
a horizontal scrollbar.
3. Move the title and cell size description to the bottom of
the preview.
Test: Run AddConfigWidgetTest
Manually open full and bottom widgets picker and observe
widget previews.
Video: https://drive.google.com/file/d/1K8A8hK5B4FgPTsX3cb-Yt4a_VjI0pk-w/view?usp=sharing
Bug: 179797520
Change-Id: I938612cb2e2477ce4a3a2d6c8891a0a36fc0978c
=> Also fix the widget tray in these non-default grids, and the external shortcut addition flow. The layout was broken as it was scaling with the icon size. Instead keep it fixed which looks much better, similar to how we maintain all apps.
=> This also fixes a small jump when dragging shortcuts external to Launcher.
issue 154169001
Change-Id: Iad1e3859dd6fedccce9b5c6633e64426a4630c31
Before this CL, the cell had 3 announced actions:
1. Add to home screen (a custom action)
2. "Double-tap to activate" - performing this action instructed the user
to use action #3
3. "Double-tap and hold for long press" - starts dragging the widget.
Bug: 116018969
Test: Manual
Change-Id: Ie2378ccb13d182a2558f70f7250055bf86c5e5f6
> The widget panel is only inflated when needed
> Using the swipe up/down interaction for widgets tray
> Removing additional view wrappers from all-apps
> Widget tray is preserved across activity recreation
> Launcher no longer has WIDGET state, the actual code around
the states will be removed in a follow-up cl
Bug: 67678570
Bug: 67585158
Change-Id: Ia29a7c33ec81e6c53cc24e2906b7022b6f41755b
- Currently the system shortcuts are just widgets and app info
- As shortcuts, they live in ShortcutsItemView
- They are populated either as icons only (if there are deep
shortcuts) or as icons + text
- Widgets are disabled until binding them is complete (we request for
them to be bound on long-press now). We should revisit this.
Bug: 34940468
Change-Id: Ia51d002c3b3ede87658bdab57abfc3eeca1ed242
- Contains two rows, one for widgets, and one for "configurable
shortcuts" that have customization activities
- Extends AbstractFloatingView and uses VerticalPullDetector for
touch interactions
- No way to show this currently; will add options to popup in followup
Bug: 34940468
Change-Id: Iab62c2cb89428f91119c9c86f9db886496c321fd
On long pressing, the confirmation activity starts a system
drag-n-drop and focuses the launcher activity. We then drive
the launcher drag controller using the system drag event
Caveats:
> We use a transparent preview for system drag and drop and use
a view inside launcher for actual preview. This gives us better
control over various animations.
> The parameters for drag operation are passed to the Launcher
activity using the intent. Since onNewIntent and onDragEvent
come at different times and are not associated, a random uuid
is used as mime-type to match the drag event with intent params
> If the workspace is locked (eg, loader is running) the drag
operation is simply dropped. Will be imporved in follow up cls
Bug: 33584624
Change-Id: I0bb5b25b690f86b6af31a14e11beb669fcb3a281
Instead drawing badge in the view directly.
This will allow us to reuse the same preview when we do not want to draw
badges. This also simplified badging of shortcut config activities.
Change-Id: I9c07c33bf9c2b8ef81a00026b1d42587868c906f
Instead of using hard-coded variants of colors, use the theme color
that corresponds (colorAccent, colorPrimary, etc).
Updated:
- "Search for more apps" text
- App info drop target hover color
- PageIndicatorDots
- All apps & widget scroll bar & scroll popup colors
- All apps section text color
- widget picker background color
TODO:
- widget picker header color
BUG: 28625102
Change-Id: I74b543ff71b8caef8cd950c8183ac84c759cb4d5
This will enable an easier migration to the new M APIs for identifying
button presses from stylus / other tools.
Bug: 20430722
Change-Id: I41cfa6eff8d76bb83cf1bdaf6623ec1092ed554c
> Filtering the widget list and excluding widgets which dont fit the grid
> setting minSpans for the widget item when binding.
Bug: 22541314
Bug: 22559137
Change-Id: Ieda48b56c95bee0c7ec71dd691af7e23e2d43db6
b/21133230
> Synchronized block was creating a bottleneck for the AsyncTasks.
> Remove calls that doesn't need to be synchronized outside synchronized block.
> Also removed setAlpha call as after the bottleneck was removed,
Inefficient alpha view usage alert started popping up in traceview.
Due to less jankness, removing the fadein animation doesn't have any
visible effect.
Link to lock congestion visualization:
https://x20web.corp.google.com/~hyunyoungs/no_crawl/traceview/traceview_lockcontention.html
Result: gfx-avg-jank delta = "-1"
Change-Id: If12817df0730f346cdba7e2f38f232eb9a4336c0
This updates almost(*) all locations that use a long press listener to
also set a custom touch listener that recognizes the stylus button press
action.
The stylus button press action is: when a stylus touches a view while the
primary stylus button is pressed which may occur on a DOWN or MOVE event.
*The location this is *not* enabled for is: Longpress to enter "overview"
mode -- this isn't really a selection or drag n drop action; it is also
easy to accidentally do this while using the stylus gesture to drag n drop
items which is not an ideal interaction. Also not set for the "cling" that
demonstrates this.
Bug: 20430722
Change-Id: I9343f143261a7b4fada9afca28b8a11a60dbecca
-> Pulling out the parts of device profile which can (and need to be)
initialized and accessed without access to an Activity context,
ie. the invariant bits.
-> The invariant bits are stored in InvariantDeviceProfile which is
initialized statically from LauncherAppState.
-> The DeviceProfile contains the Activity context-dependent bits,
and we will create one of these for each Activity instance, and
this instance is accessed through the Launcher activity.
-> It's possible that we can continue to refactor this such that
all appropriate dimensions can be computed without an Activity
context (by only specifying orientation). This would be an
extension of this CL and allow us to know exactly how launcher
will look in both orientations from any context.
Sets the stage for some improvements around b/19514688
Change-Id: Ia7daccf14d8ca2b9cb340b8780b684769e9f1892
Steven Ng
Stevie Kideckel
Pierre Barbier de Reuille
Sunny Goyal
Adam Cohen
Samuel Fufa
vadimt
Tony Wickham
Jon Miranda
Andrew Sapperstein
Hyunyoung Song
Mady Mellor
Winson Chung
