(a) Fix a null pointer exception, caused by a race condition
between stop / start calls.
(b) Fix a deadlock observed when multiple apps call stop() when
an item from one of those apps is currently being processed.
bug:5253061
Change-Id: I78533aecfda028588ce6aedb041009bc0a6f4620
There's a problem with how LayoutTransition cleans up after itself
when the target view is in a Window that is not on the screen.
The quick fix is to always start (and therefore properly end and clear)
transitions, regardless of whether the window is in the tree.
Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
Add API support for supplying content descriptions on action bar tabs.
This helps accessibility in cases where no title text is shown.
Change-Id: I8fdc4c2f2b279871b9f24b0b16e5167879b22741
- The easy edit span was displayed twice when in extracted mode. The orignal TextView now checks if it is in extra mode, and if so it does not display any pop-up
- The easy edit span was displayed before the view was layout causing the application to crash.
New feature:
- the span is automatically hidden after a timeout
I also renamed all the fields and classes to "EasyEdit...". There were still some field/class using an old name.
Bug: 5255363
Bug: 5247453
Bug: 5246997
Change-Id: Ic9bf05d2525e2df9017c91344a687e8cb9105417
Change the behavior of the highlight marking the "suggested text" and not the differences.
Bug: 5252699
Change-Id: I4c7e9fc9bac81da8b5f643990b86a336363d7968
Two problems fixed here:
- The docs for AnimationSet were too vague and incorrect: some properties of
Animation (such as duration) are pushed from the AnimationSet down to its children, as
the current docs say. Some other properties (such as repeatCount) are ignored. Other
properties (such as startOffset) apply to the Set itself, but not to the children.
Fix: clarify this behavior for each of the properties.
- The behavior for XML resources was just busted. We would set the various properties
(e.g., duration) and then forget that we did so, since we reset the flags that marked
their existence after we loaded the resource. In fact, the duration property was
always being reset to 0, regardless of what it was set to in the xml resource.
Fix: Make it work they way it always should have: respect the values read from the XML
resource and make them behave the same way they do when set at runtime.
Change-Id: I07d68876d2259105dc5a359501d5c656ecfaa8e5
- this really just calls cryptfs cryptocomplete
- needed so that UI logic can present a factory reset option if
encryption screwed up
Bug: 3384231
Change-Id: I553de87f0d03a65851030c9c5266e85866d30fa6
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
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
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
