Makes sure the behavior is consistent with legacy installs:
When the flag is on, the native libs will be extracted to subdirs under
lib/.
When the flag is off, the lib/ subdirs will be created but the native
libs are not extracted.
When the flag is off, check if the native libs are uncompressed and well
aligned.
Test: atest android.extractnativelibs.cts.CtsExtractNativeLibsHostTest
BUG: 157173358
Change-Id: Idb57fd7ca1115f787faf5cde3056c32ff3f60890
This does the following:
1. The multiuser switcher (in Settings and SysUI)
is now disabled by default. In order for it to be enabled
one of the following must be true:
a. the user has explicitly toggled it on in Settings
b. a new user gets created (via any means)
c. config_showUserSwitcherByDefault overrides this default
2. Even if a new user is added, if the user had explicitly
*disabled* the switcher, the switcher still won't be enabled.
3. SystemUI and Settings (et al.) all use
UserManager.isUserSwitcherEnabled as the source of
truth in this regard.
No one else reads USER_SWITCHER_ENABLED directly.
4. If the switcher is enabled, then SystemUI will show the
switcher avatar, even if there are no other users on the device,
as long as new users can be created. This way, if the user
has enabled the switcher, the user can use the avatar to add
guest/secondary users (which would not be possible if enabled
status was tied solely to the existence of other users).
Bug: 137943217
Bug: 141372193
Bug: 149973281
Bug: 130270878
Test: manual: Settings > Multiuser doesn't turn on the systemui avatar
Test: manual: Settings > Multiuser is initially disabled
Test: manual: adb shell pm create-user A, does turn on sysui avatar
even if the user didn't enable, but not if they disabled
Change-Id: Ia440b4db78792da76f94322a563d93db0c68e933
Background
* Some user restrictions should be per-profile
instead of per-device to allow for more
granularity.
* For this reason, the profile owner of an
organization-owned managed profile should
apply user restrictions the same way as the
profile owner on the personal user
(instead of the device owner).
Changes
* Move per-profile user restrictions from
PROFILE_OWNER_ORGANIZATION_OWNED_GLOBAL_RESTRICTIONS
to PROFILE_OWNER_ORGANIZATION_OWNED_LOCAL_RESTRICTIONS
in UserRestrictionsUtils
* Update UserManager javadocs
* Update DevicePolicyManagerTest
Bug: 148453838
Test: atest com.android.server.devicepolicy.DevicePolicyManagerTest
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testDevicePolicyManagerParentSupport
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionSetOnParentLogged
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testUserRestrictionsSetOnParentAreNotPersisted
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testPerProfileUserRestrictionOnParent
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testPerDeviceUserRestrictionOnParent
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testCameraDisabledOnParentIsEnforced
atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest#testCameraDisabledOnParentLogged
Change-Id: I431f7b9bf45a24b77f62899794561d6098f2a54b
Add a DeviceConfig feature that denotes a list of apps we want to force
into scoped storage. This would allow us to test these apps behaviours
under scoped storage at scale.
Also add the feature to StorageManagerService#dump.
Test: manual:
$ adb shell device_config put storage_native_boot forced_scoped_storage_whitelist <pkg>
$ adb reboot
$ adb shell dumpsys appops --package <pkg> # observe LEGACY_STORAGE
mode=ignored
Test: adb shell dumpsys mount
Bug: 151735608
Change-Id: I6a43e987ebf8d14fb64103a74bafde28f5863ae2
The actual cache clearing is not async anymore, so we can report the
status to the calling app. Here, we just change the documentation to
make the caller aware of the 3rd possible activity result: EIO.
This value is returned if an error happens while MediaProvider is
clearing the cache. In this case, we don't know how much of the cache
was deleted, if at all.
Test: build
Bug: 155290762
Change-Id: I3a04a9b5b6b07c6ec61e97a4cb0d3bc8b10b0370
isUserUnlocked and isUserUnlockingOrUnlocked share the same service-side
dependencies, so we can add a cache to the client-side of transaction
and hook into the isUserUnlocked cache invalidation infrastructure.
Bug: 140788621
Test: atest CtsMultiUserHostTestCases while validating cache operations.
Change-Id: Icf11b1e777936ec9922ce4a47f8cfccbd22ad5ef
Since as of R, apps can no longer query other apps by default,
deprecate the isUserAGoat API's undocumented behavior and
always return false.
Fixes: 156543788
Test: atest CtsMultiUserTestCases
Change-Id: I9743d87b762aabb01dc010ba6d5a6c01643a1f92
The referenced object could be destroyed and result in native crash when
mCallback is used.
Bug: 156536687
Test: manual test with registering a section from an app
Change-Id: Ie36c0e6e64be1246539f12999f037c24377686dd
These UserRestrictions' caveats actually apply to the
admin user, not the primary user, so we update the
documentation accordingly.
Bug: 132720870
Bug: 132719585
Test: none; it's just documentation
Change-Id: I9828136fe25537a1065423245fb0706520bf7480
When creating admin users, default
UserRestrictions do indeed apply, so updating
the javadoc.
Test: N/A
Bug: 143491938
Change-Id: Id495599abd4ddee100ca2c761d3b420fff315482
Fix a potential race condtion when the same message object
is being enqueued by two threads.
Bug: 150263007
Bug: 154867444
Test: atest android.os.cts.MessageQueueTest
Change-Id: Id79448ba8719479cbdb054f2cdd172fdcbe86d47
(cherry picked from commit 96a6fec4d6)
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
