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
also:
- when using menu to "remove from list" in landscape, animate items upward (5149577)
- dismiss recents when tapping on whitespace regions (5115883)
Change-Id: I0f38c7567281583898a49f572cf92d6c59464649
this happened when the overlays were in use, since the animation
is rendered in the FB and the FB is not used.
we now have a way to turn hwc off temporarily.
Change-Id: I3385f0c25bb9cc91948e7b26e7cd31ed18c36ace
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
Force AEC on for tuna board because of the strong feedback
of Rx audio path, even when playing over earpiece or headset.
Change-Id: I9c14257d56103ba82d6cdb0b7d5a3f315638136e
Only the easy correction (i.e., voice ime corrections) will lose the underline, while the misspelled span will not.
Change-Id: If96c17473dd70c99b808739ddde800cc93551e2a
The animation that runs when the NotificationPanel appears
used to start, then pause for a long time as the window/surface/layer
was created, then by the time it started to be visible, the animation
was over. This new approach delays starting the animation until the
layer has been drawn, so the animation can actually run a few frames after
that before finishing.
Change-Id: I998f01fd48cb762178021ad99e2b919b58a1ef3f
Text selection mode was started by two consecutive taps inside a
field with selectAllOnFocus.
ArrowKeyMovementMethod does not respect the possible cancelLongPress and handles up events.
As a result a scroll that happens to end up at its initial position will be considered a tap
and will move the cursor.
This is however not considered as a tap in TextView and a possible selection mode would not
be stopped in that case.
Fixed by making ArrowKeyMovementMethod aware of the cancel that happened in Touch.
Change-Id: I07372b703f250e1edc7ee0665318ce30441b9187
Keep track of lockscreen clock visibility, and only hide statusbar
clock when one is provided by lockscreen. This fixes bug where widget
would hide all clocks.
Bug: 5242065
Change-Id: I48de98ecb956c7f22bd40b54d771c78c1a80c14c
Both ::getSize and ::read call into lseek64, if this happens simultaneously
from multiple threads the results are undefined if not properly serialized.
Change-Id: I737cafebd836f3d8eb702beac557b4731f69c6f6
related-to-bug: 5196490
When in a phone call, we keep the screen off while the prox sensor returns positive
and the device is oriented in a vertical position.
If the call is terminated on the other end, we keep the screen off
until the proximity sensor returns negative.
We do this to avoid having the screen turn on as soon as the other end
hangs up while the phone is still next to your head.
However, we allow the power button to wake the screen while waiting for the proximity
sensor to go negative as a precaution in case there is a problem with the proximity sensor.
But unfortunately that logic broke due to a change in the call path used to turn the screen
on from the power button (it previously called userActivity, now it uses a wake lock).
This change adds code to handle the new code path so the power button will wake the screen
while we are waiting for the proximity sensor to go negative after a call.
Bug: 5184524
Change-Id: I7d1e0f0d1f78680c552a05d68a392647823250ab
Signed-off-by: Mike Lockwood <lockwood@android.com>
This patch modifies the library loaded in libEGL.so to
handle the case of GLES emulation as follows:
- if we detect that we run inside the emulator, check the
GPU emulation status through ro.kernel.qemu.gles, which
will be set to 1 if supported, or 0 otherwise.
When trying to run on an older version of the emulator,
the kernel parameter will not be defined at all.
- if GPU emulation is supported, use egl.cfg as usual.
It will contain a line like "0 0 emulation" that will
load libEGL_android.so appropriately.
- nothing is changed if we don't run inside the emulator.
NOTE: Ideally, we would modify libEGL_emulation.so to
redirect all calls to libEGL_android.so in this case.
However, this turns out to be extremely tedious to implement
(too many functions with different signatures).
As such, it is much simpler to make the check before
loading the library.
Change-Id: I9930bc168d9013cc8700feedc57b979384467c37
