Otherwise we'd be stuck using the old touch controllers until DragLayer
is setup again (e.g. launcher is killed).
Bug: 77921826
Change-Id: I8aac6fc453839902cb2d99279a6bd1549ee17d79
> If launcher already started, creating the state transition only after threshold crossed, so that previous animations are not cancelled
> Not posting animaiton callbacks at the front of the queue, as that sometimes causes it get executed before onNewIntent
> Farking the activity as forceInvisible while launching an opaque app, so that quickly pressing home/back runs the reverse animation
> Not running state animations when force-invisible is true
Bug: 77830325
Bug: 77898806
Change-Id: I50a7e915ca35fd6aeb284c8f321ecca74396fe98
I find this less confusing, as the controller is also used in portrait
mode when swipe down is disabled.
Change-Id: Ifd6b4453a1b59e1f8305c1461d89ed99de2fe7d6
> In recents activity, getting the DeviceProfile size from the
root view, instead of the Display (as recents activtiy can be resized)
> The task size in Recents activity is now proportional to the activity
size instead of 50% screen size
Bug: 77875376
Change-Id: Ib417c31fc7ec8569876368134ef021452d60aa12
Registers a ContentObserver to handle Swipe Up gesture enable/disable
changes from Settings App. Also provides a static method to get the
current state of settings for the Swipe Up feature.
Bug: 77549883
Test: Manual Test
Change-Id: I5aa13cebdcb78be4869e8a5ae7f570490c8ac05c
Previously we only allowed dragging the forefront task. Now you can
swipe up to dismiss the second task as well, but can't drag it down to
launch.
Also cleaned up page-scroll-while-dismissing logic to ensure it works
correctly in RTL and for new cases with dismissing adjacent pages.
Bug: 73187449
Change-Id: I1fe873c4cf1380b951dd3b2e396ab401ca1f7470
> Always deferring the start activity call
> Fixing quickscrub when start activtiy is deferred
> Preventing finish() call on the activity
> Fixing initTrack to work when the activity already exists
Bug: 75979063
Change-Id: Id6038c1f6c2680ec920222fb6a85c0ecc0172ed4
We now pass the log action (e.g. SWIPE or FLING) to the pending
animation, so that the end listener can log appropriately. This
is used when swiping down or up on a task, for example.
Bug: 73783784
Change-Id: I5c2eee24e8b23cf4af68d503d3435a6d8088dd8a
Example bug:
1. Swipe up to overview and let go
2. Swipe all the way to the top of the screen, past where all apps stops
3. Swipe down
Before this change, you get reset in NORMAL state instead of OVERVIEW.
By ensuring that getTargetState() checks the drag direction before
returning a new state, we guarantee we only re-init in the case that the
state is actually changing. Otherwise it's possible to change the state
to one that is impossible, such as NORMAL when swiping up from ALL APPS.
Change-Id: I19913dded9c94228d06289780b6400e99403f378
In full screen always follow the device aspect ratio
In multi-window, follow the 1:1 split window size
Rotate the screen shot only in full-screen mode
Bug: 70289009
Change-Id: Id5095565634d4d7920fefa929b28276db80bda5f
For example, long pressing icon and then dragging in the same motion
should be ignored
Bug: 77652647
Change-Id: I9cc53c2873950f216d51d90f749b3cc0d0744d3c
