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
This prevents loss of delta calculation accurracy when dragging, which
was done in float and converted to integer.
issue: 3366067
Change-Id: Ia121a6ef4619c9abfb1f76a01db3272d41d02b81
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
Bug:3367446
bringPointIntoView was called by TextView in onPreDraw. This was
passing a message to the webcore thread to change the scroll
position. This is unnecessary, because typically the scroll
position will be changed by webkit when keys are pressed. The
one situation where this helped was when the user taps on a
textfield, which brings up the IME, which may cover it. A better
solution is to tell webkit to scroll it on screen once the
screen size changes. I have a CL in external/webkit to do that:
https://android-git.corp.google.com/g/#change,91095
Change-Id: I6e06ad59e1a1c99365bb5be635a43d1b88658c0d
Receive the current seek position from native when we start
playing a video. That way is we are returning from pause we correctly
continue where we left off.
Requires and external/webkit change.
(I6001f45a362f491e9040c8b52260d0a08fb8504f)
Bug:3303721
Change-Id: I6b92289d4ef36bba1e0429327917533a4101655d
- Moving the service binding to AppWidgetService to prevent arbitrary apps from binding to widget services
- Requiring RemoteViewsServices to require android.permission.BIND_REMOTEVIEWS permission
Change-Id: Id135bafba998299eb278067712b8a5d8487cfd04
