This is perhaps not a leak, but it conflicts with how StrictMode
activity leak detection works.
Bug: 139137636
Change-Id: If7fd0361b8e5ff81a2c0adb2308793ff87349951
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
This reverts commit 7ff297a81f.
Reason for revert: Verified this was not the cl broke post submit.
Change-Id: Id992c6937a4230b945436ddb868204366ffd045e
Tests that check for all apps in overview mode were only checking for
actions being enabled. This isn't sufficient logic, two button mode also
uses all apps.
Centralize the check for all apps.
Test: local tapl tests
Change-Id: If1bf98019e6f1aea8f7967883aba6780743e9d6b
This reverts commit 0499fb2060.
Reason for revert: This might break the post submit test. See b/150401176
Change-Id: Iafc420fff72de8e83ce5e325fc1e5b1a1efe7350
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
(cherry picked from commit a1a91b0c50)
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
This including swiping up to dismiss, down to launch app, left and right to switch apps.
Test: local
Bug: 139828243
Change-Id: Ib588c8725fb765097d03a5def719abdffd603708
Since divider stuff lives in sysui instead of framework
Bug: 133381284
Test: Manual, open 2 apps in split and drag-up to show
recents.
Change-Id: If6740b7ee4829bf4cac6e829e81943f16a41f977
(cherry picked from commit 3ef159becd)
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
Creating RecentsViewHolder to be contain LauncherRecentsView in OverviewPanel so Overview Actions View can be created only once.
Change-Id: I111f88903d2ff80275cc2e07b761577260073c17
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
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
Tony Wickham
TreeHugger Robot
Jon Miranda
vadimt
Vinit Nayak
Hongwei Wang
Becky Qiu
Zak Cohen
Evan Rosky
Sunny Goyal
Sreyas Rangaraju
Peter Kalauskas
Winson Chung
Andy Wickham