Currently when loading implicit layers from apks, NativeLoaderNamespace
doesn't allow to dlopen the binaries if they come from apks from
/vendor/app. Implicit layers ship within /vendor/app should work like
other implicit layers. This patch extracts the construction of library
paths of the implicit layers and includes those paths when
NativeLoaderNamespace is created as the part of the permitted library
paths.
Bug: b/157832445
Test: atest android.gputools.cts.CtsRootlessGpuDebugHostTest
Test: setup debug layer and use adb logcat to check vulkan loader output
Change-Id: Ie2ca989bcab890578b5aa540d07f2aee2a0182bd
Remove these runtime restrictions of low ram device.
This change wouldn't bring the features onto low ram device, because
manufacturers need to change some configs to enable the features, but
would allow the usage.
Bug: 153016458
Test: build successful; multiple users and managed profiles can be
enabled with config changes
Change-Id: Ibe59219dab7e138d7dae19df77d36477e9e76b8e
To make sure we kill all untracked children, too.
Bug: 156741968
Bug: 157598956
Test: manual inspection, PoC no longer works.
Change-Id: I5d8efeb05ddec08a7fc7c00eabca6590c4cfdd8c
The MediaStore.VOLUME_EXTERNAL volume is a synthetic collection of
all currently mounted storage volumes, so if someone wants to find
the underlying StorageVolume for one of these Uris, we need to query
to resolve the real volume name.
Bug: 153664437
Test: atest android.provider.cts.MediaStoreTest
Change-Id: I7b28ba3bfd5b7a4cc577830940de4a2e1cbd1932
Since Android N we've helpfully guided apps towards using content://
Uris when sharing data, but some obstinate apps have tried bypassing
these helpful checks. Since we're finally changing the storage model
in Android R, we really to communicate strongly that apps must be
using content://, and these methods should not be used.
Bug: 156336269
Test: manual
Change-Id: Id8707ecb51f3a24747b4c84d86c70591fb5f7ffc
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
To give a way to extend a stable parcelable object, a wraper for a
parcelable is necessary.
The reason why it needs to be wrapped is allowing to trasfer an extended
parcelable even though some of modules using the parcelable don't
know the type of an extension.
Whenever setParcelable() is called, it checks stability level
Bug: 146611855
Test: atest aidl_integration_test aidl_unittests
Change-Id: I6895976658fd7450b2ee47076a03079995777143
