This change adds support for reading/writing a HidlMemory
instance into / out of a HwParcel and HwBlob, in a format that
is compatible with the hidl_memory C++ type.
This paves the way to be able to exchange shared memory blocks
between native and Java via HwBinder, which will be exposed
as adding Java support for the HIDL 'memory' type.
Change-Id: I6cbbf852218c8a631f9014e7caa7a97d17e11889
Bug: 143566068
Users of these APIs are planning to move to apex.
Test: atest FrameworksCoreTests:android.os.WorkSourceTest
atest CtsOsTestCases:android.os.cts.WorkSourceTest
Bug: 143551137
Change-Id: I2e97a8b469254ea92e3ee21571ee8ae3cbb9abbe
This new interface allows Java code to look up property values without
paying for the name->prop_info mapping and, in the case of looking up
scalars, without doing any allocation.
Bug: 140788621
Test: added tests
Test: atest FrameworksCoreSystemPropertiesTests
Change-Id: I46d12f62499e9e124fe9add588376d724b364d5d
A subsequent CL will implement a new prop_info based properties API on
top of this CL.
Test: boots
Test: atest FrameworksCoreSystemPropertiesTests
Bug: 140788621
Change-Id: Id8dd02fff7b1c0815a27ab1dfdde1700447a414c
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.
This is partial merge of aosp/Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09. Telephony greylist cleanup has been done separately. Note that annotations outside of frameworks/base/ have been merged from AOSP.
Bug: 137350495
Test: m
Exempt-From-Owner-Approval: merge
Change-Id: I015c466e8b69cc0fed5e9d394ba865aad11d8ba6
* changes:
Add new API for Telecom to send phone state
Minor style correction to avoid merge conflict
non-mainline telephony related AIDL refactor/decoupling
1. decouple IOnSubscriptionChangedListener AIDL from telephonyMainline
2. other refactor. moving APIs which will not be included in
telephony mainline to frameworks/base/core/java/android/telephony.
Moving internal classes like AIDL which will not be included in
telephony mainline to
framework/base/core/java/com/android/internal/telephony
Bug: 140908357
Test: Build & unit test
Change-Id: I9413ef758cceadd251d03f3b5ea1054cc48ef044
Merged-In: I9413ef758cceadd251d03f3b5ea1054cc48ef044
These have been the cause of bugs in the past, such as b/10150258,
because it's not always obvious or guaranteed that a calling thread will
always have a looper, or that it's actually the looper you want.
Specifying the looper explicitly, even if it's just Looper.myLooper(),
makes the code clearer. Since callback APIs generally should have
Executor variants added, it might be nice to also deprecate the
constructors or options that rely on the calling thread's looper, but
since I don't have an inventory of all those I'm starting with this.
Bug: 144042891
Test: No behavior changes
Change-Id: I0e7ba80d6b89a866ea715c790dd602ef728bf5bd
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
