- Issue: The fast scroller currently does not follow the touch input
because fundamentally, the fixed scrollbar height and the mapping
of the scroll space to the scrollbar space is fundamentally incompatible.
- This CL changes the fast scroller to allow it to detach when the user
fast-scrolls, then re-attaches after the user scrolls the screen and
the current scroll position for the scrollbar picks up the thumb position.
- Since the scroll position and the fast scroller thumb is now detached,
we can change the distribution of the fast scroll letters to make it
independent of the rows for each section and instead uniformly distribute
it along the scrollbar, which allows for more stability.
- There are edge cases where this fails, especially when there are few
apps, which we can investigate further.
Bug: 20035978
Change-Id: I8322f862107e6f330deff692885233706564bffd
> Showing animation when folder is added
> Not showing animation while cling is visible
> Checking is loader completed from UI thread
> Running bind complete runnables when bind is completed
Bug: 21772992
Bug: 23181585
Change-Id: I50742850da8294a877478ce02b107a026f68b563
This is per an earlier CR comment "we should probably move all this code to its own package (launcher3.dragndrop) in a separate cl".
I'm not moving DragSource because it's referred from gsa code.
Bug: 22609426
Change-Id: Ia7204dab99c0c395c66b77143a2d60411153f5f3
> Only setting desired size on wallpaper change for pre kitkat
> Removing wallpaper change receiver from manifest
> Removing multi-process wallpaper shared prefs for kitkat+
Bug: 23353784
Change-Id: Iba72d32871ee50b75807e2284a73a691bcddc472
- Since move to default screen starts the scroller immediately, any delays in
handling onNewIntent and onHomeIntent in the callbacks will cause the scroller
to skip frames the next time it updates. This change will defer updating the
page to the default screen until after onNewIntent is called back (and all its
posted runnables).
Bug: 22929080
Change-Id: Ibab6106938721702d4da23faaca99039861e10dc
> Renaming Lmp to Lollipop
> Lollipop_MR1 instead of directly using 22
> Using M APIs directly instead of reflection
Change-Id: I10a307f46e3be15b3299f549a2fd7e0e215a6a1b
It’s unlikely, but still possible that something interesting will happen
during the 150 ms that DragWindows takes to slightly increase in size
before it gets hidden and replaced by the framework DND drag shadow.
This fix covers 2 possible events that can happen during that time:
1. The drag gets cancelled (for example because of an app uninstall).
Here, we eliminate a crash.
2. The user starts dragging the shadow. Before, this would start
scrolling the home page. Now, SystemDragDriver starts processing touch
events exactly as the InternalDragDriver would, until the growing
finishes. Afterwards, it switches to framework dragging.
Bug: 22609426
Change-Id: I73cc09fea45fcdcc6b75b13be1347da3e7c95509
* commit 'd21f9404da5c8cdc959b483a40876b02ced35e43':
Disabling auto restore of widgets. > Always show "Setup" button for a widget which has a config activity.
> Instead of resizing the rect for dragoutline in onDrow, store the resized rect itself
> Remove unnecessary inverse matrix calculation
Change-Id: If13c3c5aaecba5a1d3a4f5d39199ed82e9662c62
* commit 'd468ee90911bee4d83e119500b52df1984107411':
Reloading launcher whenever there is an external update to contentprovider, irrespective of the uri
If you click at the icon with mouse, then release without moving,
the framework won't generate DRAG_LOCATION events, and we'll assume
the the drag ended at (0,0) coordinate.
Fixing by updating coords at any event that has coordinates.
Bug: 22028725
Change-Id: I1872b479035e14aa9fece1532b05194fa86a4907
This fixes perhaps an old bug.
If we started an accessible drag for an only item on a page,
then uninstalled the app while dragging, the page was removed
without unsetting its accessibility delegate. Later, the system asks
the delegate to do something, but the drag is over, and some pointers
are null, so everything crashes.
Fixing this.
Bug: 22028725
Change-Id: I85adcd42ae896603634994e20a7790792f7e84b1
(cherry picked from commit de1e67c388)
We don't want to start a framework DND (with drop shadow etc.) in the accessibility mode.
Besides, framework DND fails to start and immediately cancels the DND operation
if it's started in the accessibility mode. Presumably, this happens because
the finger doesn't press the screen when this happens.
The right solution is not to instantiate a drag driver at all when an accessible
DND starts, which is what this CL does.
Bug: 22028725
Change-Id: Ic743ba3f8de037c15d4e70e3b7687cdd3518b2a3
This fixes perhaps an old bug.
If we started an accessible drag for an only item on a page,
then uninstalled the app while dragging, the page was removed
without unsetting its accessibility delegate. Later, the system asks
the delegate to do something, but the drag is over, and some pointers
are null, so everything crashes.
Fixing this.
Bug: 22028725
Change-Id: I85adcd42ae896603634994e20a7790792f7e84b1
Winson
Sunny Goyal
Vadim Tryshev