1. Changed Preload Icon UI to be grayscale while the app is not startable.
2. Added progress bar for when app is installed but still ownloading.
3. Updated Preload Icon progress and click handling to use new incremental api.
Progress bar color updates will follow in a separate CL.
Demo: https://drive.google.com/file/d/1H1EvtTorLeJwC1eiq10tm-TT81YZ6osk/view?usp=sharing
Bug: 171008815
Test: manual
Change-Id: I5874a5146d79a8c91d7d90ff0b9c1c427a3c95dd
- Map to progress 1 instead of dividing by 0 if expectedDuration == 0
- Map to starting progress one frame ahead based on velocity
- Change direction of velocity so it's in the same direction as the
task progress (0 is down and 1 is up).
Change-Id: I5ac3f8a0d6c616bd303ac1a902242964bb33d3c7
Set newOneHandedSettingsObserver() defaut value 0 to prevent
blocking swipe-down notification's OneHandedModeInputConsumer
.onStartGestureDetected() when device first booting.
Bug: 175084985
Test: rebuild ROM image and manual
Change-Id: I5fe7d4036ac74682ae72cf210e8b40c63ceb53e1
Pending a resolution in b/174174514, disabling the visibility-gating of hotseat and all app prediction row updates. Updates will be allowed regardless of visibility.
Test: manual
Change-Id: I10e4dae9aad9af7b799fdad3b231c734e383b493
Previously, we were using scroll direction POSITIVE as a catch all
to mean "up" but in seascape, we actually want NEGATIVE. Added
getUpDirection() to capture that. Tried to clarify the code a bit
by putting all the methods used solely by TaskViewTouchController
together with documentation. It's still pretty confusing and feels
redundant, but couldn't think of an obvious way to simplify.
Test: Swipe up and down on a task in all permutations of:
- 3 button mode
- Gesture navigation
- Portrait
- Landscape
- Seascape
- LTR
- RTL
- Home rotation allowed
- Home rotation disallowed
Fixes: 174009771
Fixes: 173567204
Change-Id: Id0f8d6f4365d888eb46182d8544d18206795dfb8
In cases where test execution and launcher relayout overlap, mLauncher.getAppsView().getContentView() returns a recyclerview instead of pagedView. This is resolved when rebindAdapters is later called with showTabs=true. The issue here is we are keeping a stale value of mLauncher.getAppsView().getContentView() in WorkEduView which is problematic as pagedView is required to set the right tab index for the test.
This behavior also affects work testWorkEduIntermittent as we need to verify the a pagedView is visible before text execution.
Bug: 149867607
Bug: 159671700
Test: flake -t com.android.launcher3.ui.WorkTabTest
Change-Id: I4b0968d6b9daa5c8fe741d4b1ed090f9c7acabed
Launcher overwrites user's favorites table (icons in WorkSpace) upon new
install session from Play Store with install reason being restore. The
overwrite was introduced in the attempt to mitigate failed restore
session due to asynchronous nature of user profile restore, but it has
been causing general instability in backup and restore. Going forward
Launcher should be moving away from table overwrite approach, this will
be implemented in b/148284747.
Bug: 171774227
Test: manual
Change-Id: I91221544dbaeb42224ce9f595906b6d9f0e4aa89
already-closed DB.
Since the DB is already closed, if we can't end the
transaction, it should not put the code in a bad state.
Bug: 173162852
Test: manually tested backup and restore flow and existing tests
Change-Id: I2692d98f0a8efc8aeb6bfd826fe738e4436c6ee4
This reverts commit 3a8075366c.
Reason for revert: This behavior is no longer needed and was requested to be removed here: b/165931807
Change-Id: I3f16528403fb2e33eba620f8082ac2dcbe9591bf
After SuW the favorite table is copied into backup table, but the widget
id in the backup table hasn't been migrated. This introduces general
unstabality and can sometimes leads to the disappearance of widgets
after a restore.
Bug: 171774227
Test: run Backup Restore flows and verified database status with arbitrary
logging
Change-Id: If275a6b5395504d6de90e26c3998f759e797f6e1
