- This refactoring ensures that LauncherStateTransition does not
do its own animation on the QSB, and that all animations to the
SearchDropTargetBar go through its own animators.
Bug: 22515084
Change-Id: Ia7d13c44d861eac7517076b52a9651a90911ed0a
> Removing createShortcut with userHandle, as shortcuts can only be
for the primary user.
Bug: 22070517
Change-Id: Ifc58a76d0f1e0ab8f1943b46588cc19dd88bdda1
- Fixing issue with fast scroller not fitting name width.
- Refactoring fast scrolling/scroll bar code out of base recycler view
- Adding animations to fast scroller to match design
- Smooth scrolling when jumping between app rows
- Fixing issue with fast scroller jumping when you first pick it up
- Fixing issue with wrong background paddings being used
Bug: 21874346
Bug: 22031923
Change-Id: I9f011b1f375751f437604b900e95a2942d3f4601
I assumed that they are non-null, but reportedly it was wrong.
This method can be invoked before the views are fully initialized.
Also hotseat can be null as far as I see setupViews(), therefore
null-check and 'importance stored' flag check should be done
separately.
Bug: 21779078
Change-Id: I3f17226f887c38adf2b1fb7ee2a016e00ffc0eb4
> Using callback insted of using a content observer
> Setting the listener in LauncherAppState to prevent resource leak
Change-Id: Id23a4d5c8812e86178997e536226e09ec3740f84
- Adding support for an external search bar that can be used
to search a container view. This adds a new interface
AllAppsSearchController which manages the external search
bar. Each controller will have its own search implementation
which means that we no longer need a common AppSearchManager
interface.
- Removing elevation controller as we no longer have a builtin
search bar in all apps
- Refactoring container view insets so that they behave
the same in all containers.
- Refactoring apps view to ensure that we only update the number
of columns with the available width
- Cleaning up LauncherCallbacks interface
Bug: 20127840
Bug: 21494973
Change-Id: I710b8e18196961d77d8a29f0c345531d480936fe
If reading the rotation setting without the multi-process flag, the
WallpaperPickerActivity usually picks up a cached value. Specifying the
multi-process flag during the read fixes this and the wallpaper picker
always has the correct rotation setting.
Change-Id: Ic3639f8cd694674e92c8940b753c6bc30486076d
Settings observer doesn't work if a setting is modified in another
process, hence we instead register a receiver which listens for a signal
from the settings process that the rotation preference has changed.
Change-Id: I570e3c67bb64a32347e84ca00a8ac31d9010eac3
> Using a single bitmap icon size
> Picking up appropriate density for satisfy the required icon size
> Fixing some icon size assumptions during icon animations
Bug: 19514688
Change-Id: Ia7a1d0d2c03a9d39ccc241fa4ae3eb8a0f374585
> The preloaded widget was being set in a different instance of
PendingAddWidgetInfo and was never getting used for animation.
bug: 20699153
Change-Id: Iaec13640e49c66993b4695e4a52dc3a3a2133fb2
> Make package-private and @Thunk all private methods and constructors accessed from inner classes.
Change-Id: Ie5913860a0c33e48e9bf68f9b5b1699f64c2f174
This CL adds a Settings activity along with the code needed to provide
a "Allow Rotation" setting to all phones and tablets. This setting is
set to false for phones and true for tablets. On changing the setting
from unlocked to locked, the launcher (and the Settings activity)
will get locked to the orientation the user was in when he disabled
"Allow Rotation". This is consistent with how the natural rotation
feature of Android works.
Change-Id: I8a1c59d1fa0bb9262530cad96e0a9bdbab0d9344
> This check was used for flushing the cache, but since the cache
is backed by a DB, this has no effect as same icons are loaded again
Change-Id: Ib7d8a8598c5d225d922e095c899dc11ad06f2b7a
- Renaming resources, dimens, etc to be more consistent
- Removing old AppsCustomize resources and other unused code
Change-Id: I15ce35e7cb7a9b9344fc7103963e4e4c9e45d89a
-> 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
Winson Chung
Hyunyoung Song
Adam Cohen
Sunny Goyal
Dave Hawkey
Jun Mukai
Rahul Chaturvedi