clearForwardingIntentFilters removes only non-removable IntentFilters.
The ForwardingIntentFilters set by the profile owner are always removable.
Change-Id: If950ccd7e69261b86360ea647fdb501c92f5440b
The package manager service maintains, for some user ids, a list of forwarding intent filters.
A forwarding intent filter is an intent filter with a destination (a user id).
If an intent matches the forwarding intent filter, then activities in the destination can also respond to the intent.
When the package manager service is asked for components that resolve an intent:
If the intent matches the forwarding intent filter, and at least one activity in the destination user can respond to the intent:
The package manager service also returns the IntentForwarderActivity.
This activity will forward the intent to the destination.
Change-Id: Id8957de3e4a4fdbc1e0dea073eadb45e04ef985a
Pass the setting along to UserManager.
Fixes a security exception when fetching the profile's enabled state.
Change-Id: If71698cf32c52cce1158cf2027443a339bc58488
Add a new enabled state for a managed profile.
Expose that as a new API on DevicePolicyManager.
Set the new state when enabling the profile.
Return only enabled profiles from the user manager.
Bug: 13755441
Bug: 13755091
Change-Id: I2907b182e19b3562592da688b3f68ef5f4088557
Simple wrapper around the UserManager.{get|set}ApplicationRestrictions
APIs. Also added a new Intent to signal to running apps that the set
of restrictions has changed since startup.
Change-Id: Ifd108108a73f87325b499d9de2e1b2aacc59b264
Passing in the name of an actual admin should be enough to pass the
security check as it was. This is now fixed as the caller is not
given the opportunity to spoof its own name any more.
Change-Id: Id8be4ca4c8bf3751a1ee8125cf119fa100c81d22
Those intent handlers are persistent preferences. They will remain the default intent
handler even if the set of potential event handlers for the intent filter changes
and if the intent preferences are reset.
Change-Id: Id0cfae46f93c10d89e441f272096a205ec518dd0
Creating a profile owner when there is no device owner present also
creates a new DeviceOwner object without packageName set -- this
situation can lead to a null pointer access when calling isDeviceOwner.
Change-Id: I31eab498d78cadc67a1aedd205b458dee2d27705
Previously the userId of the current process used but it
makes the provisioning process cleaner to be able to pass
it in explicitly.
Change-Id: I670c4cf3638f1340f6d0bf856c3e01045df8c29e
This change simplifies the process of initializing a SystemService
by folding the onCreate() step back into the constructor. It removes
some ambuiguity about what work should happen in the constructor and
should make it possible for services to retain most of their final
fields after refactoring into the new pattern.
Change-Id: I25f41af0321bc01898658ab44b369f9c5d16800b
ProfileOwners, like DeviceOwners, are Device Admins that have
additional priviledges. ProfileOwners however are scoped per
user.
Change-Id: I1e22c85878e0672121e6ebbe97fca38591f992b2
At startup, we check with PackageManager whether a system service is
available before attempting to load it. A system service is available
if its associated feature (similar to hardware features) is present.
This does not remove unavailable services from the compiled jar.
Change-Id: I13571805083aa4e65519a74acb52efd17b9fb3d7
These services can now be excluded by modifying the list of REQUIRED_SERVICES (TB renamed)
Changed appwidget, devicepolicy, backup and print services.
Change-Id: Id8e2855d5c045cd57bdb02dca9ed75172803bce7
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
