If the broadcast could not be queued due to a stopped user, the
party trying to send a PendingIntent should be notified right away.
Otherwise, for instance, AlarmManager could be waiting forever to
be called back after the broadcast is delivered.
This is a potential fix for:
Bug: 18290018
Change-Id: I07c0751e80f11e69dfa2be5c96a033aecb298b81
The heavy implementation of the backup manager service is now sitting
behind a lightweight trampoline that actually provides the binder
call interface. The indirection allows us now to tear down the
implementation on the fly without breaking callers who have cached
binder references to the backup services: these callers will simply
see their future invocations failing benignly.
In addition there is now an API for suitably privileged callers such
as device policy management to effect this turndown.
Finally, there is now a static system property, "ro.backup.disable",
that a product can use to outright remove backup/restore operation
from the system's operation. The public APIs will continue to be
safely usable on such products but no data will be moved to or
from the device.
Bug 17367491
Change-Id: I8108e386ef3b5c967938fae483366d6978fe4e04
This change incorporates API council feedback and enables the
TrustAgent whitelisting API.
It also contains a minor cleanup of DPM's use of UserHandle
to eliminate unnecessary object creation.
Fixes bug 17008504
Change-Id: I63cc50169fde54b34406845818bcaf6aadc1a3db
We previously killed a process when one of its task was
swiped away in the recents UI. This had negative performance
implications for apps with multiple tasks in recents. Now we
will only kill the process if there are no more tasks associated
with it.
Changed also removes the need for the
ActivityManager.REMOVE_TASK_KILL_PROCESS since ActivityManager
will now only kill a task process if it process has no out
standing tasks.
Bug: 17305377
Change-Id: Ibc39bb328d13c7eab05c04798c2f14887923d9d4
Add two small developer apis to wearable extender to help developers
show barcodes on different shaped wearable screens.
Bug: 16299175
Bug: 17005635
Change-Id: I05088ffcc405c69f1e8df7bf967ea930548c7d51
The fix for bug 16555230 attempted to return the same LoadedApk
object between the system context object and the activity thread's
list of opened packaged. This ensured that we used the same classLoader
on both these objects (among other things).
However, the object the Context owns is actually incomplete (and
necessarily so) because it might be created before the package
manager is and we need the package manager to construct a complete
LoadedApk object.
Work around this by manually setting the classloader and aInfo for
"android" contexts created by the system server's activity thread.
bug: 18167468
Change-Id: I623634f912111f89eaf716b8258d1926d2513dcd
Bug 18073470
Shared element ordering was based on the key ordering in an
ArrayMap. This is normally fine, but when shared elements
are nested, the child's layout can be overwritten by the
parent's if it is laid out first. The only way to force the
ordering of shared element layout was the change the transition
name. To fix this, shared elements are now laid out parent
first, then child.
On return, nested shared elements were not transitioning to their
final destination properly because the matrix used to calculate
their position was not correct. This change recalculates the
parent matrices when appropriate.
Change-Id: I62333183cf03519e525587e4ea31fcf14bb83cdc
