Although the recovery logic for app shortcuts and deep shortcuts are
mostly the same, in deepshortcut's case we don't care about the
component name. This CL fixes the bug where we reset the intent if the
activity a deepshortcut points to is not found. resetting the intent is
problematic as we'll need the shortcut id (which is stored as an
extra on the intent) to recover the deep shortcut using pinned shortcuts.
Bug: 140819317
Change-Id: I22f0266b98a9f6175303cc92a85397e240443250
Broken by change I03c31bb308fc496b9fc633c2fde23ae4568f8c44.
Bug: 139281702
Test: Ran BindWidgetTest with 8/8 successful.
Change-Id: I6a03744c9cd919316ff27b12c50acc70c91d47fa
This reverts commit f3d58f1f84.
Reason for revert: Rolling forward for development and fixes.
Bug: 140242324
Change-Id: I954cface2e50a5a9a5e143d2ea29fbcebb298ede
This reverts commit 050f9b1279.
Reason for revert: Test failure on ub-launcher3-master (b/140998509)
Possible Root Cause: This happens when fallback image or default icon was
used for shortcut icon, but shortcut caching logic do not have the logic
to create either fallback image or default icon. So upon updating icon cache,
the icon remains to be null, causing an NPE.
Change-Id: I1ee3bb7a3cab2af5730c2ee77d9370c1578a9ad6
Deep shortcuts now supports icon cache.
When workspace is being loaded, we will now attempt to load deep
shortcuts from memcache/db.
The icon for deep shortcuts loaded in the workspace is saved to
memcache/db after the workspace is loaded.
Bug: 140242324
Change-Id: I49da8319ad203476fe1e45683e2848dbde3473f2
> Moving grid calcutation in a separate class
> Moving content saving logic to folder instead of relying on item bind
Bug: 139051851
Change-Id: I81b226dbebe13652482a767c992e8cc8f4f35a60
- We update the ranks of all folder items after loading, to ensure there are
no gaps caused by removed folder items. This also ensures that we load
the high resolution icons for all preview items.
- FolderIconPreviewVerifier#setFolderInfo was not always called
- Init mGridSize with [1, 1] to prevent divide by zero error in case
setFolderInfo is not called
Bug: 126268196
Change-Id: I856489968665a39303e2922c78cf90f2b3ee6ebb
Instead of maintaining a workspace screen array, calculating it from
the current set of items as needed.
Bug: 122262946
Bug: 119500058
Change-Id: I85bb0e55a4442ab9bcac390a601da0cb2583c26a
Removing a separate table for workspace screens. List of screens are
automatically parsed using the items in the favorites DB. Order of the
screen based on the screen id and rearranging screens is no longer
supported. In case the screens need to be rearranged, all the items
in the favorites db will need to be updated with new screen ids.
This makes backing up the DB (in the same database) easier as only
one table needs to be duplicates.
Change-Id: I8ba947a898f637d780e2f49925e78604263126e8
> Avoiding color extraction for icons which have already be evaluated
> Fixing color extraction from hardware bitmaps
Bug: 111343544
Change-Id: I624866e892465684871fbc130003e32945d86460
Change to only keep the per Activity shortcut count in memory, not
the list of ids.
The full shortcuts are loaded at long press time so saves memory.
Bug:117239104
Test:Manual and ran instrumentation tests
Change-Id: Iee974ecba2c977216be4f078396ceed22b931f5d
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
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
