Device owners can update Settings.Secure and Settings.Global settings.
Profile owners can update Settings.Secure settings.
DMAgent currently needs to live in /system/priv-app in order to
(among other things) update global and secure settings. This change will
get us closer to being able to move DMAgent out of priv-app.
Bug: 14965414
Change-Id: If2cc3a56de91bffde33b838ab8ecea2c32412803
This makes the DevicePolicyManagerService and UserManagerService
push the DeviceOwner/ProfileOwners and user restrictions on boot
as well as on any change.
This also adds a list of restrictions that allow any op to connected with
a user restriction such that it will return MODE_IGNORED when the user
restriction is present (except for the device/profile owner).
Change-Id: Id8a9591d8f04fe5ecebd95750d9010afc0cd786c
A managed profile will now share password settings with its parent.
- the current password is always stored in the parent
- admins of profiles are notified if that password changes
- checks for password quality now take the requirements of admins on
the parent and its profiles into account
Todo:
- Currently KeyguardSecurityContainer wipes the whole device when
the maximum fails has been reached on any profile.
We need to limit the wipe to the profile for which the fails exceeded
the maximum number.
- Intents with ACTION_SET_NEW_PASSWORD need to be forwarded to the parent
of the profile when sent from a managed profile
Change-Id: I8532c59f753f8d9c61200f553f275214ad90276e
Here we let DevicePolicyManager keep a list of tasks that are
allowed to start the lock task mode. This list can only be set by
a device owner app. The ActivityManager will call
DevicePolicyManager to check whether a given task can start the
lock task mode or not.
Change-Id: I650fdae43fc35bf9fd63452283f4e2bbadd11551
Bug: 14611303
of accounts.
The account types with disabled account management are stored in a
blacklist in the active admin object, editable by profile owners.
Change-Id: I57dc5f709ad79674fa28dd006969283585daea24
These methods allow profile or device owners to enable
systems apps pre-installed in the primary user in the
managed profile. Apps can be specified by either package
name or intent.
Bug: 13587051
Change-Id: Ifcbc68c139308506b6c18cf3c0ea62b8026ff75f
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
