also cleaned up some unnecessary synchronous commands from state machine,
and fixed an issue with a synchronous WPS command
Change-Id: I55bf4379d9810e11f2ba2e03e2e703b132d1488f
Now, each ViewGroup is tracking which of its child views [which might
themselves be ViewGroups] is currently under the drag point, and when the
drag leaves that child, a DRAG_EXITED is synthesized and dispatched all
the way down to the leaf view previously under the point. ENTERED is
still *not* dispatched down like this; instead, it's calculated and
synthesized directly at each level based on the new LOCATION.
The ViewRoot still tracks the leaf drag target, but solely for the
purpose of reporting changes to the OS after full dispatch of a new
LOCATION -- the entered/exited messaging is no longer initiated at the
ViewRoot level.
Change-Id: I0089cc538b7e33a0440187543fcfd2f8b12e197d
The implementation was guarenteed to cause deadlock when a timeout was set.
Change-Id: I59444ea784eb9057c6c4c9e9123f558b3ef5eef6
Signed-off-by: Nick Pelly <npelly@google.com>
Reorganization of getResource to allow for other densities accidentally
overrode the default return code for getResource from BAD_VALUE to
BAD_INDEX. This corrects the default return to BAD_VALUE which restores
other things to working.
Bug: 3155824
Change-Id: I13dafff85bc6978c5f5435fc09ab0474c7885c4d
the warning printed currently "do requery on background thread"
is not that useful in processes such as gapps, acore.
to reduce the deluge of bugs assigned to me, I think a simple
deprecation warning is better.
Change-Id: I7a1129ea889f10e72895092a3cdd48cc96d0d1f0
Make clear in the Javadoc comments of the `Cursor` get* methods that
implementations thereof can have implementation-defined behavior. In some cases,
these changes actually correct the documentation. For example, in the case of
`getShort` and the `SQLiteCursor` implementation thereof, non-numeric data is
*not* converted to a `short` via Short#valueOf or even in a functionally-
equivalent manner.
Change-Id: Ib2f81811a603680b52fc482eb9c0f3195447566f
Two issues:
1. First, due to an inverted conditional in the input dispatcher, we were
reporting touches as long touches and vice-versa to the power manager.
2. Power manager user activity cheek event suppression also suppresses touch
events (but not long touch or up events). As a result, if cheek event
suppression was enabled, touches would not poke the user activity timer.
However due to the above logic inversion, this actually affected long
touches. Net result, if cheek suppression was enabled in the power manager
and you held your thumb on the screen long enough, the phone would
go to sleep!
Cheek event suppression is commonly turned on when making a phone call.
Interestingly, it does not seem to get turned off afterward...
This change fixes the logic inversion and exempts touches from the cheek
suppression. The reason we do the latter is because the old behavior
was actually harmful in other ways too: a touch down would be suppressed
but not a long touch or the touch up. This would cause bizarre behavior
if you touched the screen while it was dimmed. Instead of brightening
immediately, it would brighten either when you lifted your finger or
300ms later, whichever came first.
Bug: 3154895
Change-Id: Ied9ccec6718fbe86506322ff47a4e3eb58f81834
