> 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
This avoids acquiring a lock for upating the sharedPrefs during onResume
as all the logic runs on a single thread.
Bug: 67305604
Change-Id: I1bbea382da9fafb403b4e9508f393f78db28478d
> 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
The intent extra is not always correct as the profile id can change during backup restore.
This allows us to use a consistant behavior everywhere.
Change-Id: I004bd244204ca91758b1d42488e1fc13b0ccb998
> Disabling Install shortcut broadcast for O and above
> Adding a preference to control automatic icon addition on homescreen
> Adding icons on homescreen for new installs based on the above preference
Bug: 32920609
Bug: 27967412
Change-Id: I92e5cb7c841fb445dc8bc058d975f212ee54f8d1
> This ensures that LauncherAppState is only accessed in the presence of
a valid context
Bug: 33032833
Change-Id: I955e5cb022f8bd6374681ae6c0720a2666d5b750
> Moving any icon cache access to background thread
> Updating Apps list to avoid loading icons for ignored apps
Bug: 21325319
Change-Id: Id72755100f1176ccfcc99249c5e02873cc249a13
> 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
> Moving isPackageEnabled to InstallShortcutReceiver
> Moving the deep shortcut map to the data model
> Removing appInfo.flags. Instead fetching the flags when needed
Change-Id: I654dd8acefa7b7d183b0419afbe112bef001d536
homescreen
A shortcut can be added by any app as INSTALL_SHORTCUT is a normal
level permission. But the intent is actually launched by the launcher
app which can have other permission as well.
> When adding a shortcut from the broadcast, verify that the intent does
not require any permission
> When adding a shortcut using the two-step drop process, verify that
the source app also has the permission to create such a shortcut
Bug: 30778130
Change-Id: I710a490d69019dc25709db5a97020c20d9325007
> When package gets unavailable or suspended, the disabled flag was getting
updated on the UI thread. This could lead to inconsistent model if launcher
activity didn't exist.
> Fixing: When unsuspending one work profile apps, all work profile apps get
unsuspended
Bug: 27673573,27673373,27403236
Change-Id: I7fde3f79c36204e73ca66ccf8431fa0f0cce3d08
The content provider is the first component started with the main process,
which makes it ideal for initiating LauncherAppState
Change-Id: I03db82a8949ad1376af53a0033592f421dbf0b15
> Not deleting icons from cache, which have not been restored yet
> Not checking if activity exists during DB migration. Missing
components are removed during loader anyway
> Backing up and restoring bitmaps even when iconType is resource.
This allows us to show a proper bitmap icon, until the correct
resource is available.
> Loading proper shortcutResource icon for promiseIcons
> Checking against promise intent when verifying duplicates
> A launcher App intent can contain EXTRA_PROFILE
Bug: 22094970
Change-Id: I982971338846733833ec133119393af0bea0eb08
> Use low res only for app shortcuts
> Running icon migration after restore
> Running icon migration again for all users
> Deduping shortcuts added from widget tray
Bug: 20945600
Change-Id: I3bb47545fdd9832510069026fbae8966d2311cc1
> Ensure icon cache never returns null icon
> Enabling install shortuct receiver only after workspace has finished binding
> Making all the model changes for package installs on worker thread and only
posting the updaes on the UI
> Making shortcut exists check on the loaded items and not on the DB
> Explicitely using worker thread for PckageInstallListener
> Removing backward compatibility support from PackageInstallerCompat
Change-Id: I9592771b9670c1c1c84c8208cae8dafa7b393e65
When the managed profile is created, a "Work" folder is created
and added to the homescreen. All work profile apps are added to this
folder and icons for subsequent installs (withing a fixed time frame)
are automatically added to this folder.
If this folder get deleted or the time-frame expires, icon for any new
install is placed on the homescreen.
Bug: 17410319
Change-Id: I49f4e437707d5eabe4eec85320765bf6ba7fde97
> Only deduping shortcuts for the primary user as custom shortcuts
for secondary users is not supported.
Change-Id: If129dee64a395602006ebb996d4b09b93b89084f
> Widget previews are saved in data dir instead of cache dir
> Expiring widget previews similar to IconCache
> Removed support for setting thread priorities
Bug: 19865031
Change-Id: Ib6033c2b1ff8ae61bba8762ca994ccd8217d3c75
Elimates 304 methods based on dex analysis
The java compiler generates sythetic accessor methods for all private
fields, methods and contructors accessed from inner classes. By marking them
package-private and @Thunk instead, sythentic accessor methods are no
longer needeed. These annotated elements should be treated as private.
Change-Id: Id0dc2c92733474250d8ff12fa793d3a8adeb1f26
- Moving the property to LauncherAppState
- The property is only read on dogfood builds.
The property can be set using setprop or /data/local.prop
Change-Id: I14c7354efb12edb93f97e81687a6f920cc634e9a
