This reverts commit 9ef41413e0.
Reason for revert: This was the only launcher CL during the time b/280669657 and 280680602 occurred
Change-Id: Id7107f0935f84908ca87e1ae4c62ab05efe41a24
Migrating some of the class to use the controller directly, will
update the remaining calls in follow up cls
Bug: 277345535
Test: Presubmit
Change-Id: I8edc7c43665f94702ac64bd92932d6c94cb544a4
ENABLE_DATABASE_RESTORE feature is already removed
Also migrating some tests from BackupRestoreTest to RestoreDbTaskTest
Bug: 270392706
Test: Presubmit
Flag: N/A
Change-Id: I71822bbc2232008b3d2b4b9fbed0db5d889591e4
All existing legacy shortcuts will be migrated one-time to deep shortcuts
This shortcuts are pinned under the Launcher package, with custom badging
Bug: 275875209
Test: Updated unit tests
Flag: N/A
Change-Id: I7da001f724776ad8d6c807517b7e4e259de626c2
when using AutoInstalls or when restoring, and when work telephony is
enabled.
Test: atest RestoreDbTaskTest
Bug: 258631628
Change-Id: I3e699e5c34c09daf60e29724eda04282493673e7
LauncherPrefs will contain Launcher's shared preference functionality.
It controls optimizations and classifications such as restorable vs
non-restorable data, bootaware vs non-bootaware data, and configurations
such as default values so the calling code doesn't need to and our code
base can have a single source of truth for items that are used in
multiple places.
The old APIs remain in place, but are deprecated and will be removed
after all Shared Preference usage has been gated by LauncherPrefs in
future CLs.
Bug: 261635315
Test: Manually tested themed icon, Workspace configuration, and app
install functionality.
Change-Id: I29fd516468bc93fda393062e95be26b6d55c816e
Fix: 235358918
Test: Manual
1. Rebooted the device and verified that widgets are still updating properly
2. Changed the theme from dark to daylight, then from daylight back to dark and verified that widgets are working
3. Kept the device on for several days and verified that widgets are still updating
4. Turn on auto-rotate for the launcher, open any app then exit, verified that widgets will not vanish and reappear
5. Add & remove widgets from the screen, added widgets are still updating
Change-Id: I98ee902f7d16b47bd77626201a4fefc897ba17a0
- In reinitializeAfterRestore, use db path instead of grid name to check if migration is necessary, so migration will still happen if grid names are renamed. Also, only remove the target db path instead of all non source db paths, which are not necessary to be removed.
- In LauncherBackupAgent, remove old files before restoring to avoid old files from overriding restored files e.g. grid name in shared preferences
- Make sure InvariantDeviceProfile is intialize before we set pending to false, so unsupported grids can still be initialized and then be migratead
- Renamed 6x5 grid so it no longer collides with 4x4
Fix: 218500583
Test: Restore backup from supported and unsupported grids
Change-Id: Ic78e0bc7dc44ad86bd217c736b88708ad488ac0b
- 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
- Introduced device_category to allow grids to be only enabled for certain device types. By default grids are enabled for all device types, so old OEM device_profiles aren't affected
- Removed device_profiles_split.xml as a result and merged with device_profiles.xml
- Added deviceType in InvariantDeviceProfile to replace isSplitDisplay and centralize the logic
- Only has 6x5 grid with new default layout that works better for tablets
Bug: 198575341
Test: manual
Change-Id: I03f6727ce837ffeee6321b6d7c53942338d0cf30
- In RestoreDbTask.sanitizeDb, add extra step to fill all screenIds gaps so that no empty pages are left in between
e.g. [0, 3, 4, 6, 7] -> [0, 1, 2, 3, 4]
Fix: 201085524
Test: RestoreDbTaskTest
Change-Id: If0b577bf789347cc490ada0b22f2cd39ee1a33bb
- 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
Split InvariantDeviceProfile#numHotseatIcons into two variables:
numDatabaseHotseatIcons and numShownHotseatIcons. These are generally
the same, but different DisplayOptions within the same GridOption
can choose to show different numbers of hotseat icons while sharing
the same database.
numDatabaseHotseatIcons is used for all reading/writing/migrating
purposes, while numShownHotseatIcons determines how many Hotseat
icons to show in the UI.
Test: Existing tests pass, added two new migration tests
Bug: 184789479
Bug: 171917176
Change-Id: I54583504f61a47a4444b6a637ebb7e3ab31528b7
1. Instead of debouncing launcher restore when new install session
(triggered by Play Service due to restore) is created, it is now
throttled at once every 30 seconds. (i.e. Launcher restore is triggered
immediately, but cannot be triggered again within 30 seconds)
2. Removes the backup table when all items are restored. (i.e. no item
were removed as a result of sanitize db due to user didn't sign in to
their work profile)
Bug: 153648870
Change-Id: I32df371f8b47c60a72515876217fd83ac1e56f0a
Test: manually verified with deferred restore
The focus of ag/10346770 is around the actual algorithm, while in the meantime our preview logic has changed during the code review of ag/10100264.
GridSizeMigrationTaskV2 addresses both cases, the difference being preview passes in constructed IDP while actual migration uses IDP from the current Context.
When doing actual migration, we call METHOD_UPDATE_CURRENT_OPEN_HELPER to update the current db helper and copy the favorites table from the previous db into the current db in favorites_tmp table. Then we do migration from there.
When calculating preview, I added METHOD_PREP_FOR_PREVIEW in this change to copy the favorites table from the intended grid setting to the current grid setting in favorites_preview table. Then we calculate migration from the current favorites table to favorites_preview table and save into favorites_preview table.
Bug: 144052802
Fixes: 144052839
Test: Manual
Change-Id: I64a8b61a4e0bf8399c0ae1af4ef9d2bde0f1ee2f
go/grid-migration-v2
When changing grid from option 1 to option 2, we calculate the diff and add the icons that are in option 1 but not option 2, to option 2's workspace, according to the reading order.
Test: manual and unit tests
Fixes: 144052802
Change-Id: Id01f69e90ce656a9b7c9051fed499807ee9ac0f7
go/grid-migration-preview
With this change, we can see actual grid migration in wallpaper preview.
The approach here: we use a tmp table (favorites_preview) here specifically for this preview (to write off the migration results), and load from this tmp table workspace items if migration is necessary and successful. Otherwise, we load from the current workspace.
UPDATED: this change should be completely compatible with the new multi-db grid migration algorithm. Here is why
1. In LauncherPreviewRender#renderScreenShot, I added a check to decide which grid migration preview method we should call. Once v2 preview method is implemented, it should be integrated with other parts of this change perfectly (the reason will be mentioned below).
2. While we have multiple DBs, mOpenHelper in LauncherProvider always points to the current db we are using. Queries using CONTENT_URI is routed to whatever DB mOpenHelper points to, so it works perfectly to directly operate on CONTENT_URI even when we use multi-db underneath the hood.
3. With 1 and 2 mentioned, I believe in order for this preview change to support multi-db, we only need to implement the V2 grid migration algorithm. Because most of what we are doing in this change is wrapped in GridSizeMigrationTask, it's perfectly safeguarded.
Bug: 144052839
Change-Id: Ie6d6048d77326f96546c8a180a7cd8f15b47e4c4
Removed the code to handle table copying across dbs. We don't really need this since per ag/10298497, we can just copy db files directly.
Bug: 149236106
Test: N/A
Change-Id: I90bd7b6779fcaa841c71f5d0f27ec91907f926fc
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
1. Create feature flag for new backup & restore flow.
2. For each restore session (install reason is restore),
if its creation time is newer than the one we have in
SharedPreference, we update the entry and restores
favorite table from backup.
3. The restore operation is debounced so that when
multiple restore session is created within a small
amount of time, only the last invocation will get
executed.
Bug: 141472083
Change-Id: I7b5b63ec28741ba2b02ccfd13f591c961362ba36
Test:
1. apply on master, build & flash on physical device.
2. factory reset the device.
3. go through SuW, perform restore, exit without
adding work profile.
4. settings -> account -> add work profile account.
5. finish work profile setup, verify work profiles
is restored as well.
(see go/play-launcher-plan-launcher-implementation)
1. When Launcher launches for the first time, creates a backup
of the workspace before sanitizing db entries.
2. Creates a new path in LauncherProvider that triggers workspace
restore using last stable db entry of the same grid size.
3. When restore from backup created this way, the table will be
sanitized afterward.
Test:
1. apply on master, build & refresh on physical device
2. factory reset, go through SuW and perform restore
3. exit SuW without signing into Work Profile
4. run following commands in console
adb root
adb remount
adb pull
/data/data/com.google.android.apps.nexuslauncher/databases/launcher.db
sqlite3 ./launcher.db
.tables
SELECT * FROM favorites_bakup;
Bug: 141472083
Change-Id: I8032866a97eb333946d4f62352595d180364126b
sanitization.
Bug: 147114476
Change-Id: I34459267cfacb168ec520856e90e5da0b83728f0
Test:
1. follow the verification step in ag/9891836
2. add the following line in Launcher#onResume
LauncherSettings.Settings.call(getContentResolver(),
LauncherSettings.Settings.METHOD_RESTORE_BACKUP_TABLE);
3. build & flash on the device
4. verify sanitizeDb success without error message
> Changing the lifecycle to follow other static objects in Launcher
> Removing compat interface and inlining everything to helpers
Bug: 141376165
Change-Id: I82bd5db1969101de9a7eac77f32728d70195bb35
Previously, it was possible for AppWidgetsRestoredReceiver to
start the restore process before work profile has finished restoring which
resulted in the work profile items being removed from the workspace.
Bug: 131315856
Change-Id: I2f295a1ca91f1996522bcc8052aa139979526e3b
Favorites table is copied as a separate table name during the first grid migration.
On subsequent migrations this backup table is used if it exists, otherwise new
backup is created. The backup table is also removed if there is any insert or
delete operation on the db (outside of the migration operation itself).
Bug: 111850268
Bug: 121048571
Change-Id: I6f02f4a355c369ee99d89430971be258f7516f6e
Sunny Goyal
Charlie Anderson
Sihua Ma
Nicolas Sleiman
Stefan Andonian
Alex Chau
Tony Wickham
Pinyao Ting
Tracy Zhou
Jon Miranda