Added the preview license back, with changes as previously negotiated
with legal.
See first comment for staging directory link.
Change-Id: Ibc23d4d89b4380546d61ed052ba15dc81b8b1336
Ensure that the callback always sees the current-operation state in sync
with the various other bits of internal backup-operation state. Previously
only the current-operation state was managed inside the critical section;
this resulted in a slim race window where a callback could see an ongoing
operation as still valid, but after the internal state on which that
operation depended had already been cleared.
Bug 17931760
Change-Id: Ia032668e7a9d22f1029c57fc98db9e86484d5719
An app can send an accessibility event by calling the send methods
on view or directly asking the accessibility manager to do that.
While the recommened way to send such events is calling the methods
on view a legacy app or app whose developer did not read the docs
carefully may be calling the accessibility manager APIs directly.
In such a case the event does not have assigned window id and does
not get send. Since events fired by using the accessibility manager
directly lack context to determine whether thier source is important
for accessibility we assume they come from an important view to
avoid breaking backwards compatibility.
bug:18001711
Change-Id: Ie1c298fa5a0670cbeaedfcd64f820961c296b6ca
To clarify that BluetoothLeAdvertiser object will return null
when BT is off OR if the hw doesn't support these capabilities
bug: 18006072
Change-Id: I635d7971711a3cae7c58f7a0636faf9a03f19970
The restore-session idle timeout should not be ticking while we're
doing legitimate restore work. We now explicitly stop the timeout
ticker [a delayed message on our handler thread] whenever we undertake
a valid restore operation. The timer is already correctly resumed
when restore operations conclude.
(In practice we need to suspend the timeout tracking at exactly those
times when we're entering the wakelock-protected restore flow. The
timeout is reestablished when the wakelock is released; this part
is already in the code.)
Bug 17990544
Change-Id: I7318020ce30fd9c35bc3a644f8c101fd3d063c8b
Under certain circumstances when launching a new activity, the
topmost stack activity is moved to the front even though the
activity is being created in a different task.
This checks if the topmost stack task matches the desired
task and if not, moves the desired task to the top.
Also make activity dump ordering consistent.
Fixes bug 17721767.
Change-Id: I59397f31b629a208f3863887c57d6f6fb1f6e1f3
