Introduce a new API to request use of individual attestation
certificate for attesting keys generated by the
DevicePolicyManager.generateKeyPair method.
It builds on existing device ID attestation capabilities in two ways:
(1) Eligibility check: Assuming similar privacy requirements for the use
of individual attestation certificates, enforce the same conditions
for using them as the conditions for requesting device identifiers
in the attestation record.
(2) Keymaster interaction: Passing the right Keymaster tag to the
attestKey call, which is easily done in AttestationUtils.
Bug: 136494773
Test: CTS test to be added.
Change-Id: Idb5cee66d986a521c17e1955532d0bfae66c035d
Creates a new SystemConfig xml entry which allows a device to whitelist
system packages to be installed on users when they are created, based on
the type of user.
System packages will be installed on users when they are created, or
during OTAs, based on this whitelist. The whitelist can be
enabled/disabled via a Config resource.
For any user type, system packages can be whitelisted or blacklisted.
If it is both (for the same user type), the blacklist takes priority.
If it is neither, it won't be installed (since it isn't whitelisted).
If a system package isn't mentioned in the whitelist file at all, for
any user, then its behaviour depends on the Config resource value, which
can optionally implicitly whitelist all such apps on all users.
For now, the list is mostly empty and the default config is set to be
enabled but implicitly whitelist all system packages that are not
mentioned.
Test: atest FrameworksServicesTests:SystemConfigTest
Test: atest com.android.server.pm.UserManagerServicePackageWhitelistTest
Test: manually test user 0 by flashall -w and checking packages
Test: manually test OTA by setting setprop persist.pm.mock-upgrade 1
Bug: 134605778
Change-Id: Ia098c1f597f66a1c946cfcc9b7771c25e8ceabf7
Two intents that can be resolved to the same component were
evaluated as different intent filters, because one had the package
name set while the other one did not(null).
Skip performing package check if both two intents have components which
equals to its set package.
Bug: 64108432
Test: manual
Change-Id: I8163cbb6b56366ebbecaede7fa04ab3eab7cfe9f
This reverts commit 27c4e658b3.
Reason for revert: <potential performance regression. revert for now and looking for possible optimization from ART team>
Change-Id: I5bf728e4f6789d7e6398cf90f22fbf3a24d481c2
We used to store the actual permission state for pre-M apps in app
ops, which creates two different sources of permission state and is
hard to handle correctly. This change will allow us to store the
permission state for pre-M apps within permission as
FLAG_PERMISSION_REVOKED_COMPAT (and syncing app op state based on it),
and is part of the effort to support rollback of runtime permission
state managed by PermissionController.
Actually, we do set a REVOKE_ON_UPGRADE flag properly when user
grants/revokes a runtime permission for pre-M apps, so it can be used
for computing app op state. In the case where app ops are incorrectly
set to denied without setting this flag, the app won't get the
permission revoked upon upgrade to support runtime permissions, and is
stuck with the denied app op, so overriding the app op state in this
case is arguably fixing a bad state.
Since the proposed new flag will cover whatever REVOKE_ON_UPGRADE does
currently, and REVOKE_ON_UPGRADE did imply denying app op in its
javadoc, this change is simply adding our new flag by renaming
REVOKE_ON_UPGRADE.
Bug: 136503238
Test: manual
Change-Id: Ib910f4df543d2fd8de259a6675f043d870a6f4c1
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
This change breaks isInstantApp up into a public and internal
implementation so that internal interfaces have a means of calling
without any permission checks that only apply to public callers.
Fixes: 141288362
Test: Work profile setup
Change-Id: I2cb8338c2a68bc9c4a61c075398d767980c504ed
If an app doesn't have a launcher activity enabled by default, a
synthesized activity isn't created for that app.
Test: make ds-docs -j32
Bug: 140968734
Change-Id: I2fe8666ee8cde479f404e43c622f03891d96c38f
This change turns off the kill switch for App Enumeration by default
and sets the PlatformCompat feature to @Disabled until we're ready to
turn it on by default for beta.
Bug: 136675067
Test: atest AppsFilterTest
Test: atest AppEnumerationTests
Change-Id: I7f3c1995318838cda5d7025de8ae366cde75930f
This change adds consideration for more than just activities when
computing matches between packages for app enumeration / filtering.
It also changes the failure logic when parsing a package to allow for a
queries intent tag that contains no action, but a scheme or one that
contains no data tag but one action (or both). Previously it would have
been impossible to enumerate an app purely based on the authority of one
of its providers.
Bug: 136675067
Test: adb shell device_config put package_manager_service package_query_filtering_enabled true && atest AppEnumerationTests
Test: atest AppsFilterTest
Change-Id: I07bb449e78fb79a2ed61f75b37e582e0f3467a2d
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Merged-In: I53946ed4e31de0ffe9c84875c391a7dec6f5375a
Change-Id: Idaae690f79a5c680ad0059a52be62160d9dfb5e7
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Change-Id: I53946ed4e31de0ffe9c84875c391a7dec6f5375a
Creating a SystemConfig from a non-system process is taking 500+ ms.
This CL instead exposes the needed split permissions from system_server
to optimize performance.
Tested locally and creating PermissionManager / retrieving SystemConfig
is now less than 1 ms.
Bug: 139828734
Bug: 139485700
Fixes: 139828734
Test: Added systrace / logs to PermissionController app and traced
runtime of onGrantDefaultRoles().
Merged-In: I111403e8dae3bc2b0acafc32e61aa5cd890fea29
Change-Id: I111403e8dae3bc2b0acafc32e61aa5cd890fea29
(cherry picked from commit f69c71e25889d8a9d66da05ee0f386d7fb626c6c)
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Change-Id: Id0e63ae4a7be578d1e93838b371320f86a787e0e
When the configurations are being read from the proto file, if a
duplicate locale is found in the list, an exception is thrown from
LocaleList which causes the UsageStatsService to crash. Instead, we'll
now log a WTF if duplicate locales are found when parsing the
configuration proto and not add the duplicate locale to the list.
Bug: 140197723
Test: atest UsageStatsDatabaseTest
Change-Id: Ie178b3cfdd45e6771a7c0e4bb42e47f79b5c30cc
(cherry picked from commit 5d9031dbee)
Throughout the codebase, sometimes an integer user ID is called
userId, and sometimes it is called userHandle. Here, we rename the
occurences of "int userHandle" to "int userId" in select files.
Additionally, we add the @UserIdInt annotation in many more places.
This certainly does not cover all uses of userHandle, which is used
widely throughout Android; doing so would be more dangerous and cause
merge conflicts. But at least the core User code can have a consistent
nomenclature.
Bug: 138384792
Test: compiles. presubmit passes.
Change-Id: I9a2684e9bfac637e0476c4b68027008ebb8a160b