Bug: 115891474
Test: make -j10 icon-loader
Next step: Launcher will depend on icon-loader in next CL
Change-Id: I797ddb857cf8be79f3be6ca2f174c593ca3713a5
> Items ids were already being typecasted to int when being bound on the UI
> Using a consistent type allow better use of platform data-structures
> Adding IntArray and IntSet as a replacement for various Collection classes
Change-Id: Id3c650ed2420c2bfca3bd7671d2b705b56112371
Bug: 115891474
Sending out the package name changing CL first before I make
LauncherIconsHandler and tests around it.
Change-Id: Ic10479a06333e1435b392a7072cd08782e710cbd
When launcher loads, it fetches the list of apps twice, once for
loading all-apps and again for updating icons. Instead reusing
the previously fetched apps list.
Also moving the icon loading in a separate package for further
generalization
Change-Id: Ibd2dae56e6027a31b633da030bc6b43a90b27e1b
Reset the restore status for auto install icons where the activity is
installed and enabled so the item is not stuck in the auto install
state.
Bug: 112664405
Test: manual - See issue
Change-Id: I37116b6e6ecbe4215d96627f9b1ea6909d12a6c0
Previously, if a developer renamed their launcher activity, we removed
all instances of their icon from the home screen, since technically the
activity they pointed to no longer exists. However, in the vast majority
of cases, the developer simply renamed their activity and nothing should
change from a user's perspective. So instead of removing icons that no
longer point to a valid activity, we now redirect them to point to the
first activity in the manifest (or remove them if there is none).
Test:
- Install app with Activity A and place on home screen
- Rename A to B and reinstall - verify home screen icon remains
- Add new launcher activity C - verify icons still go to B
- Force stop launcher and rename B to A - verify icons go to A (same activity)
- Remove activity A - verify icons go to C
- Remove activity C - verify icons are removed
Bug: 28907647
Change-Id: If9da251bd588908c4c425e7dd32e38fcbe54bab2
When a app is restored, it may not be in exactly the same state as it was when backed up.
Some components might be missing, and some shortcuts may be disabled or unavailable
Bug: 63525806
Change-Id: I09e6c0e9a9d2c1e8ccd73430f94bd065bdf2718e
> Calculating extracted color during icon generation and storing it in model and DB
> Removing unused logic avoid various types of badge rendering
> Icons are badged with extracted colors, while folder is badged with theme color
Bug: 35428783
Change-Id: I93e30c52fbded7515c3ae1778422e84672eafb56
> Removing Widgets and related states
> Fixing different durations being used when opening/closing all-apps
> Removing some unnecessary object allocations when changing state without animation
> Differentiating widget bootm sheel and full sheet in logs
Bug: 67678570
Change-Id: Ic169528736d04ee0b38564b4f96595ba066eabda
> LoadWorkspace can be called with a LoaderResult which does not bind anything.
> Synchronous bind does not look for a valid page id, and will fallback to the
current pageId similar to full load flow
Bug: 37616877
Change-Id: If14491dc79c5b85ae1019cc93e4e08759df3387d
Will move it to a separate file in a followup cl.
This simplifies dependencies between LauncherModel and LoaderTask which
and making it easier to start the loader before Launcher activity is
created (as the Callbacks in LauncherModel can change while loader is running).
Bug: 34112546
Bug: 37616877
Change-Id: Ie9619c6b0de0e3eb60657c04ae1b58d946c829e9
> Checking for duplicate icons before adding new icons
For O and above, icon addition is controlled using
SessionCommitReceiver.
As long as the Launcher is the default app, it will keep adding
icons on the homescreen. Apps installed while launcher was
not the default homescreen, no icons will be added.
For below O, icons are added based on package event. As long as
the Launcher process is running, it will keep adding icons on the
homescreen. Apps installed while the launcher app was dead, no
icons will be added.
Bug: 37528649
Bug: 37082950
Bug: 34112546
Change-Id: Ic99501fa476c00474a479f2a36c24614bfa3f4bf
> Sometimes a system app can be in disabled state. When the app is
enabled or disabled, the system sends onPackageChanged event instead
of onPackageAdded/onPackagesRemoved.
Bug: 36911898
Change-Id: Id82f70421b95b23f9891c8d4b0b7e0e1d4cddf7b
Before we were adding it in a disabled state, and then enabling it once
widgets were bound (if widgets existed for that app). Now we load all
widgets when launcher starts so that we can use the values for the
purpose of animating the popup container. Then, as the container opens,
we reload widgets/shortcuts for that particular app and add/remove the
widgets shortcut if necessary.
Bug: 34940468
Change-Id: I64bd009442d10d3d1f9a977bdedfdb639a7dd193
> Instead of checking promiseIntent != null, using isPromise() for consistency
> Fixing bug where clicking a pending icon does not launch anything
> Fixing bug where draging an icon on Info target, permanently hides the icon
Change-Id: Ic8f6b56042dba42d5ed9aedb0f5947186e1a4208
Providing a way to access icon cache without LauncherAcitivtiyInfo.
This allows fetching LauncherActivityInfo only when required, thus
avoiding system RPC when the icon is already in cache.
Change-Id: I92918c7a0d0d0796e5f7b70d4ecb6787c52c6600
> Making iconBitmap public instead of a getter (similar to AppInfo)
> Removing getIcon() which can lead to IO on UI thread
> Removing updateIcon and handling the update at the caller
Bug: 21325319
Change-Id: I6a49b9043f974e9629ea25e77012d97cc04c0594
