Previously DMAgent would apply these lockdowns before/
after setting the matching user restrictions.
Bug: 16701642
Bug: 16945830
Bug: 16944983
Change-Id: Ib4f7145055687f12408d6ccacd8e6380406a32b2
We set the system_server classpath in the environment
(like we do with BOOTCLASSPATH). After the zygote forks
the system_server, we dexopt the classpath (if needed)
and then launch the system server with the correct
PathClassLoader. This needed several small / medium
refactorings :
- The logic for connecting to installd is now in a separate
class and belongs in the system_server.
- SystemService / SystemServiceManager have now moved to
classes.jar. They are only used from there, and since they
use Class.forName, we want them to be loaded by the
system_server classloader, and not the bootclassloader.
- BootReceiver now moves to frameworks.jar, because it is
used by ActivityThread and friends.
bug: 16555230
Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
When the maximum number of retries that has been exceeded is not for the primary profile of the user, wipe only the profile that set that policy (e.g. the managed profile) rather than the entire user. At the moment the whole device is wiped if the max number of incorrect passwords for a managed profile is reached, as the password is shared with the USER_OWNER.
Bug: 14453697
Change-Id: I5746de104133c0ea0a51d75b9c92e1516d365d8c
The goal of this change is to enable support for appwidget from
user profiles to the user main profile. A user profile is a user
which is associated as a child of the main user profile. For example,
a user may have a personal (parent) and corporate (child) profile.
The device policy should be able to control whether adding a widget
from a child profile and given packages is allowed. This change
assumes that all packages from managed profiles are white listed.
Another change will add the device policy changes.
Change-Id: I267260b55d74c48b112a29979a9f59eef7a8194e
Removed all communication from wm to device policy manager.
Added initialization of cache in wm by dpms.
Change-Id: Ifa0b8bfcd625464b156d5cc0fb66d342deda1c27
The activity manager should know when to lock the screen. If an admin
does want this to happen then they should be able to run both commands
in succession.
Also rectifies some creative code styling in the same DPM method.
@bug 15558805
Change-Id: I8918184a4585aa8b061eb4a68edc2ec6805d8127
priv apps can request to become a profile owner after setup has
completed. This will pop up a consent dialog (in Settings).
Also, clean up profile owner concept to be a component name.
Change-Id: I5e8532866e8018f61836c4e84fbbadb6150218ae
This adds a new feature that allows a device admin to specify a
whitelist of features that are allowed for the given admin.
Change-Id: I83f853318efbcf72308532d0a997374f73fa9c10
When we add a CrossProfileIntentFilter, we store the package and userId of the calling app
inside the CrossProfileIntentFilter.
When an app calls clearCrossProfileIntentFilters, we only remove the filters that the calling app
has set itself.
BUG: 16537557
Change-Id: I6e7bc859383ea66553d9f4230365df8ba27525f3
WindowManager will set secure flag on SurfaceControl for
all windows of a flagged user to prevent screen capture.
API is consistent with the camera disable API.
Change-Id: Ib180f67f1ad827b6f4aca2af615274256cce58f4
Using a background broadcast is bad, it can take a long
time to get the message back, either accidentally (backed up
behind other broadcasts) or from a deliberately malicious
admin.
Change-Id: Ib7491f8e27dacdc002562aef027ee4664e78e97b
loadSettingsLocked() was being called twice for USER_OWNER at
systemReady(), doubling the number of admin entries at every boot.
Also guards against double-adding admins which appear twice in the
same XML file, favouring more recently-refreshed entries for
backward compatibility.
Previously an application calling in with 'refreshing = true' would
double-insert whatever admin was being refreshed into its user's list
of device admins. This is fixed too.
@bug 16416936
Change-Id: Idd147aa130e6bce7bcc40532f0a7fb07117b3151
No need to enforce that the caller is in the system process.
We're only checking if the device policy is allowing access.
Bug: 16301261
Change-Id: I87a7c808d116c86aa68cebb36631c46d0a54be96
This corrects the expected behavior of the app state. Hidden apps
can be installed by the store to be brought out of hidden state.
Bug: 16191518
Change-Id: Id128ce971ceee99ba1dea14ba07ce03bd8d77335
Contact information in the managed profile is shown
in the incoming call UI unless blocked using this API.
TODO: Actually plumb this into the caller-id logic.
Bug: 16301261
Change-Id: If03adc907d9558baa0a45a1833b857206b7bf96a
This is to ensure that some system app can't modify that
state for purposes of changing the profile owner without
user consent.
Bug: 16207721
Change-Id: Ic5f454d7568cd824b83456eed0e2611779a9adf8
We need to go back to uninstalling system apps so we can
re-install non-default system applications through Play.
This reverts commit e3dbcd138c07f2d32ac84229d0a49052cc18d424.
Change-Id: I0a7af094614c4a10800971c82e10571f7312e079
Once verified that caller is device owner just calls through to
the activity manager and acts like that call.
Change-Id: I34023313cd6742b73d2105655ec6b631879aa37a
This adds a feature to allow DevicePolicyAdmins to prevent using
simple PINs, which are defined as those containing more than 3
repeated values. Examples include '1234', '2468', '1111', '9876', etc.
Bug 12081139
Change-Id: I4ebe1c76a48087dcd7c878e9bd79a4e3ee2a27fe
Add package state to allow profile or device
owners to block uninstall of packages.
Add API to DevicePolicyManager to set/get the
state.
Bug: 14127299
Change-Id: I03528819850b42df7bafa7747bb9e4558d20c4e6
Instead of sending the profile name in the provisioning intent
the mdm should set the profile name after provisioning has completed.
This allows us to simplify the provisioning flow and the mdm can
change the name of the profile later on if required.
Change-Id: I821ef2300eae74e89872152ae1c89ac3ecbb82e7
Since managed profiles are started on bootup, the managed profile
would be allowed to set an app (possibly itself) as a lock task
app and then run itself on bootup and constantly control the
device. This privelege should be restricted to device owners.
Change-Id: I4a93aabd6054cbe75076ef0517fce03ffa74dc93
For these crossProfileIntentFilters, the activities in the current profile cannot
respond to the intent.
Only activities in the target profile can respond to the intent.
BUG: 14936725
Change-Id: I5e2704c2b56ff50a8339dd49284956391d7fad7e
Add a method for DeviceAdminReceivers of profile/device owners to
be notified that lock task mode has entered or exited for an app
they have whitelisted.
Change-Id: Id124287d41564bbfccdacccf1977b7acb3ddec3f
Exposes these methods:
- hasCaCertInstalled
- hasAnyCaCertsInstalled
- installCaCert
- uninstallCaCert
Allows device and profile owners to perform some certificate management
including querying for and enabling/disabling specific CA certificates.
Change-Id: I4aa8a1a8601b234e30acde99dfa382e04cb62495
Currently the device owner can create secondary users, but unless
it is a system app it will not be installed and will not be able
to pass data easily from the code that creates the user and any
code running on that user.
This allows the device owner to install itself while creating a
user and start up a service to configure that user. createUser
takes an bundle so that the device owner can pass across any
initial setup data it needs to, this bundle will be sent to
the admin receiver in onEnable.
Change-Id: Ic1f8565dd2a7bd85363527cf68b0ecd4dc9c3636
Now throws an exception titled something like "Admin X does not own the
profile" instead of the rather unhelpful NullPointerException that was
thrown previously.
Change-Id: I33f6da5ea5eb70d8ea3939cfa280c794b01c3382
