Remove @hide, and add parameter for specifying profile owner. The PO
has to live in the same package as the device owner.
Bug: 25288732
Bug: 25860170
Change-Id: I40e8984a71ee9d1ff74e57d4e79e298deef9bc35
Add explicit modelling of provisioning state so that integration
of management provisioning flows with packages such as setup-wizard
are cleaner, and can be more direct. Previously we relied upon
USER_SETUP_COMPLETE secure setting and HOME intents to signal intent,
but this is not very clear and can be fragile.
Bug: 25858670
Change-Id: Idc56a040f710c3aee281db420f21717da3960722
This is a reduced version of the (deprecated) function
createAndInitializeUser, that allows the device owner to create a
new user and pass a bundle with information for initialization. The
new version of the function has the same functionality, but the
profile owner of the new user is always the device owner.
A flag can be specified to skip the setup wizard for the new user.
The new user is not started in the background, as opposed to how
createAndInitializeUser did it. Instead, the bundle with
initialization information is stored and will be broadcast when the
user is started for the first time.
Bug: 25288732, 25860170
Change-Id: I4e1aea6d2b7821b412c131e88454dff5934192aa
A user/profile is considered affiliated if it is managed by the same
entity as the device. This is determined by having the device owner and
profile owners specify a set of opaque affiliation ids each. If the sets
intersect, they must have come from the same source, which means that the
device owner and profile owner are controlled by the same entity.
BUG=25599229
Change-Id: I393fe0de70272307ed3c811aaba4b48a5109c562
Adding a policy for profile owners to set the background color of the
confirm credential screen for the managed profile.
Bug: 26638631
Change-Id: Iea36b94c5a42b6ae12cc36921ec5f840306e81a1
The calls to LockPatternUtils#isSeparateProfileChallengeEnabled
require MANAGE_USERS permission, wrapped them in a clear identity
Bug: 26565169
Change-Id: I4a18cec3ae7beb13320350d4c3fdc63e4a7d741d
Change the current static condition to a per-user condition so we
can check and enable/disable the work challenge properly. Also add
an isAllowed API, as the Work Challenge can only be used when the
user's DPC targets N or above to maintain backwards compatibility.
Change-Id: I0cb8b475838816801868ffb24726407aa257b4de
This change creates the infrastructure for a parent
DPM and implements the actual parent APIs for
- set/getPasswordQuality
- isActivePasswordSufficient
This is part of the Separate Work Challenge
Change-Id: I0477051b3162cbb26aac79467da08932f22fd1b7
When hidden PackageManager methods take a userId argument, they
should be named explicitly with the "AsUser" suffix. This fixes
several lagging examples so that we can pave the way to safely
start passing flags to new methods without scary overloading.
Also fix spacing issues in various logging statements.
Change-Id: I1e42f7f66427410275df713bea04f6e0445fba28
The device or profile owner can allow another
package to set app restrictions for any app in that user
Similar to the way it can give permission to access
CA certificate related APIs from M.
Bug: 22541936
Change-Id: I0c1b0804ad300dfa4fbdc1c7721c5d8653d77861
Adds APIs in DevicePolicyManager and PackageManager for allowing
a device admin to suspend a package. PackageManagerService sets
or unsets a new PackageUserState 'suspended' setting. Terminal
command to suspend/unsuspend has been added via
PackageManagerShellCommand (as root).
Next steps:
* use the new 'suspended' setting for denying access to start app
(probably in ActivityStackSupervisor)
* broadcast a PACKAGE_(UN)SUSPENDED intent for launchers to pick up
* remove app from recents (go further and kill it if it is running)
* erase existing notifications for this app
Bug: 22776576
Change-Id: I718b3498f6a53cc0c6fdfb6d15031e53ddca4353
Adding new policy in DPM to trigger reboot on the device.
Requirement: Device owner can reboot the device if it is stuck or is
not useable due to some unresponsive UI.
Bug: 25304994
Change-Id: I7a6d5c8ad611de9c1cf6619378e492a306b41626
Preventing apps with MANAGE_USERS from managing application
restrictions via UserManager. Application restrictions should
only be set via DevicePolicyManager.setApplicationRestrictions,
or via Settings (for restricted profiles).
Bug: 22541936
Change-Id: Ieed51ef54b4c23a73f383465e9af9b3bcf18a514
The keypair is specified by alias and removed via a call to the
KeyChainService, which will have installed the pair in the first place.
Bug: 22541933
Change-Id: I37317e7c22e89816156e6e9a7abf4c5a59e8440a
When per-user encryption is set up and we change the password of a
profile, the parent and other profiles shouldn't receive an
ACTION_PASSWORD_CHANGED as they have their own distinct passwords.
Change-Id: I70d4ec81277a9bdc3ac6cd952b84cd769a2800b4
This allows us to tell lock checks from FBE checks separately,
and will be useful when dealing with password unification.
Change-Id: Ifbea425f749fee4d6d51faddd8b64bf717a1a5f8
When the Work Challenge is in place, re-route the
enforcing of Admin policies on the password to the
work profile. The Admin should not be allowed to
dictate policies on the device lock in this case.
This is part of the Separate Work Challenge feature.
Change-Id: I757973e540797b5fb10bea7a2fd1925561655bc9
For some markets we have to allow the user to review permissions
for legacy apps at runtime despite them not supporting the new
permission model. This is achieved by showing a review UI before
launching any app component. If an update is installed the user
should see a permission review UI for the newly requested
permissions.
To allow distinguishing which permissions need a review we set
a special flag in the permission flags that a review is required.
This flag is set if a runtime permission is granted to a legacy
app and the system does not launch any app components until this
flag is cleared. Since install permissions are shared across all
users the dangerous permissions for legacy apps in review mode
are represented as always granted runtime permissions since the
reivew requirement is on a per user basis.
Whether the build supports permission review for legacy apps is
determined by a build constant allowing us to compile away the
unnecessary code for markets that do not require a permissions
review.
If an app launches an activity in another app that has some
permissions needing review, we launch the permissions review
UI and pass it a pending intent to launch the activity after
the review is completed.
If an app sends a broadcast to another app that has some permissions
needing review, we do not deliver the broadcast and if the sending
app is in the foreground plus the broadcast is explicit (has a
component) we launch the review UI giving it a pending intent to
send the broadcast after the review is completed.
If an app starts a service in another app that has some permissions
needing review, we do not start the service and if the calling app
is in the foreground we launch the review UI and pass it a pending
intent to start the service after the review is completed.
If an app binds to a service in another app that has some permissions
needing review, we schedule the binding but do not spin the target
service's process and we launch the review UI and pass it a callback
to invoke after the review is completed which spins the service
process and completes the binding.
If an app requests a content provider in another app that has some
permissions needing review we do not return the provider and if
the calling app is in the foreground we show the review UI.
Change-Id: I550f5ff6cadc46a98a1d1a7b8415eca551203acf
