Floating icon animation runs entirely in portrait
since that's what orienation launcher starts in.
Current app window target rects are in landscape to
be able animate to Overview correctly (which is not
in portrait since the leash from WM is in the same
orientation as that of foreground app).
Invert that rect as the animation from app window
to floating icon progresses.
Fixes: 148528795
Change-Id: Ie1149a1a8904afc80bd1986f8d67b6f2d88c49f2
WM is making changes which allows apps to maintain
their orientation independent of the orientation of
the foreground app. This allows recents to always start
in portrait even when the app currently running is in
landscape. This means we have to give the illusion of
a landscape oriented overview when user swipes up in
gesterual nav when launcher is started in portrait
configuration.
PagedOrientationHandler abstracts all coordinate specific
logic from Paged/RecentsView primarily, but also all
other dynamic calculations throughout launcher.
PagedViewOrientationState is the single point of exposure
to other classes that depend on those changes. The goal
is to also minimize holding state to allow for default
implementations of PagedOrientationHandler for all the
3p/Fallback classes. PagedViewOrientationState also
holds other data around rotation that isn't
specifically tied to view logic.
The fake landscape overview can be toggled with:
adb shell settings put global forced_rotation [0/1]
Fixes: 146176182
Change-Id: I65d8d4e9f92b93931cbe0053ccaf0cda8d2ffd6c
While the recents task list is frozen, launcher
will continue to listen for touch regions in
all orientations of apps it has seen while frozen.
Ex. Start w/ portrait app, then quick switch to
90-deg landscape app, touches in the navbars of both
those orientations will be treated as valid.
Once the task list unfreezes, only the orientation
that is currently displayed will have a valid navbar
touch region
fixes: 140116135
Test: tested manually in all 4 orientations with
quickswitch, swipe to recents and swipe to home
Attempted to write unit tests, but only basic ones
since there are some limitations on the MotionEvent
API for mocking
Change-Id: I8d3751571a939497b44e0dd249a0248299ba5ceb
Didn't test out widgets in Part 5. So in this change,
- Added some widget classes to the PreviewContext WHITELIST
- Manually update widget model after loading workspace since we do not attach widget listeners to the LauncherAppModel for preview.
Change-Id: I0a555b2319b2e91432dbd58289ddb66aca1384df
It also turned out that Pilfer event seems to come in a
non-deterministic order relative to the events from the Main and TIS
sequences. So I moved it to its own sequence.
Change-Id: I5851aafb6d04398c5727712eaf8561916a30c4c5
Overview actions removes the all apps from overview. Don't run the tests
that depend on these.
Ultimately need to add more tests for the actions.
Test: tapl local
Change-Id: I2471d10af7bc03a40a94f99aa16354b85bdb3ad7
Generally mEndRect is still correct from when we set it in
animateOpen(), but there are cases where it is no longer valid and
should be recomputed in animateClose(). For example, if you dismiss
notifications, the height of the popup changes between opening and
closing it.
Test: Long press an icon with a notification dot, dismiss all
notifications from the popup and then close the popup. The shadow
follows the outline of the popup, instead of extending well below it.
Change-Id: Ic5d6ad2807ea1ec8aff5e3d6ce8abaa11ce5d33c
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
when detecting motion pause events. This is the same logic used by
the platform implementation VelocityTracker
Bug: 139750033
Change-Id: I87aabd46e58a5caa1395be3a63fd38d0ee75e355
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