| Age | Commit message (Collapse) | Author |
|---|
|
* makes no sense
Change-Id: I8f2d6f835e92ea5de6ea64fb82b3f2b88348c8a2
|
|
Change-Id: Ib8d5dcc70d386376755c0a57b009ced1b2ee0834
|
|
Change-Id: Idc4d2622a4155854ff2762b2392a8d0f8cddb2c6
|
|
- Removed deviceTypeCompatible check and allow restore across for mfactors
- In AOSP default device_profile, mark 3x3, 4x4, and 5x5 as phone only. On tablets they'll reflow to 6x5.
Bug: 198575341
Bug: 210129187
Test: Only 3x3, 4x4 and 5x5 are enabled on phone
Test: Only 6x5 is enabled on tablet
Test: Phone backup of 4x4 get restored and reflow to 6x5 on tablet
Change-Id: I36a641d47fcee86ace0fea3d9194d61d12517f13
|
|
- Allow disabled grid to be used during restore
- Remove all inactive grid dbFiles to allow grid migration to happen
- Set the proper grid after restore to trigger migration
Bug: 202125760
Test: Restore a 2x2,3x3 grid, icons and widgets are migrated to 4x4 grid
Test: Restore a 4x4 grid, icons and widgetse stays in original position
Change-Id: Ie59e1ca0ca56ed2de52d88cd5f51b980788afa52
|
|
Due to the dogfood 4x5 grid using the wrong db, there may
be some rearranging of items.
The goal is to completely remove the old 4x4 and 4x5 grid,
but first we need to silently migrate users to the new grid.
We still need to keep the old grids in the device profile
so we hide them from the Styles & Wallpaper app.
We also need to reset and remove the ENABLE_FOUR_COLUMN feature
flag from the UI.
- Added TODO to remove this logic in the tracking doc
Bug: 183965808
Bug: 175329686
Test: have old 4x4 or 4x5 grid set up
install apk with these changes
confirm that we are now using the new grid and the
other grid options are inaccessible to the user
Change-Id: I81a91b8415effbe0bf7ba722f11ab44a4169e3df
|
|
We'll have a db for each grid option and a db for back up / restore.
TODO(pinyaoting): support back up / restore using the new infrastructure, particularly calls to GridBackupTable should use different DBs when the feature flag (NEW_GRID_MIGRATION_ALGORITHM) is on.
Bug: 144052802
Test: N/A
Change-Id: I644a3e70148bd78204a747a337446a3c038f616f
|
|
provider. This allows OEMs to keep the user's homescreen intact while
changing the default home app package.
Bug: 28536314
Change-Id: Ibebfd7dd33aa2cbd9ca28d2d611dd0a4a5971444
|
|
b/26494415
- Removed bundle object that became redundant now that we have LauncherEvent proto
- Combined Stats and UserEventLogger as they are effectively doing same thing
- Removed parent field inside Target
- added predictedRank target inside Target
b/27967359
- make com.android.launcher3.action.LAUNCH broadcast explicit
Later CL: finish packageName/intent/componentHash/predictedRank fields
Change-Id: I441fb46c834f73e58a4d2324e8da7971e8713ec8
|
|
Bug: 27778623
Change-Id: I28aa6698d3caa1fc11b2e8df0733143865f9b408
|
|
> Removing cross process preference file
> Removed broadcast listener management for settings changes
> Defining content provider method to get/set laucnehr preferences
Change-Id: Ida36eac0ab17c1d48fedc9404817a53a89b36c4f
|
|
|
|
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
|
|
> 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
|
|
> WallpaperPicker can still depend on launcher code, but not the
other way round.
Change-Id: I93a07f985c3955c638a68a5fad9c09b184a879b9
|
|
> We store some local logs which are never propagated to the
server and cause unnecessary file-io during app launch
Change-Id: I2b41c3af182de2a87f38ad88f3bae9d250574c26
|
|
> IconDB maintains a DB of icons keyed on ComponentName + User
> During loader, icons & labels are loaded first from the DB, and
if the entry doesn't exist, loaded using packageManager
> After the loader completes, IconDB updates any entry which might have
changed, while the launcher was dead.
Change-Id: I7a6021cb6d1ca1e66fa5a0bdd21e1543e0cf66fc
|
|
Bug: 12753154
Change-Id: I00679bdc6eff70a1398122aaa955c08eabd556b1
|
|
Replace hardcoded Launcher filenames with the defined constants.
Bug: 12753154
Change-Id: I072f202d9388a703b9e6851bde64ea7fafe4b10a
|
