This fixes spurious verification errors that would be generated
when a view declined an initial event such as ACTION_DOWN. Since
the view would not receive the rest of the event stream, it would
not see the corresponding ACTION_UP and the next ACTION_DOWN would
trigger a spurious verification error.
Change-Id: I2386acf378cd1765d5446faed5ad9c6525f8b400
The mapper sends a DOWN when the finger is released then starts
a short timer. If the finger is not pressed again before the timer
elapses, then the mapper sends an UP to complete the tap. If the
finger is pressed again then the mapper starts sending MOVEs
as part of a drag.
Double/triple taps work as intended because we also start watching
for a new tap when the finger is pressed again. If a new tap
occurs the old tap is also finished. So each individual finger
short press/release cycle constitutes a distinct tap.
Change-Id: Iaa51182edee4378162a66adfd746088e93af2a30
Added a new PointerIcon API (hidden for now) for loading
pointer icons.
Fixed a starvation problem in the native Looper's sendMessage
implementation which caused new messages to be posted ahead
of old messages sent with sendMessageDelayed.
Redesigned the touch pad gestures to be defined in terms of
more fluid finger / spot movements. The objective is to reinforce
the natural mapping between fingers and spots which means there
must not be any discontinuities in spot motion relative to
the fingers.
Removed the SpotController stub and folded its responsibilities
into PointerController.
Change-Id: I5126b1e69d95252fda7f2a684c9287e239a57163
Make addHeaderView and addFooterView be more consistent with each other: they
now both check that there either is no existing adapter, or that the existing
adapter is a HeaderViewListAdapter, and they both call the DataSetObserver
(previously only addHeaderView would check the adapter, and it would only
check that it was null, while only addFooterView would call the DataSetObserver)
Make removeHeaderView and removeFooterView check that the DataSetObserver
is non-null before using it.
Change-Id: I681b87f70aabca63e664ca8d0c1cfc25530e00b9
In the old world, MenuBuilder and MenuItemImpl were responsible for
generating views for any presentation of a menu. MenuBuilder needed to
know any types and resources involved, and the implied caching
semantics did not work well for menus presented within AdapterViews.
In the new world, the MenuPresenter interface takes over the
responsibility of generating views or adapters for menu
items. MenuBuilder/MenuItemImpl still provide extra metadata tracking
used by these presenters. Mutiple presenters may be active for a
single menu at a time. All of this remains internal framework
implementation details.
BaseMenuPresenter provides a simple base for presenters that treats
the host MenuView more like an AdapterView. This allows for less
rebuilding of views when items are added/removed.
Callbacks have been restructured. Calls that relate to the menu itself
are still handled by MenuBuilder.Callback, but calls related to a
specific presentation of a menu are handled by MenuPresenter.Callback
objects attached to a MenuPresenter.
Also add API to programmatically set divider options for LinearLayout
and hidden API so that ActionBarView can have finer-grained control
over divider placement.
Change-Id: I2265b86a084279822908021aec20dfbadc1bb56b
(a) Don't check that the audiotrack is initialized (will
not be true in static mode until the first write call)
(b) Block until it completes playing.
Change-Id: I50eb6cece00f3d12f3b75102d62014c360ac0346
When a user explicitly disables wifi, wait on the supplicant shut down until after
all child states have handled exit - this avoids time outs due to communicating with
supplicant after breaking the socket connection
Bug: 4052161
Change-Id: Iec5bb3e14a2df4a8a12de8bb81d9c10aeb992ad4
