If a profile owner is defined for a specific user, do not delete usage
stats for a package on package deletion.
Bug: 197399948
Test: atest UsageStatsTest [all]
Change-Id: I94a8e3dfca8ef4c7616f77944d61726e06043b85
Merged-In: I94a8e3dfca8ef4c7616f77944d61726e06043b85
Background
* Historically, when the screen capture disabled
policy was set on the personal profile, screen
capture was disabled for the whole device
(per-device).
* This should be changed to only be disabled in
the personal profile (per-profile).
Changes
* Renamed DevicePolicyCache methods to setScreenCaptureAllowed
and isScreenCaptureAllowed
* Added parameter ownerCanAddInternalSystemWindow to
isScreenCaptureAllowed
Bug: 148453838
Bug: 157035400
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: If1bd68f0ec3e88497c5d3b4382977b526b2364ba
Allow apps with MODIFY_QUIET_MODE permission to register
broadcast receivers for MANAGED_PROFILE_* in their manifest.
Fixes: 158870146
Test: atest 'com.android.cts.devicepolicy.QuietModeHostsideTest#testBroadcastManagedProfileAvailable_withCrossProfileAppsOp'
Test: atest 'com.android.cts.devicepolicy.QuietModeHostsideTest#testBroadcastManagedProfileAvailable_withoutCrossProfileAppsOp'
Change-Id: I39746c5b3ff3c49f8a903fc52091fcb8d3607c84
(cherry picked from commit cc8b51873b)
* if no apps are suspended by the DO prior to migration, nothing
changes
* if some apps were suspended by the DO and the DPC targets R+
via DPM.setPackagesSuspended(), this will result in personal
apps suspended explicitly by the PO DPC as if it called
DPM.setPersonalAppsSuspended(). The apps will stay suspended.
* if the DPC target SDK is below R, the apps will be unsuspended
because the DPC won't have a way to unsuspend them. And the
user will be stuck with suspended apps.
+ when unsuspending apps, don't collect the list of apps subject
to suspension, but rather unsuspend all that is suspended. It
is more robust, e.g. when some app stops meeting the
conditions, e.g. not SMS app anymore.
Bug: 157270093
Test: com.android.server.devicepolicy.DevicePolicyManagerServiceMigrationTest
Test: Manual, with TestDPC, also patching it to target R
Change-Id: I1eba7216dd557c94bef822b77d25b484dfcd6f63
While most of the admin policy (DevicePolicyData) is loaded lazily
wheneve they are read, the list of Device and Profile owners are
currently loaded during PHASE_LOCK_SETTINGS_READY, which means
policy getters relying on the list of owners, for example
isCommonCriteriaModeEnabled, does not work until this boot phase.
It turns out that some other system services (WifiService) will
attempt to read the policy before this boot phase and hence fails.
Fix this by loading the owner info as part of DevicePolicyManagerSerivce
construction, so the info is always available.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: Set TestDPC as DO, enable Common Criteria mode, add WiFi,
Check /data/misc/apexdata/com.android.wifi/WifiConfigStore.xml
for the lack of plaintext WiFi PSK.
Test: atest
com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testSecurityLogging
Bug: 157476512
Change-Id: If403cf98574612cb44f7c8a697095276c65087fe
Instead of requiring the DEVICE_ADMIN feature, we accept either
the feature or the appropriate permission.
Bug: 133240910
Test: Manual testing
Verify that API executes when on a device without DEVICE_ADMIN
when the caller has the LOCK_DEVICE permission.
Change-Id: I30bd0dc81d9d7b7ed5503a926066caffb389b9c0
(cherry picked from commit 3cc489b7f3)
In upcoming changes, we'll need to shift the calculation of needed
permission grants to occur before we acquire any AM/WM locks; we'll
continue to use that calculated list when actually granting.
This change also reduces the surface area of how callers in the
system server interact with Uri permissions to reduce the risk of
accidental misuse.
This is a no-op refactoring.
Bug: 115619667
Test: atest FrameworksServicesTests:com.android.server.uri
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.AppSecurityTests#testPermissionDiffCert
Change-Id: Ied529156205903f9b02b4265963fdf59f7dd7f92
Only notify the user when the admin enables location services on their
device, not on every state change.
Prior to this change the user would be notified when the admin disables
location services, with a misleading notification indicating apps now
have location available.
Tested by installing TestDPC, setting it as device owner, then toggling
location on and off and observing user is notified only on turning
location on.
Test both legacy and new method flows.
Bug: 156602188
Test: Manual using TestDPC (see above)
Change-Id: Ia757802bd7da1afeecfd8071598b692c69860c66
* A security exception should be thrown when
setAutoTimeRequired is called on a managed profile
* Update javadoc
Bug: 156620695
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testSetAutoTimeRequired
atest com.android.cts.devicepolicy.MixedProfileOwnerTest#testSetAutoTimeRequired
atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testSetAutoTimeRequired
Change-Id: Ifb53c218947f62aa446aa607d3f4eee354586395
PendingIntent as part of a notification can be intercepted by
a malicious app and re-fired with crafted intent arguments.
System server should set explicit target for these intents
to avoid it being fired to other apps with system privilege.
Bug: 155183624
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: Set a DO/PO with TestDPC, turn on location, verify notification
works
Test: set a DO with TestDPC, request remote bugreport and verify
notifcation works
Change-Id: Ib7d0039c3d07a9d1ccf57e944303353ec9e9b66d
This helps avoid confusion if the user only sees the notification the
next day.
Bug: 155740352
Test: manual with TestDPC
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I6c95a6db2e8967eeffa373f96170cd610f13856a
* Make sure that if the time is rolled back after the deadline
has been reached, it is not undone. When the deadline is
reached it is set to -1 which is far in the past, so timezone
change won't affect it.
* Return sensible value in case when the deadline has just
expired and the suspension itself hasn't been enacted.
Previously the deadline expiration wouldn't be reflected until
mAppsSuspended gets updated after all apps are suspended.
* Update deadline on time changes. This makes it react to time
changes via adb.
* Additional debug logging to investigate further if the issue
persists.
Bug: 155878352
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I6549f76584121df200ace811285e7a358f262869
* Now it is of nice blue colour, lighter in night theme.
* Uses suitcase icon instead of warning sign.
* Shows "Work profile" instead of "Android system" as the source.
note: I reused a string for "Work profile", which has the same
content, but different purpose. This is not ideal, but we are way
past the deadline.
Bug: 155612405
Test: manual, with TestDPC
Change-Id: I8298401742085b1738de384e3fe0e612a8142607
Background
* Secondary users should be disabled
when the device is an organization-owned
managed profile device.
* This is because supporting secondary
users would complicate the semantics of
user restrictions.
Changes
* Add DISALLOW_ADD_USER as a base restriction
when the device is an organization-owned
managed profile device.
* Handle removal case when the device is no
longer in this mode.
* Remove the ability of other admins to apply
DISALLOW_ADD_USER.
Manual Testing Steps
* Provision an organization-owned managed
profile device.
* Check Settings > System > Multiple users
and verify that a user cannot be added.
* Check WP TestDPC 'Set user restrictions
on parent' and verify 'Disallow add user'
is not present.
Bug: 155281701
Test: Manual testing
atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I83348fc8b854cef20383803124000540b5b130cb
Before this CL the whole notification used to be clickable,
with this CL it is not clickable but contains a button with
"Turn on work profile" text to match the mocks and to make it
more clear to the user.
Also, added text style so that the text is warpped if it can't
fit into one line.
Test: manual with TestDPC
Bug: 149075510
Change-Id: Iabe7387df99a6b719a7ce1f310c38f2916e7e4c7
When admin sets a new strong auth timeout policy, replace the existing
alarm (which enforces strong auth after the timeout) with a new one
with updated timeout.
Bug: 146188984
Test: atest com.android.server.locksettings.LockSettingsStrongAuthTest
Test: atest MixedManagedProfileTest#testRequiredStrongAuthTimeout
Change-Id: Ibcc13eb0d66697aff44192769b8fd817ca6800b8
Previously in case when the personal apps are suspended as a result
of work profile off timeout, ACTION_CHECK_POLICY_COMPLIANCE would
only be triggered if the user taps on the notificaiton. With this
change it is triggered also when the user uses any other way to
turn the profile on.
Instead of attempting to invoke policy compliance check, the
notification now turns the profile on. And once it is unlocked,
policy compliance check is triggered.
Also, made "apps suspended" notification non-dismissable.
Bug: 151439078
Bug: 149075510
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I84e5a13995af78992f22568a3a87e7d96af1a3be
String resource names were renamed to differ from the old ones
because the text used to require an integer argument.
Also notification update moved out of synchronized block.
Bug: 154912947
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Change-Id: I83997c2cf575f36bb2b53037ed9a68dfecc290a2
* updatePersonalAppsSuspension is invoked for all events relevant
to profile maximum time off: user stopped, user unlocked,
system boot, deadline alarm goes off,
setManagedProfileMaximumTimeOff called.
* It takes all relecant bits of state into account: policy,
current deadline, user state. It calculates the new state
of the deadline, notification and alarm and makes appropriate
changes (e.g. schedules the alarm, posts notification, suspens
apps).
* Updated package manager query flags so that even when personal
apps are being suspended while the user is locked, it includes
non direct boot aware apps as well.
Test: manual, with TestDPC
Test: atest OrgOwnedProfileOwnerTest#testWorkProfileMaximumTimeOff
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
Test: atest OrgOwnedProfileOwnerTest#testPersonalAppsSuspensionNormalApp
Bug: 149075510
Change-Id: I94d2582c7af91a5d97e67d2baf2e15f0a6d5ffa9
* Add @TestApi isFactoryResetProtectionPolicySupported()
to DevicePolicyManager which returns whether factory
reset protection policy is supported on the device.
Bug: 153696811
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testFactoryResetProtectionPolicy
Change-Id: Id0bd6cdacf33f0fb2f795e1ead5127b79f42960e
Another way was to clear it using existing APIs for each package
but each call would cause Package Manager to re-serialize the
package-restrictions.xml, so I added a separate API to do it in
one go.
Bug: 149075700
Test: manual, set TestDPC as a DO, block uninstall, remove DO.
Test: manual, set TestDPC in COMP, block uninstall, migrate to COPE.
Change-Id: I9be69af5d7ae9e0ddda087d3e01e35f3429f25f4
+ don't send broadcast when clearing already empty restrictions.
Bug: 149075700
Test: manual, set TestDPC as a DO, set restriction, remove DO.
Test: manual, set TestDPC in COMP, set restriction, migrate to COPE.
Change-Id: Ib85ee3937c43cde1cca0dad8117cd0f8dd642fd8
If the DO is not preinstalled, it is just removed.
If it is preinstalled, it is marked as disabled until used.
Bug: 149470717
Test: manual, with TestDPC, also pushed to /system/app
Change-Id: I26f4ad486263e40c10bfb71f22001ee5ebbf117b
* accountTypesWithManagementDisabled
* disableScreenCapture
For security logging nothing has to be done since the state is
stored in a system property, just changed it so that the logging
will be started after the migration and only events for the
right user are logged.
Also removed the todo about hardening for power cut case, the
risk of additional complexity sees to outweight the benefit.
Bug: 149075700
Test: atest DevicePolicyManagerServiceMigrationTest
Change-Id: I3a58325f2d6f415e51998c5096c5fc123d26602d
* Modified setAutoTimeRequired to call
pushUserRestrictions after requireAutoTime
in the active admin is set.
* Modified addSyntheticRestrictions in the
active admin to include the auto time
required case.
Bug: 145604635
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.server.devicepolicy.DevicePolicyManagerServiceMigrationTest
Change-Id: Ida4952eeec8ec12573c4049a9bf8e0ce6a951a86
Expose internal API to check if the user's password
will be sufficient after profile unification. Also
expose some other helper methods and refactor
DevicePolicyManagerService to unify a few similar
methods that gather admins from user and its profiles.
Bug: 148630506
Fix: 149682344
Test: atest com.android.server.locksettings
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: Ic647c14d5bab7e7337185bc40b1368e42c65f738
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
