This CL uses getGroupUuid() and isOpportunistic() instead to figure
out whether the subscription is visible or not
Bug: 140768340
Test: Manual
Change-Id: Id7215eabe4e6c47a057b747fdbb3027857f2f12c
code
A featureId is only used by runtime permissions.
Test: atest FrameworksTelephonyTests CtsAppOpsTestCases
Bug: 136595429
Change-Id: I7ef41e8961e48d40e5685c4a521e83cb20953e48
Reason for revert: This causes a boot issue on Taimen (b/144480969). It wasn't caught by TreeHugger due to Taimen tests being disabled due to a different lab outage (b/144350336).
Change-Id: Idc18b3531fda53257b85b81a869c00592eee83ce
Introduces the notion of 'user types' to UserManager.
Previously, users only had properties, set by UserInfo flags. We now
solidify some of these as formal user types. Each user must be of
precisely one user type. The configuration of each type is defined
in a UserTypeDetails object.
Prior 'types' - namely Guest, Restricted, ManagedProfiles, Demo, and
'normal' - that were set via UserInfo flags are now controlled via
UserType. Previous UserInfo flag methods for categorizing these are
still supported as long as no user of of more than one type.
If a user was (e.g.) previously both Guest and Demo, it is now
invalid and will be prevented from upgrading. This should not be a
problem in AOSP, where these 'types' were assumed mutually exclusive.
UserTypeDetails is sufficiently general to support future non-managed
profiles. To this end, the logic for specifying badges and their
colors/labels is contained by UserTypeDetails, and therefore
UserManager is responsible for delivering the corresponding badge
information.
Bug: 142151520
Test: added new test class UserManagerServiceUserTypeTest
Test: added additional tests in UserManagerServiceUserInfoTest
Test: added additional tests in UserManagerTest
Test: added additional tests in UserManagerServiceCreateProfileTest
Test: created UserTests to run the various pm.User*Test's
Test: atest \
com.android.server.pm.UserTests \
UserLifecycleTests \
ManagedUserContentResolverTest \
CtsDevicePolicyManagerTestCases \
CtsMultiUserHostTestCases \
com.android.server.devicepolicy.DevicePolicyManagerTest \
com.android.server.am.UserControllerTest \
CreateManagedProfileTaskTest
Test: atest com.android.server.pm.UserManagerServiceCreateProfileTest
using adb shell getprop persist.sys.max_profiles # for 5 and -1
Change-Id: Id1183a76055e9a7610965cf40b256d1392afe6f8
handleShellCommand() would be a system API, so we should use PFD instead,
per the API guidelines.
Bug: 142751512
Test: "adb shell cmd jobschduler help" -> show help
Test: "$ cmd jobscheduler run abc 123" -> shows "Package not found: abc / user 0"
Test: "adb shell cmd activity help" -> show help
Change-Id: I64b1e4c540db836cc4a46fed24a038b7077ecb63
This creates a java API for registering pullers. Will implement the
statsd side in a follow up CL.
Test: builds, boots
Change-Id: Ib6735984297ce3148839a6370a3c15b2a585baf5
The public platform version no longer can be a codename, it is
always the most recently released platform. A new build property
and API provides either the offical version or the current codename
as appropriate. This will avoid breaking apps that look at the
platform version while development is under a codename.
Bug: 143175463
Test: manual
Change-Id: I72975ec86ac07700dc9052245b54411fa77982b8
Up until now, the FUSE mount logic has made two assumptions:
1. The primary external volume is an emulated volume on /data/media
2. Only the primary user is running, as user zero
With this change, we are able to handle the following cases:
1. Mount new external storage volumes as as portable storage
(PublicVolume) managed by FUSE. The PublicVolume originally mounted on
/mnt/media_rw/<uuid> is availabe on /storage/<uuid> as a FUSE mount
2. Mount new external storage volumes as adoptable storage
(PrivateVolume) with a stacked EmulatedVolume managed by FUSE. The
EmulatedVolume orignally mounted on /mnt/expand/<uuid>/media will be
available on /storage/emulated if set as the primary storage
3. Run the MediaProvider as a secondary user handling requests on
/mnt/user/<userid>/<volid>
Test: atest AdoptableHostTest
Bug: 135341433
Bug: 140120303
Change-Id: I5fb48616b4143277ea14c6846037e2fd176e16db
By default, PR_SET_DUMPABLE is 0 for zygote spawned apps, except in the
following circumstances:
1. ro.debuggable=1 (global debuggable enabled, i.e., userdebug or eng builds).
2. android:debuggable="true" in the manifest for an individual application.
3. An app which explicitly calls prctl(PR_SET_DUMPABLE, 1).
4. GraphicsEnv calls prctl(PR_SET_DUMPABLE, 1) in the presence of
<meta-data android:name="com.android.graphics.injectLayers.enable"
android:value="true"/>
in the application manifest.
So checking both ro.debuggable=1 and PR_GET_DUMPABLE is redundant.
Bug: 144186877
Test: CtsAngleIntegrationHostTestCases
Test: CtsRootlessGpuDebugHostTest
Change-Id: Ica49254df2c7c090808411935cdeb8efd4e3cb51
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
Merged-In: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
