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
This is a mechanical replacement of Context.getSystemService(String)
with Context.getSystemService(Class<T>) when retrieving
InputMethodManager. Note those are bundled code. Hence we don't need
to make sure Build.VERSION.SDK_INT >= 23.
Change-Id: Icc64942ad8f11e44bf84f8d4fe476b2fdd1257f3
- Also make sure DPMS.mOwners is always guarded with DPMS.this.
(and remove synchronization from Owners.)
Bug 25796840
Change-Id: I83f7b78e7b437d9c2a2b1d6e714346cd15f95330
- DPM.setActiveAdmin() will not accept DAs without BIND_DEVICE_ADMIN
when it's targeting NYC or above.
- DAs without BIND_DEVICE_ADMIN targeting MNC or below will still be
accepted. (with a logcat warning)
- DAs that are already set on a device without BIND_DEVICE_ADMIN
will still be accepted regardless of the target API level, even when
it's upgraded to a version targeting NYC.
Bug 24168653
Change-Id: I1914c2ec99135d9dd8cbac3f6914f9e43bafacc8
- Previously on MNC, they would return the same result regardless who
the calling user is.
- Now they properly take DO user-id into account. Meaning, they'll
always return false and null respectively, if the calling user doesn't
run device owner.
- Note isDeviceOwnerApp() is a public API and getDeviceOwner() is
a system API. Meaning we're changing the behavior or non-private
APIs.
- Also cleaned up hidden APIs, and gave them explicit suffixes
to avoid confusion. Bundled code should prefer them for clarity.
Now we have:
* APIs that work cross-users: They all require MANAGE_USERS.
boolean isDeviceOwnerAppOnAnyUser(String packageName)
ComponentName getDeviceOwnerComponentOnAnyUser()
int getDeviceOwnerUserId()
boolean isDeviceOwnedByDeviceOwner()
String getDeviceOwnerNameOnAnyUser()
* APIs that work within user. No permissions are required.
boolean isDeviceOwnerAppOnCallingUser(String packageName)
ComponentName getDeviceOwnerComponentOnCallingUser()
Bug 24676413
Change-Id: I751a907c7aaf7b019335d67065d183236effaa80
Adding method isManagedProfile() and isSystemOnlyUser() for DPC to know
if running in a managed profile or system only user
Bug: 24464823
Change-Id: I79974fdfd60d2bfe52dee3b4c95becf47a5bf0b1
Now that we don't have UM.setUserRestriction*s*() that could remove
all existing restrictions, there's almost no point handling
DISALLOW_RECORD_AUDIO differently.
Now DISALLOW_RECORD_AUDIO is handled just like other restrictions,
except we don't persist it.
Bug 24954662
Change-Id: I27875b4a74dd95a3ce6bb774081eeaf718eaec15
This policy allows DO to specify a list of apps to cache even without being
installed on any user.
Bug: 23938464
Change-Id: I2eeab7f148409739fc23a5c44e955ad12b63fd04
- Now when DO/PO sets a user restriction, DPMS pushes it to UMS and
then UMS persists it, in order for UserManager.hasUserRestriction()
to never have to talk with DPMS, which would cause lock inversion.
- Also apply user restrictions when a user start.
- This is an updated version of the abandoned CL -- the difference
is, ActivityManager no longer has to call DPMS.
- Also removed an unnecessary write to userlist.xml in UMS.
upgradeIfNecessaryLP().
Bug 23902097
Bug 25388912
Bug 25354031
Bug 25641040
Change-Id: I0948aea06ad7d0f45fe612a431d765faddfe3c58
The old check looks a lot like an equality check, but it's not valid
because two passwords can share the same parameters.
For example:
'11Aa' and
'Y99z'
Are not different according to the old logic.
Bug: 25319928
Change-Id: Ia69861d9103670d1fc1dbf0130516e18e85e8de0
Add new "am unlock-user" command so we can trigger changes from the
command line.
Move FBE check to static method so it can safely be called early
during boot before the mount service is ready. Move FBE emulation
to persisted system property, and start reading/writing that value.
Change default permission grants to ignore current encryption-aware
flags, since many of the target apps aren't crypto aware.
Always prepare package data directories, which is how we create the
new "user_de" paths during boot.
Bug: 22358539
Change-Id: I6f58ea2d34b3a466d3775d614f8a13de92272621
Split-user systems will allow for combinations of management modes,
specifically managed-{user,profile} on systems with a device-owner.
Bug: 25671630
Bug: 25680065
Change-Id: I5716f55eb6c8318129b4614adc22897d53901bee
