On touch up, View would move itself to the pressed state if it
hadn't already shown as pressed. However, it did this *after*
scheduling the message to deliver the onClick(). Thus if the
app took a little too long to execute inside of onClick(), the
invalidate to draw the highlight state would be executed right
before the following message to remove the highlight state,
causing it to basically not be shown.
This change just does the invalidate before scheduling the
onClick, so we can be sure it gets done first.
Change-Id: I6a4d1742a3aab60969c38b44bb3e163f48de62d4
Fixes bug 3362502
The underlying cause was that the DragEvent.obtain() variant which
clones an existing event was failing to copy the local state field.
This change also moves the logic for inserting the local state object
into DragEvents about to be dispatched from the Binder incall thread
into the main-thread code sequence. This is to eliminate any potential
SMP memory coherency issues around drag start vs incoming events
needing to refer to the local state object.
Change-Id: I368e8936dbf8a00b7d5cc19c2ef0101bd75b6b2d
In particular, if a new window was created out from under the drag,
the drag-move event dispatch logic would wind up blithly assuming
that it would find a valid touch-dispatchable window under the
finger. When this was untrue, it would NPE, but the NPE was caught
and discarded safely by higher-level guard code.
With this change, we now avoid the NPE entirely and report the
spurious condition as part of the debugging log stream.
(Also add the local-state object to DragEvent.toString()'s output.)
Change-Id: Idfa5f45d049e48415ee59c8b0ffb5b0ed4098ce3
Bug 3347962
Root cause of this problem: if the adapter's content gets updated by a backgroung
thread, the PopupDataSetObserver will call showDropDown which will popup the
list.
Added a flag to make this call show the popup iif it is already visible.
This relayout is needed to clear the mDataChanged flag set when the content was
modified and which otherwise prevents touch events on the result list.
ArrayAdapter didn't use its lock to protect access to mObject.
-------------------------------------------------
However, the study of the this race conditions revealed an other bug:
Updated adapter's content is not displayed in filtered AutoCompleteTextView
Bug 3369097
Change-Id: Icd90d452f98231866f4d8a1f6994c1492febecb9
1. ViewGroups being removed from the layout during a drag would wind up
crashing the app with an NPE at drag-ended time, due to blind dereference
of now-cleared object pointers.
2. Passing a 'null' ClipData to startDrag() would crash the system
process with an NPE. Should this even be valid? I'm inclined to say
yes, though it means that apps will need to guard against it.
Fixes bug 3369542
Change-Id: I168fc1284d6fd4403999946609725414cf254df0
When the AudioFlinger runs out of available AudioTracks (max 32),
the ToneGenerator constructor throws a RuntimeException. Although this
denotes an abnormal situation, VolumePanel should catch this exception.
Change-Id: Ida1312fe4857e99a0ef38b4013cb03e819405689
Don't dismiss by default when tapping outside, even for AlertDialog.
If AlertDialog doesn't have any buttons, tapping outside will dismiss it.
Applications can make their own dialogs (or activities looking like
dialogs) can use the existing and new APIs to control this behavior
themselves so that it does the right thing.
Change-Id: I02bfb9161e169de0033200211b3a7ec80080bd83
