Also use the same style for the date in the phone
notification panel (which already had the same net
appearance).
Bug: 5231182
Change-Id: Ie0b44c2b9021a4f6ad56b0e1a78fdc9d8cf16f88
The toIndex of accessibility events fired from a AbsListView
is exclusive but should be inclusive i.e. it was reported one
more that it has to be.
bug:5256286
Change-Id: I496959fdfb6760b0c74899730c4cc558e89234a6
1. Tuned the max angle between two moving fingers in touch
exploration mode for a gesture to be considered a drag.
The previous value was too aggressive and it was fairly
easy for the user to get out of dragging state if she
ingreases the distance between her fingers.
bug:5223787
2. Before clicking the explorer was sending hover enter and
exit resulting in firing the corresponding accessibility
events which leads to announcement of the content under
the tap that triggered the click. However, the click is
actually performed on the last touch explored location
(if in the distance slop of course) instead of the actual
tapping pointer location. Before fixing that the user was
confused since he was hearing announcement of one content
but actually was clicking on something else.
bug:5225721
Change-Id: I79fec704878f98c95f181bf8a9647e0bb1bd10ef
bug:5255022
bug:5218838
When the view starts scrolling, we tell native so it can block updates until the
view stops scrolling. This change fixes an issue where wouldn't tell native that
we stopped scrolling because the view didn't have room to move.
Change-Id: I5f2eec31493570937f7b8b2992a85283de06fb60
If it doesn't catch touches, the stream is dropped on floor, leaving
no event stream for swiping to intercept. Also connect up
NotificationClicker to large_icon.
Bug: 5068171
Change-Id: I51e74dd1cdc2749554c591432a48fad35de993ff
The test was making EGL calls once disconnected. Instead of calling
"disconnect" directly on the Surface, and EGL calls should be made to that
effect.
Change-Id: I21468ac8cbc2cb3145a49269e32a884736cd452e
In queuebuffer, if the surfacetexture returns an error,
surfacetextureclient should check for that and pass on the error.
Change-Id: Ie6d70e779fac0702f372eb4df5ecb655280875ee
Away in the misty span of very-long-ago, it was suggested that spinning
a separate thread to run the backup process was wasteful, and that it
could just run it inline on the dedicated HandlerThread that the
backup manager uses for its own operations. That was indeed true,
except that the timeout management was also using delayed messages
to that handler. You see where this is going: timeouts were never
actually being processed, with the effect that a badly-behaving
app's backup agent could lock up the entire backup / restore system
until the device was rebooted.
This is bad.
Backup operations are now driven as an asynchronous state machine:
each step (init, call one agent to obtain data, send resulting
data to the transport, finalize the backup) is handled as a formal
state transition on-looper. No synchronous wait-for-completion
or -timeout is performed on any thread.
As an additional effect this greatly tightens up the serialization
and locking semantics. We no longer have to worry about an in-
flight operation involving a standalone thread spinning off on
its own; everything is on the HandlerThread and can be coherently
manipulated from that perspective.
Along the way, this CL tightens up the per-agent error handling
logic. Previously a single failed agent would abort the entire
backup process, tantamount to a transport-level failure. This could
mean that the aforesaid badly-behaving app's agent could in effect
starve out other apps whose agents were routinely showing up later
in the queue. There's some nondeterminism involved, but in practice
it could and did happen. Furthermore, the failure case would
reschedule *immediately* in this case, because the transport itself
would see that all is well and sure, why not run a backup soon?
This, as you might imagine, causes battery-life issues.
Now we note that the single agent has failed, mark it for a future
repeat attempt, and process the rest of the queue normally, pretending
success at the transport level even though we didn't actually send
any data for that app. This means that (a) we now finish running
backups for everything in the queue, (b) reschedule backups only for
those apps whose agents individually failed during this run, and
(c) perform the retry after the normal interval [typically on the
order of an hour] rather than immediately.
NOTE: this CL does not retool the restore code path, just backup.
Restore is similarly vulnerable to misbehaving apps, though, so a
future CL will address that bug vector.
Addresses bug 5074923
Change-Id: I67e3f8d06f322607881eaa4093de6d675b85ff2c
Make ProgressBar maintain aspect ratio on indeterminate progress drawables.
Make RotateDrawable tolerate left/top bounds != 0.
Change-Id: Iee03030caa98f72a8745f1ae3fb0de108ff663d4
Logic in performTraversals() starts a transition running at the
proper time. But when a view's parent window goes away, this transition
may not start at that time because drawing gets canceled. But the
transition still hung off of the ViewRoot, waiting until some later
drawing operation to kick it off. This resulted in some weird animations
like the Recents panel appearing and having a single item animate off of it.
The fix is to delete pending transitions when drawing is skipped.
Change-Id: I3ab7702c16e069644a163424f977350743e2cecc
This change removes the MediaPlayer#setTexture method. It has been
replaced with MediaPlayer#setSurface.
Change-Id: Iaecbbac7629d7092883f270694c5c67391f4ed6c
