Sockets accepted on a server socket didn't populate
the mPfd field, which is used to close out the java
end of the native-and-java communication socket when
the overall rfcomm socket is closed. #badnewsbears
b/21398841
Change-Id: I3adb0a9965f83d0f3006fa4f79ea4abeab5c9a17
Outsets are used during measure/layout pass, but this can be called on a
view that is not currently attached.
Bug: 21602590
Change-Id: I5860d5e7c20131e2650bdb8635e9659e76205fa1
(cherry picked from commit e660d4e96a)
Outsets are used during measure/layout pass, but this can be called on a
view that is not currently attached.
Bug: 21602590
Change-Id: I23e3acc45ca4bf7684d8913f839e29e8e9e94d78
(cherry picked from commit e660d4e96a)
Rotation might change while the wallpaper is displayed. If outsets are
present, this must trigger a resized callback and the wallpaper must
take these accounts immediately into account before requesting relayout.
Bug: 22209764
Change-Id: I97f2670f384ccac792e7c2727eb0ef017ec66188
Outsets aren't dynamic so they are a great candidate for a hint when the
window is added through the window manager. Thanks to this during first
view hierarchy measure or wallpaper window layout they are immediately
available and don't require multiple measure/layout passes.
Bug: 21593814
Change-Id: I573c15ffbbe4fcd8a6ed9c5e4fcd6cfbbcd7434f
Cherry-pick from master
This change adds four new stem keycodes for Android Wear. These
keycodes are intended to represent the various hardware buttons
around the watch. There is one primary stem key that will be used
for power/settings and three generic stem keys that will be
customizable.
BUG: 21903503
Change-Id: I867cf79554c72d42c8acbb3ff8b1678e482d4fe2
This fix is to take advantage of ArrayMap, which is a key-value
mapping data structure that is more memory efficient than HashMap.
Bug: 11604254
Change-Id: I57006880de570a4d7f3899e274cf0a06355d116b
(cherry picked from commit d7444427d9)
The existing code exits the column-filling loop immediately but
may continue to try to fill rows. Ordinarily this should fail
too but it's possible for the process to continue and then
blow up a little later. Fixed this problem by exiting the row-
filling loop promptly.
Bug: 21406130
Change-Id: Ifab59188d5d1b40f3c1f5c97604dd48da71bf37b
(cherry picked from commit bb8c841e90)
ActivityView shouldn't set the surface on the main thread, because it's
a binder call and causes jank. Instead it should delegate the call to a
background thread and let it do the work there.
Bug: 15752100
Change-Id: I6f2764c93dfb8f3e00d79f0e97d4a6688b6fdd8f
Fix for situation where you palm the device while swiping away an
ambiactive activity (or rather, when you swipe slightly an ambiactive
activity during palm gesture). This would make the activity stay in half
dismissed state. Instead when the screen goes off, we either dismiss or
cancel the dismissal.
Change-Id: I82e699c00c25bc97dd95bc6473a17e5817f7667a
Information about the chin is now part of the config.xml instead of the
theme. It is retrieved by WindowManagerService and passed to the clients
as insets. Clients can adjust their behavior in a way that makes it
invisible to the user, that part of the surface doesn't actually exist.
Bug: 19908853
Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
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
