This allows work profile MDM to enable unknown sources
even if the user doesn't have UI for it. Installing an
app from an unknown source will still prompt the user
with the package installer dialog, so it's not like the
MDM can now quietly install apps from non-market sources.
Bug: 18316350
Change-Id: Ia8f4fe36f12a258aa888e085acc0b358925f4817
This expands the use of EXTRA_REFERRER to be relevant anywhere,
allowing apps to supply referrer information if they want. However,
if they don't explicitly supply it, then the platform now keeps
track of package names that go with Intents when delivering them
to apps, which it can be returned as the default value.
The new method Activity.getReferrer() is used to retrieve this
referrer information. It knows about EXTRA_REFERRER, it can return
the default package name tracked internally, and it also can return
a new EXTRA_REFERRER_NAME if that exists. The latter is needed
because we can't use EXTRA_REFERRER in some cases since it is a Uri,
and things like #Intent; URI extras can only generate primitive type
extras. We really need to support this syntax for referrers, so we
need to have this additional extra field as an option.
When a referrer is to a native app, we are adopting the android-app
scheme. Since we are doing this, Intent's URI creation and parsing
now supports this scheme, and we improve its syntax to be able to build
intents with custom actions and stuff, instead of being all hung up
on custom schemes.
While doing this, fixed a problem when parsing both intent: and new
android-app: schemes with a selector portion, where we were not
respecting any scheme that was specified.
Change-Id: I06e55221e21a8156c1d6ac755a254fea386917a2
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
Bug 18191727
Transitions were targeting specific views, but they do this by
adding targets. If there was already a view targeted, now that
transition also targeted a different view. This prevents that
by only targeting views when no target was given.
Change-Id: I50590a81c1c1c55b1624f8df848ab53731f7e8e1
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
