The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Bug: 16840760
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
Before, the resize frame was created as soon as a widget was dropped,
but this caused it to be in the wrong spot after the spring loaded
mode exited. Instead, we should wait until the workspace is back to
normal before creating the resize frame.
Bug: 24192073
Change-Id: I8d87febcc4ec7e3c44d50135184c3a837d7cd960
1) Use a different content description for temporary new page
2) Use different accessibility description for add widget toast
3) Announce when an item is deleted
4) Announce when hovering over a drop target
5) Announce state during drag-n-drop and widget resize (similar to seekbar)
Bug: 23573321, 24057944
Change-Id: Icabb317625e70c78e11c0b4f99b9339172d93594
The navigation bar is opaque on mobile devices in landscape mode.
Launcher should ignore the right insets and draw the edge effect appropriately.
Also draw the black bar under the navigation bar, just in case we assume it
to be opaque, but it was not actually opaque.
Bug: 18526657
Change-Id: I1d49dcb82b8a5ee25009bc738cd9b8c0c5c88263
-> In some instances, onResume would incorrectly call onShow
-> When pressing Home from CustomContent, we'd get a sequence of onHide,
onShow, and then onHide due to some deferred actions in onNewIntent.
Got rid of the onShow.
issue 17629011
Change-Id: I9b4f2ef682f5a7060e68210866fa05452076e428
> Using ViewTreeObserver to listen for onDraw instead of overriding onDraw in workspace
> Loader passes the list of deferrerd runnables to launcher
Change-Id: Ie4877f746c96e9497396de8089f00f70bf867e17
It is a bit clunky and doesn't have the App Info drag bar at the
bottom yet, but it is a start.
Also removed page hints because they are no longer used.
Change-Id: I1f8f82d33e6694cab1f1c762e78852ac0d40ab33
- Also fixing case where the all apps button to search for more apps
was not focusable
Bug: 20639227
Change-Id: Ie4d9092e654d3cafc0eb346b3bb744ec3e295e92
- Routing the various places where we call through to delete from
LauncherModel through Launcher, which will delegate the removal
of the icon from the workspace, and properly handle the removal
of all items and their contents from the db.
Bug: 23944119
Change-Id: I022fe2b3e79da16b5af87505c4362490b8422686
Previously the search began with the page that the user
long-pressed to enter the overview, even if they then free-
scrolled to another page before selecting "Widgets."
Change-Id: Ie286f6864c78b573c05dd9d02c1346e17db711a6
The search for this page starts at the current one and
continues to the right (on LTR) until a page is found that
can accomodate the widget, taking possible resizing and
reordering into account.
Bug: 11338870
Change-Id: I2e9a310eb8f74024dca9150f55a525e1309c2f07
Previously there was a workaround to ensure that adjacent panels were visible
while in the overview or spring-loaded states, but it incorrectly kept only
those original pages visible even while the user scrolled to other pages. So now
we only use the workaround when first entering the overview or spring-loaded
states, and then fall back to the default getVisiblePages() implementation in
PageView when in free scoll mode.
Bug: 23766408
Change-Id: I692ec00b9cd6d7889c374aee41b85abd0a5d8d3c
When "Wallpapers" is selected from the overlay, the current wallpaper parallax
offset is sent to the WallpaperPickerActivity as an Intent extra. The CropView
then uses that offset when previewing new wallpapers to ensure the preview looks
exactly the same as the actual wallpaper will when set.
Note that this fix doesn't seem to work for DefaultWallpaperInfo - that will
come in a future CL.
Bug: 23568800
Change-Id: I41c5bbbfdabfeb4e20d77e9b5804842a03211edf
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
> 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