- Also cleaning up the Task to remove some confusing nomenclature
related to task properties. Now there is a single icon and title,
and we keep a copy of the TaskDescription for future icon loading.
- Also changing a few cases where we should be calling isFreeformTask()
Bug: 26221779
Change-Id: Iac20cc7b4912f76c14232a323981ab2e8f62628a
- Fixing regression where we were clobbering the freeform stack order
- Ensure there is padding between tasks
- Fix the header bar animation
Change-Id: I69ced3e3cb2f0c761ddf0c3bd00b17c847d74c0b
* changes:
Allowing tasks to be swiped away in the history view.
Loading activity icons in History view.
Ensuring that the undocked task is visible in Overview.
- Also only show the history button if there are
historical tasks (and reflect that in the
button text)
Change-Id: I7b9dcf79e2feef61f96b720f586144de4c5033e3
- Moving the empty view into the RecentsView so
that we can coordinate its animation with the
history button and the task stack (when history
is visible, all of the other views are animated
away, and vice versa)
- Removing unnecessary launch state flag to keep
track of recent task empty state just for deciding
animations for system bar scrims.
- Fixing issue with overview button not dismissing
the history view while it is open
- Fixing issue with swiping the last recent task
away causing both Overview and the docked task
to be dismissed to home
Bug: 26044055
Change-Id: I731fb0f7efb3de7d5f826673479c602b606453e9
- Because these tasks may not have valid
last-active times (they can be launched in the
background), the historical state should reflect
the task that they are affiliated with.
Bug: 26043228
Change-Id: I04db9effc371783a80bea80bd0a45b666269ead1
Sometimes, the volume control expand arrow would be displayed
incorrectly. When different apps use different volume controls and
force different orientations, the position of the arrow (expand button)
will not be updated correctly. When this happens the arrow cannot be
pressed and the volume settings cannot be expanded.
The underlying reason is that onLayoutChange only compares the old
dimensions of a view with the new dimensions, which doesn't take into
account that the last time onLayoutChange was run it may have been run
for a different view (a different volume control), in which case the
dimensions of the new view may not have changed, but the arrow needs to
be repositioned anyway as it needs to be positioned in relation to
another view.
Fix this problem by storing the last stream (volume control) that the
arrow was positioned in relation to, and checking if we're positioning
in relation to the same stream the next time the position of the arrow
is updated.
Change-Id: Id23e7605d50857292e09c1909b3e27f01bdf5e22
