Also, need callback from SysUI to Launcher once the pip animation is
started to keep back compatibility.
Bug: 146594635
Test: manually
Merged-In: I617a17fd5f6049d9f1d49f9f834623a2bb49f6ca
Change-Id: I617a17fd5f6049d9f1d49f9f834623a2bb49f6ca
Change high res loading state implementation to toggle on/off based on
config_lowResTaskSnapshotScale!=0 instead of ro.config.low_ram=true
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Change-Id: I316e553a8a13fe38f1224c38f7aa717a0f628f57
Enable preloading if config_enableTaskSnapshotPreloading instead of
assuming it should be off for all low ram devices. This allows it to be
configured via an overlay.
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Change-Id: I9e3320dcff5b710e110cc7199c41c5a004991592
Bug description: When folder label is updated from a suggested label to a custom label,
EditFolderLabelEvent log expected to have FromFolderLabelState = FROM_SUGGESTED.
Currently FromFolderLabelState is logged as FROM_CUSTOM in such scenarios.
Root cause: Folder label state is decided based on whether IME has entered into compose mode while editing.
This works fine for initial folder creation and also updated to non-empty label(to both custom or suggested).
But when folder is edited from suggested to empty label, its internal state changes from SUGGESTED to CUSTOM as expected.
Later when empty label is updated to suggested again, its internal state remains custom forever.
Fix: Instead of setting folder's internal state based on IME's compose mode, comparing actual folder label with suggestions
and set it to SUGGESTED if any suggestion matches else CUSTOM.
Change-Id: Ieea572ee93fd5567e3128c9bbcea3b670f0f01d9
Creating RecentsViewHolder to be contain LauncherRecentsView in OverviewPanel so Overview Actions View can be created only once.
Change-Id: I111f88903d2ff80275cc2e07b761577260073c17
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
Change high res loading state implementation to toggle on/off based on
config_lowResTaskSnapshotScale!=0 instead of ro.config.low_ram=true
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Change-Id: I316e553a8a13fe38f1224c38f7aa717a0f628f57
Enable preloading if config_enableTaskSnapshotPreloading instead of
assuming it should be off for all low ram devices. This allows it to be
configured via an overlay.
Test: TaskSnapshotCacheTest
Test: TaskSnapshotControllerTest
Test: TaskSnapshotPersisterLoaderTest
Test: TaskSnapshotSurfaceTest
Bug: 148099851
Change-Id: I9e3320dcff5b710e110cc7199c41c5a004991592
when detecting motion pause events. This is the same logic used by
the platform implementation VelocityTracker
Bug: 139750033
Change-Id: I87aabd46e58a5caa1395be3a63fd38d0ee75e355
Also, need callback from SysUI to Launcher once the pip animation is
started to keep back compatibility.
Bug: 146594635
Test: manually
Change-Id: I617a17fd5f6049d9f1d49f9f834623a2bb49f6ca
It seems that the only time it is used, it is the same as
mSourceWindowClipInsets anyway.
Bug: 149870691
Change-Id: I3b1a5a47a0d49cdd6eb8a3271ca24da6c17109cb
Previously, we were only updating the clip rect when params.currentRect
== null, meaning the clip would be stale once the caller started
providing its own rect (e.g. when swiping to home).
Also fix some visual jumps when swiping home, all caused by running the
transform progress from 0 to 1 instead of starting at whatever the
progress was before ending the gesture, e.g.:
- When swiping to home without animating into an icon, the corner radius
was set back to the window corner radius.
- Before this change, the clip didn't update throughout the animation,
making the window slightly bigger than the floating icon view; after
this change, the clip jumped to show the insets again before clipping
back down during the home animation.
Bug: 149870691
Change-Id: Ie48f4b665a5bf3cbef76bdf7f043febe99fb84a0
AppWindowAnimationHelper and TransformParams were being very tightly
intertwined, to the point that you really had to understand subtle
nuances of both in order to get a desired behavior. This makes making
changes really difficult, because there are lots of "traps" to know
about and navigate. To help alleviate this burden, cleaned up some of
these traps and give AWAH and TP distinct roles:
- A caller who needs to animate an app window needs both AWAH and TP.
TP defines specific parameters of how the app window should be
controlled, and AWAH simply reads from TP in order to provide the
desired behavior.
- Only the caller should write to TP; AWAH should no longer change
anything in a TP that is passed to it. For instance, instead of
repurposing TP.currentRect, AWAH now has its own mCurrentRect to
update based on passed parameters.
- TP is a very basic class that just holds various values that callers
can set one at a time. The order should not matter (setting one value
will never set another one), and defaults make sense.
- Commented the setter methods in TP so developers shouldn't have to
follow the code to see how they are used.
Bug: 149870691
Change-Id: Ia48f4453c29549271a3fc6538128a1a77439e015
Start a thread to read logcat synchronusly instead
of back-tracking at the end of the test
Also:
* Reusing the same logcat process for all checks. This eliminates
reading the log from its start for every gesture. We don’t kill that
process at the end, and don’t stop the thread. I’ve verified that
“am instrument” doesn’t hang, and the logcat process gets automatically
killed after the test process exits.
* Not using mStarted latch, as there is no need to wait until the reader
reaches the start mark.
Bug: 149422395
Change-Id: Ide4ed19ad8d099c41918f38c2b073b8b2e143b69
This currently includes the menu that pops up when
long pressing an app icon in Launcher or Search, or
long pressing Smartspace. Previously, only the menu
for Launcher apps grabbed accessibility focus after
the open animation completed, and now all three do.
Fixes: 145253300
Change-Id: I147b45d38a04ab9a55eee9b5bd5551b4c7185fcf
This change takes care of rendering widgets using widget provider's layout info.
Test: manual
Bug: 144052839
Change-Id: I7002d8bf653513cdd317736d550a47f61f0ee474
Amos Bianchi
Hongwei Wang
Peter Kalauskas
Tracy Zhou
Andy Wickham
Sunny Goyal
TreeHugger Robot
Samuel Fufa
Sreyas Rangaraju
Tony Wickham
thiruram
Hyunyoung Song
android-build-team Robot
Vadim Tryshev
Winson Chung
Becky Qiu