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
Due to a bug caught late in the release, this API is broken
and should be removed from API 22 because it's too late for
a fix and there's no workaround.
Bug 19461292
Change-Id: Ib0757a4484b14afe7f83ae9527bb3f5f4834ee62
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
