Most apps that declare the INTERACT_ACROSS_PROFILES permission do
not have it granted, but get the app-op instead. We do not
normally want platform-signed apps that are actually given the
permission to appear in the user-configurable section in Settings,
so we remove them from the return value of
canUserAttemptToConfigureInteractAcrossProfiles in this CL.
Note that OEM can choose to allow some platform-signed apps to be
user-configurable by including them in their OEM whitelist file.
This CL respects that and allows these apps to be configured by the user,
despite being granted the permission. If the user rejects the app-op,
PermissionChecker correctly returns false.
Bug: 149742043
Test: atest CrossProfileAppsServiceImplRoboTest
Change-Id: I693338507eec9cdc0ba10a3584e994a58d2d113c
It is currently not meant for use by general enterprise device admins.
Bug: 152478326
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest KeyguardUpdateMonitorTest
Test: atest AdminSecondaryLockScreenControllerTest
Change-Id: I6d60bc35a4e8f74b1da55b042582a2f2fa89d57f
* Sort the user restrictions to local restriction
set and global bundle in DPMS instead of User
Manager.
* Simplify pushUserRestrictions.
* Split the list of user restrictions the profile
owner of an organization-owned device can set into
a global and local list. The user restrictions in
the local list will only be applied to the personal
profile as opposed to the whole device.
Bug: 149743941
148453838
Test: atest com.android.cts.devicepolicy.UserRestrictionsTest
atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.server.pm.UserRestrictionsUtilsTest
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionSetOnParentLogged
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionsSetOnParentAreNotPersisted
Change-Id: I1faa1f4776deb98e38595a358c01c3fbabfb1840
- Don't declare the plugin directly, it is exported via java_library that defines the sources.
- Remove unneeded framework-annotation-proc.
Bug: 152220864
Test: m && diff merged_compat_config.xml
Change-Id: Ie750b5391229d21679a8610780b9f8d4a997e204
Merged-In: Ie750b5391229d21679a8610780b9f8d4a997e204
(cherry picked from commit 9f5a5623a7)
This commit removes the log message from DevicePolicyManagerService
when a caller fails the access requirements as it can be confusing
if the caller subsequently passes a carrier privilege check and can
access identifiers, or in the case where the caller does not have
access a similar entry is logged by TelephonyPermissions. The subId
for which the carrier privilege check is performed is also logged
to facilitate debugging.
Bug: 152117976
Test: atest SubscriptionControllerTest
Change-Id: I6d88d739a0d9053e8eff32d74d90009699abe8fc
Background
* If the device is an organization-owned managed
profile device and a FRP policy is set, the
factory reset protection data is no longer
erased from factory reset in Settings.
Changes
* Added isNotEmpty method to FRP policy.
* Allow Settings to call
getFactoryResetProtectionPolicy
by checking for the MASTER_CLEAR permission.
Bug: 148847767
Test: manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I04f178255dd215579087c33b675b40eed7a6eac7
When checking whether provisioning of a managed profile is allowed, it
is unnecessary to check whether there's a restriction on the parent user
because the check is done from the primary user.
If the check is done from inside a managed profile, then the check
should return false because a managed profile cannot be provisioned from
within another managed profile.
The DevicePolicyManagerTest was incorrectly returning user 0 as the
"parent user" for user 0, so changed the test to return null as the
profile parent for user 0.
Bug: 147631026
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.ManagedProfileTest#testIsProvisioningAllowed
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.DeviceOwnerTest#testIsManagedDeviceProvisioningAllowed
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.DeviceOwnerPlusProfileOwnerTest#testProvisioningNotAllowedWithDeviceOwner
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.CustomDeviceOwnerTest#testIsProvisioningAllowed
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.CustomManagedProfileTest#testIsProvisioningAllowed
Change-Id: Ia62dce93265ec65b61a048c4d96f96baa4598a57
Also make use of PackageManager.getUnsuspendablePackages() which
already takes care of launcher and dialer packages and some
other critical apps, like package verifier, package
[un-]installer, etc.
For newly installed packages it PackageManager.getUnsuspendableApps()
seems to be sufficient since that app won't be critical for the
functioning of the device.
Test: Test: atest
OrgOwnedProfileOwnerTest#testPersonalAppsSuspensionInstalledApp
Bug: 149394138
Change-Id: Ic3196dbfdd5c506e708563d305a42494391dc878
Notification about personal apps suspension should only be shown
in cases when apps are suspended because of maximum work profile
time off policy violation, not via an explicit call to suspend.
+ updated strings. Note, some strings are not used yet.
Test: manual, with TestDPC, suspended apps explicitly, checked
that the notification is not shown.
Test: manual, with TestDPC, set maximum work profile time off,
adjusted the clock, checked that the notification is there.`
Bug: 151918490
Bug: 149076989
Change-Id: Idd4c7ec11af416c303c9218495d55c73154c7a5f
- Documentation clarity and method rename per API review feedback.
- Specifying in documentation and implementation that the implementing service must be exported by the Profile Owner.
Bug: 150866056
Bug: 136085151
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest KeyguardUpdateMonitorTest
Test: atest AdminSecondaryLockScreenControllerTest
Change-Id: I58175bd6cf8936f5b1267625ca15b4f9c57f4144
Per API review feedback, global settings are discouraged in favour
of fine-grained getter APIs.
Bug: 149999040
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testCommonCriteriaMode
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testCommonCriteriaMode
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: Ia810f67409ce2b482bca06f1e21df2f98d12ccfd
Add enforceNetworkStackOrProfileOrDeviceOwner() to check if the
caller has PERMISSION_MAINLINE_NETWORK_STACK or not.
Call this check in isAlwaysOnVpnLockdownEnabled() for allowing
the caller which has PERMISSION_MAINLINE_NETWORK_STACK to get the
status of always-on VPN.
Bug: 141621373
Test: 1. Build pass
2. Manual test to see if CaptivePortalLoginActivity could
deal with the issue properly.
Change-Id: I3b7ddc2543e6b4754d6eaac128ca9a8ccea6b59c
Based on API council feedback that current method names are ambiguous,
renaming them with
setUserControlDisabledPackages/getUserControlDisabledPackages.
Bug: 150865604
Test: atest DevicePolicyManagerTest
atest com.android.cts.devicepolicy.DeviceOwnerTest#testSetUserControlDisabledPackages
Change-Id: I74f07ae5f0e9b425a6f2e4aa52d2cb8ac42da68e
Revert recent changes that make DevicePolicyManager call TimeDetector /
TimeZoneDetector to change the device time / time zone.
The DPC app runs as the user, so any rules that the TimeDetector /
TimeZoneDetector wants to enforce about what the end user can do will
need to be different for the DPMS path. There will be a dedicated
(probably LocalService) code path for the DPMS to use instead.
Bug: 140712361
Test: treehugger
Merged-In: Ia60702492231cc4c7c5de157c1f266d30996d950
Change-Id: Ia60702492231cc4c7c5de157c1f266d30996d950
(cherry picked from commit 77c9fcdb10)
On devices that have a Device Owner, or had a Device Owner and Profile
Owner and the managed profile was removed, apply the restriction
for adding a managed profile.
This would prevent such devices from getting into the DO+PO mode, which
is no longer supported in R.
Bug: 149006203
Test: Manual, set TestDPC as the Device Owner, upgrade it, observe TestDPC cannot create a managed profile.
Test: Manual, have a device with different DO and PO packages, remove PO, observe it cannot be re-added.
Change-Id: Iea48049a671071d2ad075b5e4c9ae3ce830975d3
* If setApplicationHidden is called with a non-system
non-installed app, the exception thrown exposes
whether the app is installed on the personal side.
* To solve this, the exception thrown is wrapped
and a different message, which does not include
whether the app is installed, is used.
Bug: 150677248
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testApplicationHiddenParent
Change-Id: I742b5d71904e5d54cc2b353448fa043bbc7293cb
DevicePolicyManagerService needs to clear caller identity before
calling into PackageManager APIs, to make sure the app enumeration
restriction in R does not adversely affect its functionalities.
Bug: 150407679
Test: MixedManagedProfileOwnerTest#testDelegatedCertInstaller
(without the stopgap fix ag/10456865)
Change-Id: I237c527241c26a309302bc2f7e36f8007a6c53b8
* A SecurityException was being thrown because getProfiles
in UserManager cannot be called by the COPE PO for user 0
without permission MANAGE_USERS or CREATE_USERS.
* Added binderWithCleanCallingIdentity to this method.
Bug: 149941985
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testScreenCaptureDisabled
Change-Id: Iccc60233baaeaa732f197d7aaf31acc9d75a247b
Merged-In: Iccc60233baaeaa732f197d7aaf31acc9d75a247b
(cherry picked from commit 2797594914)
ADB_ENABLED historically meant the state for USB debugging. Since
wireless debugging can be enabled separately, define another setting
for it.
BUG: b/111434128
Test: make
Exempt-From-Owner-Approval: approved in aosp_master
Change-Id: If3abca8e77381d6832f55d55a43c52ee1a1267d1
When security logging is enabled on org-owned profile devices,
Security events will be redacted to preserve privacy on the personal
profile as follows:
* TAG_ADB_SHELL_CMD
Shell command will be redacted.
* TAG_MEDIA_MOUNT
* TAG_MEDIA_UNMOUNT
The media's volume name will be redacted.
* TAG_APP_PROCESS_START
* TAG_CERT_AUTHORITY_INSTALLED
* TAG_CERT_AUTHORITY_REMOVED
* TAG_KEY_GENERATED
* TAG_KEY_IMPORT
* TAG_KEY_DESTRUCTION
* TAG_KEY_INTEGRITY_VIOLATION
Only events happening inside the managed profile will be returned
to the admin.
Bug: 148437300
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest FrameworksServicesTests:SecurityEventTest
Test: atest FrameworksCoreTests:EventLogTest
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithSingleUser
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingWithTwoUsers
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSecurityLoggingEnabledLogged
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testSecurityLogging
Change-Id: I2e52229a3163b3e0dc3d80d71700023394d84587
There may be policy critical apps that must not be suspended by the
user in a managed profile. The owner can now use either of the following
to block suspension of apps:
- DISALLOW_APPS_CONTROL: Blocks suspension of all apps in the user
- DISALLOW_UNINSTALL_APPS: Blocks suspension of all apps in the user
- setUninstallBlocked: Blocks suspension of a given package.
The same also block any of the DistractionRestriction to be set via
PackageManager#setDistractingPackageRestrictions. This is to make sure
the apps can still show notifications.
Since the owner should have the final call, these do not block the owner
from adding app suspensions itself. Whenever either of these are set,
any app suspensions that were not originally added by the owner are
lifted immediately and any distraction restrictions that were added are
removed.
Also, clearing restrictions and suspensions if an app with SUSPEND_APPS
permission is disabled. Even though it is expected that UI not allow
such an app to be disabled, it is hard to enforce across all device
implementations. And a missed edge case would lead to permanently
unusable apps on the device.
This change also fixes a bug where any DistractionRestrictions set
weren't cleared on suspending app data clear.
Test: atest GtsSuspendAppsTestCases
Bug: 144826981
Bug: 145735990
Change-Id: I81a492e1d07a8cc9aeb0acd7e5142826824a42ae
