- When double tapping, the next preload call can come in before activity
start, which then resets the instance load plan (which is not
preloaded since Recents is “on top”), thus having no launch task,
which then falls back to launching the front-most task. The preload
call should never create a new plan unless it will preload it.
Change-Id: I001bfc901856c4e6b4e4b9b6a2125085b53c808b
- Fixing regression in scrolling from the back of the stack to the front
where bindVisibleTaskViews() would be called early causing jank and
task views to be returned to the view pool before the animation was
complete.
Change-Id: Ib68495a2e3b34f92a4971dd6b32b7bc6c616ac23
This is a preparation for File-Based Encryption (FBE) support in IMMS.
In order to support File-Based Encryption (FBE), IMMS needs to reset
its internal state exactly when the device is unlocked by user first
time. This is important because IMMS would recognize only
encryption-aware input method services until the the device is unlocked
by the current user.
Even if we reset the internal state when the device is unlocked by the
current user, there are still two tricky points.
1. Except for the initial boot, IMMS uses Secure Settings to determine
what IMEs are enabled and what IME is currently selected. These
persistent state may not be suitable for the situation where the
device is not unlocked yet, because some of IMEs referenced there
may or may not be encryption-aware. Depending on the situations,
we may need to enable at least one encryption-aware IME to ensure
that the user is able to type password to unlock the device, even if
such an IME is not Settings.Secure.ENABLED_INPUT_METHODS. We have
to be careful when doing this because we don't want non
pre-installed IMEs to be enabled until the user approves it.
2. IMMS tends to save its internal state into Secure Settings.
However, because of the point 1, we may need to automatically enable
a certain IME to make sure the user is able to type even when the
device is not unlocked yet. We don't want such a temporary state
to be persistent in Secure Settings.
The basic idea of this CL is to implement Copy-On-Write (COW) mode in
InputMethodSettings so that we can later discard any changes made before
the device is unlocked. As the initial step, we start using this COW
mode until the the ActivityManager becomes ready. With this change we
can revert a previous commit [1] for Bug 6685037, where forward-locked
encrypted apks need to be taken care of an early boot phase.
[1] Ifb311f85154beadd4787ec73669bedfdf1f5172d
4c0e7152e7
Bug: 26279466
Change-Id: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
Move pieces of the detail panel from the header and QSPanel to be
in a single container to make the enter/exit be handled better
and code cleaner.
Change-Id: Id1e79b96830ee50051e340fb09ecde537a64e516
Refactor setPackageSuspended into setPackagesSuspended. The rationale
is that the consumers of this API are likely to want to remove
multiple packages at once. Rather than calling the API N times, call
it just once.
The good part is that we already have the broadcast intent for
suspended packages take an array so only one broadcast. Less stress
on the system.
Another good part is that (right now) we only have one consumer of
this API and it will be easy to make changes once this CL goes in.
As a shell command, for consistency only allowed one package at
a time.
Bug: 22776761
Change-Id: Ic8b8cf64d0a288ea3a282bb7b72f9d663b3b0049
Always keep all the files of the remote bugreport
operation and keep them for at least a day.
Bug: 27215341
Change-Id: I514956004bf982e868a87b39c705d7c4a4a7b001
Previously, all results from runner thread - both for preflight
or full backup pass were ignored.
This change adds two synchronized method to get preflight result
and result of full backup pass.
This leads to better coverage of AGENT_ERROR to return in callback
as a result of backup operation.
On the other side we won't start backup pass in main thread
if preflight check hasn't been succeeded.
Change-Id: Id5f9e4c956a1bd5c396d59b7ad2098139a15e69d
