This is the framework version of ag/682710.
Original change description:
This change adds a missing call to offsetLocation() when tracking
swipe velocities on a SwipeDismissLayout. This bug was causing
incorrect velocities to be measured which often resulted in an
incorrectly interpreted leftward swipe cancelling the dismiss
gesture.
Bug: 20350515
Change-Id: I4f3e3668a1f9aab963fdfa9095a43f4c5344703f
Gus's original change description:
This change modifies the logic in SwipeDismissLayout which determines
whether or not a gesture should be interpreted as a dismiss
gesture.
Previously, on the first touch move event, the gesture was classified
as a dismiss gesture if the X movement exceeded the touch slop
and the Y movement did not. At this point the gesture was not
intercepted and the underlying widget (in the case of the cue
card, the GridViewPager) received all subsequent move events.
In the case of a very fast gesture at a slight vertical angle, it was
easy for the total Y movement to exceed the touch slop.
This change only rejects the gesture if the Y movement exceeds
the X movement, which is consistent with how GridViewPager
distinguishes horizontal vs. vertical swipes.
This change also cancels the dismissal if the end of the gesture
is a leftwards flight.
BUG: 20542762
(Same as b/20350515 but for Activity dismissal at the system level.)
Change-Id: I6e3fb646c42dda0d1c1f5552d91b27c6374fc08c
AccessibilityNodeInfo refresh was getting the latest cached
state but this is not good enough as an accessibility service
can execute an action on the node and then refresh it to get
the new state.
bug:16954787
Change-Id: I004b4987b8dc423a2ab7031a4fbfe64365ddd7fe
(cherry picked from commit 5738fec00d)
This change prevents the Runnable posted by ActivityContainerCallback
from retaining the ActivityView's callback if it is never cleared out
from ViewRootImpl.sRunQueues.
Bug: 19872883
Bug: 19654978
Change-Id: I6dce4381b96c8c77afcd38a55bfe474f13dfbfba
I am not sure if this is the correct approach to the problem. Right now
we are reporting double chin (60 vs 30). The reason for this is that
we setDisplayPadding from Clockwork Home activity (bottom=30) and add
windowOutsetBottom.
We use display padding to set surface frame size (320x320) and both
outset bottom and display padding for inset. I think we should use only
one of these. I decided to go with display padding, because that's
what was suggested to me the last time I visited this. I removed
the dependency on windowOutsetBottom altogether.
However, I don't feel confident this is the correct way to do this.
We depend on Home activity to send the display padding now to get
the correct result, so wallpapers behind other activities will not
work correctly.
Maybe instead of setting display padding from the outside, the
windowOutsetBottom should be added to display padding bottom for the
purpose of calculating surface frame and generating insets.
Advice on what is the right approach here would be greatly appreciated.
Bug: 19881056
Change-Id: Ifb655528d8f85ef01d942bf1e64e8b08475689ca
Change way in which an outside caller can get the preferred SSLContext.
(cherry picked from commit 8a97063720)
Bug: 19798387
Bug: 17136008
Change-Id: Ide578664bcb605304322bfddd2e640a63042fa09
Problems arise if an activity is started in an ActivityView when the
parent activity is not resumed. In particular the ActivityView can
be brought to the front in front of other activities that have been
started by the parent.
This change checks the state of the parent when the ActivityView is
starting and if it is not resumed, throws an Exception.
This change also removes the queueing up of Intents if the surface
does not exist when startActivity is called. Now, the owner of the
ActivityView is notified when the surface becomes available. If
startActivity is called before that notification an Exception will be
thrown.
Fixes bug 19147472.
Change-Id: I6712cf1929fe65c4238ce7f3feb4e8511ed97244
