Moved functions which parse the USB functions list into one common
place on UsbManager.
Deleted the no longer supported USB_FUNCTION_MASS_STORAGE.
Ensured that the UserManager.DISALLOW_USB_FILE_TRANSFER rule is
consistently applied during user switch and when changing the
current USB functions and make sure it only affects MTP and PTP.
Collapsed the boot completed and user switched receivers to
ensure consistent ordering of side-effects.
Validate the list of functions passed to setCurrentFunction() so
that the separation of concerns is clearer. It was somewhat
ambiguous as to whether functions such as ADB could / should be
enabled through that interface. Improved the docs for clarity.
Fixed a bunch of broken stuff related to the USB config
persistent property (list of default functions) that could cause
ADB and other functions to not work at all. Added new failsafes
to ensure that we reliably get back into a happy state.
Bug: 22206076
Change-Id: I02915ddfce7193a8f67a14f0d76bab22fc575dfa
Add per user versions of mute methods so
device policy manager can mute the correct
user.
Just persist change if the calling user
isn't the current user.
Treat calls to audio manager coming from uid
1000 as if they were coming from current user
rather than user 0 so that the correct user's
user restriction is checked.
Bug: 21782066
Bug: 21778905
Change-Id: I51469b741096d8a2ffdc520eaf5b3fd754f2c819
Otherwise after the Device Owner is gone, runtime
permissions might still be auto granted/denied.
I understand that there are many other policies that
we don't reset after the device/profile owner goes
away (e.g. keyguard enabled/disabled). At least now
we have a single method when we could clear the
ones that we care about.
Bug: 21889278
Change-Id: I6997655e6ef6d474bd25ae1c323eca5b17944b16
Clarify docs that runtime permissions can be granted or revoked by
a profile owner/device owner only for MNC apps and not legacy apps.
Check the targetSdkVersion and return false if legacy app.
Remove all policy flags from permissions when cleaning up
a device or profile owner.
Bug: 21835304
Bug: 21889278
Change-Id: I4271394737990983449048d112a1830f9d0f2d78
Even though the documentation of DISALLOW_CREATE_WINDOWS says it is for
Device Owners and Profile Owners on User 0 only, it was previously not
part of DEVICE_OWNER_USER_RESTRICTIONS and was therefore callable from
a profile owner on a managed profile or secondary user.
Bug: 19726884
Change-Id: If6443eacbc28b7ee6c0845754923573a79f8bde3
This setting controls whether WiFi configurations created by a Device Owner app
should be locked down (that is, editable or removable only by the Device Owner).
Bug: 21427528
Change-Id: I0f8fb72bf9da1597e08d3dfc631d37b6b4178ff5
It was querying for permission of user 0 instead of the calling user.
Switched to passing in the explicity userId.
Also set the flags before granting/revoking permission from DPM.
Bug: 21430988
Change-Id: Id0d2dc65e20108cefa3eeb4363f866d49c791cc4
- Remove ManagedProvision Bluetooth extras from
DevicePolicyManager
- Remove ManagedProvisioning device initializer status
action and extras from DevicePolicyManager.
- Remove DIA status update protected-broadcast
and permission
- Remove DPM.sendDeviceInitializerStatus method
Bug: 21559093
Change-Id: Ibb651ebb2772ace6a16a5830f82f75465150e6e3
We have APIs for a DO/PO to fix a permission in a granted or
denied state in which the user cannot manage this permission
through the UI. However, there is no way to go back to the
default state in which the user gets to choose the permission
grant state.
Change-Id: I2562a1d8b1385cd740b44812844ef14c895c2902
Because DeviceAdminReceiver is protected by BIND_DEVICE_ADMIN permission,
in order to send broadcast to it, we need to clear the caller's identity
and call sendBroadcastAsUser() as system.
Bug: 20213644
Change-Id: Icc7b239b9005e286012ade6580ec92a0a57198e0
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
Uri provides a stronger guarantee of well-formedness and lets apps do
nice extra things like specifying scheme etc. without twisting any
expectations.
Bug: 20820034
Change-Id: Ia6bbedb74765444920b667d643fb7e1eb6a7292b
* Introduce a new "charger only" mode. In this mode, MTP is disabled,
and no file transfers can occur.
* Make charger only mode the default.
* Modify "persist.sys.usb.config" so it now only holds the adb status.
* Make the USB settings non-persistent. Unplugging the USB connection will
reset the device back to "charger only" mode.
* Fixup wording per UI guidelines.
TODO: Re-implement MDM restrictions for USB / MTP access controls.
Bug: 18905620
Change-Id: I99a50d9132a81e98187f431166fd9fef4d437e4f
We now maintain a mata-state with each permission in the form of flags
specyfying the policy for this permission. This enables support of the
following use cases:
1. The user denies a permission with prejudice in which case an app cannot
request the permission at runtime. If an app requests such a permssion
it gets a denial unless the user grants the permission from settings.
2. A legacy app with disabled app-ops being upgraded to support runtime
permissions. The disabled app ops are converted to permission revocations.
The app ops manager is a part of the activity manger which sits on top
of the package manager, hence the latter cannot have a dependency on the
former. To avoid this the package installer which is the global
permission managment authority marks the permission as revoked on
upgrade and the package manager revokes it on upgrade.
3. A device policy fixing a permission in a granted or revoked state. This
additional information is folded in the meta-state flags and neither
apps can request such permissions if revoked not the user can change
the permission state in the UI.
Change-Id: I443e8a7bb94bfcb4ff6003d158e1408c26149811
Allow admins in managed profiles disable trust related
keyguard features (trust agents and finger prints) for the
parent user.
Allow admins in managed profiles to control whether notifications
from the profile are redacted on the keyguard.
Bug: 18581512
Change-Id: Ic2323671f63781630206cc2efcc8e27ee58c38e6
Make SystemUpdatePolicy Parcelable; hide public constructor and
expose static builder methods.
Bug: 20820025
Change-Id: I594ba3c7e5514551134ba6c866b24498b66506bf
Rename the DevicePolicyManager functions setKeyguardEnabledState and
setStatusBarEnabledState to setKeyguardDisabled and
setStatusBarDisabled respectively.
Bug: 20820039
Change-Id: I06f6a19ac55b24e66e9f2cb340ead5d940cb2235
Managed provisioning does not currently set a meaningful profile owner
name. This changes to use the application label as returned by
PackageManager.getApplicationLabel which should be more descriptive.
Bug: 20679292
Change-Id: I5a0e87ef05b62879a73814e6d338e8b984b81c94
Profile owners and Device owners can set policies for runtime
permissions. Blanket grant/deny policy can be set for a user.
They can also explicitly grant/revoke permissions for specific apps
which cannot be overridden by the user and will not be prompted.
[More implementation required in PackageManagerService and
PackageInstaller]
Bug: 20666663
Change-Id: I2c25c18c2a195db9023a17716d5896970848bb45
This activity will launch by default on device reboot or user switch
during user initialization, even if there are higher priority 'home'
activities.
Bug: 20223050
Change-Id: I335aeb010a1ae5db07a4343d26e160c74bd299e1
