| Age | Commit message (Collapse) | Author |
|
All new mainline APIs must be flagged.
Bug: 380052797
Test: atest PackageManagerShellCommandInstallTest
Flag: android.content.pm.sdk_dependency_installer
Relnote: N/A
Change-Id: I3b2677947608dbe772d81bc6875d45930095afa7
|
|
|
|
Bug: 380052797
Test: atest PackageManagerShellCommandInstallTest
Flag: NONE API to avoid hardcoding constant
Relnote: N/A
Change-Id: I8d32ce928ba83211bf864b088c205c56ef96289d
|
|
Followup fixes for RoleManager get/setDefaultHoldersForTest and is/setRoleVisibleForTest
LOW_COVERAGE_REASON=b/382484309
Relnote: N/A
Flag: com.android.permission.flags.cross_user_role_enabled
Bug: 381315745
Test: atest RoleManagerTest
Test: atest RoleManagerMultiUserTest
Change-Id: I19ddcd4a71682f89ccf32322833db3404f46c86f
|
|
This dialog looks similar to the existing ECM dialog, but has a
different message, about being blocked while in a phone call
Also removes the ecm "isUnknownCallOngoing", in favor of using
"isRestricted"
Test: atest EnhancedConfirmationInCallTest
Flag: android.permission.flags.unknown_call_package_install_blocking_enabled
Relnote: android 25Q2 feature
LOW_COVERAGE_REASON=FLAG_NOT_ENABLED
Change-Id: I113114c15df3df483e290f0bab00f5cecb2b44f8
|
|
|
|
Add role methods to assist in setting test role visiblity and default holders
LOW_COVERAGE_REASON=b/382484309
Relnote: N/A
Flag: com.android.permission.flags.cross_user_role_enabled
Bug: 381315745
Test: atest RoleManagerTest
Change-Id: I6d1d4200849a2be994f83da675fc57837ae7204f
|
|
This intent action will be used by settings to trigger the "action
blocked due to being in untrusted call" dialog
Bug: 364535720
Test: build
Flag: android.permission.flags.enhanced_confirmation_in_call_apis_enabled
Relnote: 25Q2 api
LOW_COVERAGE_REASON=NON_CODE_ONLY
Change-Id: Ic96ca1ce17ed5df3a4f4f736c6bd48ea599dadbe
|
|
|
|
Adds new APIs that let certain apps query if there is a call with an
unkown user (read: not a contact) ongoing. Also merges an InCallService
which tracks and updates this state
Bug: 364535720
Test: atest EnhancedConfirmationInCallTest
Flag: android.permission.flags.enhanced_confirmation_in_call_apis_enabled
Relnote: 25Q2 release
LOW_COVERAGE_REASON=FLAG_NOT_ENABLED
Change-Id: I2e260bd911a65f99dd7e7b7b4012b04ef7b51203
|
|
LOW_COVERAGE_REASON=FLAG_NOT_ENABLED
NO_IFTTT=brings jarjar inline with RoleParse transform
Relnote: N/A
Flag: com.android.permission.flags.cross_user_role_enabled
Test: atest RoleManagerTest
Test: atest RoleShellCommandTest
Bug: 372746716
Change-Id: I1b4da27df2f0d1862aa0031b2988bd7562f1a956
|
|
This API then enables TelephonyManager to expose the emergency
role holder to priviliged clients via getEmergencyAssistancePackageName.
Bug: 323157319
Test: atest RoleManagerTest
LOW_COVERAGE_REASON=Flagged test added but flag not enabled
Change-Id: I91089701248a32a720b488147405b2566cca2be9
|
|
Because Intent is more common, and we're not really getting major
advantages from how we're using a PendingIntent, return an Intent
instead of a PendingIntent.
Test: atest CtsPermissionUiTestCases:android.permissionui.cts.EnhancedConfirmationManagerTest
Fix: 324645464
Change-Id: I12062d20edb5a34950fd3cb9c9b993998b906041
|
|
"sc_private_profile_api" into main
* changes:
Add the titleForPrivateProfile API
Generalise the code for various profile types - 6
Generalise the code for various profile types - 5
Generalise the code for various profile types - 4
Don't add primary profile in default group summary
Generalise the code for various profile types - 3
Generalise the code for various profile types - 2
Generalise the code for various profile types - 1
|
|
This API lets the safety sources set the title for the private
profile in the safety center config file.
This change also temporarily disables the linter. Safety Center team
will look into enabling it later.
Bug: 286539356
Test: manual
Change-Id: I99ab006240883065d290b2d9976f2a7c9bf7905e
|
|
We're planning to move the "Restricted setting" dialog into
PermissionController. But, this dialog's intent action string,
Settings.ACTION_SHOW_RESTRICTED_SETTING_DIALOG, is currently bound to
the Settings app.
So, to ease the transition, this change defines a new intent action
string.
This string should only need to be accessed by PermissionController,
which handles the intent, and EnhancedConfirmationManager, which
constructs the intent.
Bug: 322026141
Test: manual
Change-Id: I1ba1d5bc778dd39239abb0dc6e0f0f32bea0c2b2
|
|
Accept a 'settingIdentifier' argument to getRestrictedSettingDialogIntent.
We might want to use this to customize the dialog depending on the setting being requested. (Though, we're not doing that yet.)
Bug: 323225971
Change-Id: I51258724c48958176fa436b23f23cfa93a242dc3
Test: manual
|
|
We plan to call EnhancedConfirmationManager::setClearRestrictionAllowed
a hidden API method, from PermissionController. But,
PermissionController can't access hidden API methods. In order to make
this possible, setClearRestrictionAllowed will need to be upgraded from
hidden API to SystemApi.
The reason we need to call setClearRestrictionAllowed from
PermissionController is that we plan to move the
ActionDisabledByAppOpsDialog activity into PermissionController, and
modify it to call setClearRestrictionAllowed instead of directly setting
appops.
Bug: 322026141
Fix: 320517290
Test: atest CtsPermissionUiTestCases:android.permissionui.cts.EnhancedConfirmationManagerTest
Change-Id: Ibd068ac456846fd1af8e867a6b336853a7835c4a
|
|
We've recently created a new permission:
MANAGE_ENHANCED_CONFIRMATION_STATES
The EnhancedConfirmationManager API should be gated by this permission.
So, add the RequiresPermission annotations.
Bug: 320512579
Test: presubmit
Change-Id: Ia04678c8049e46bdd27ae24dd23e7c842e240c63
|
|
|
|
This is a system service that provides the core API for ECM
(Enhanced Confirmation Mode).
Fix: 310655061
Test: manual
Change-Id: I831391e4437b51b3312b5273a2360bd029a3d8ee
|
|
Bug: 283989236
Bug: 291794775
Test: local testing
Change-Id: Ibd1b48e62b2702678434add5a007ca24d9fbf7d2
|
|
Migrate the isRoleFallbackEnabled preference to system server as a part
of the role logic move project. We only do the migration if it's V+. On
the system server side it will check the existing preference in
SharedPreference and migrate for all roles for the user.
API-Coverage-Bug: 314281553
Bug: 302563864
Test: RolePersistenceTest and RoleManagerTest
Change-Id: Ib24ebb8211359a652e52007fecf79a2390575e9c
|
|
Previously, due to a mismatch between Metalava and the output of
`java_aconfig_library`, flag constants did not have their literal value
inlined in the API signature files. That would cause problems with
future changes to filter APIs by flags. This change is part of a topic
that updates Metalava to inline the values into `@FlaggedApi` and
update the API signature files.
Bug: 314319629
Test: m checkapi
Change-Id: I222466e8f8bda8564509c02db7ce324bc9f2174d
|
|
We created the role_controller_in_system_server feature flag, then later
made it a fixed flag. However, it has been observed that the fixed
flag documentation shows the following warning:
IMPORTANT: Modifying the type of an existing flag is not supported.
For example, you cannot change a regular flag to a fixed read-only
flag, or vice versa. If you need to change the flag type, the best
practice is to create a new flag.
By renaming the flag, we're effectively removing the old flag and
creating a new one. This should mitigate any issues implied by the
above warning.
Fix: 313529525
Test: atest CtsRoleTestCases
Change-Id: I75e8c88984bdf9f5b98cc0a4745e205bcf8a798b
|
|
java_sdk_library has previously internally disabled a few legitimate
issues. As this is being un-done for modules, add baselines for the
pre-existing issues.
Bug: 306806877
Test: m checkapi
Change-Id: I230a1a0a36bfb1786a1f1333c5d6eff477069001
|
|
Add the isFallbackEnabled related fields (and setting/getting this value)
in System Server. We will assume all current RolesState have version=0.
If the version is undefined, it will be -1. If the isFallbackEnabled is
migrated, it will be 1.
What's not included in this CL:
(1) Code in PC to read this value from System Server
(2) Code in System Server to read from SharedPreference, migrate the
current user settings, and update RolesState version
Notes for the reviewer(s): (and open for discussions)
(1) If the version doesn't support isFallbackEnabled (when version < 1),
it will assume isFallbackEnabled is false. I think if the version < 1,
we should try to migrate (in a followup CL) this user settings and
update the version to be >= 1 instead of asssuming isFallbackEnabled to true.
Hence there's a constructor for RolesState that sets
mFallbackEnabledRoles to null. This should be used when version < 1.
(2) If the roles doesn't present or the version doesn't support
fallbackEnabled (see the condition in RoleUserState.setFallbackEnabled),
we don't allow setting fallbackEnabled to true.
Bug: 302563864
Test: Will add it after fallback logic described in Notes (2) is discussed.
Change-Id: Iaeb037ae014323f0af0c43031b20f3239e359027
|
|
Bug: 265351435
Test: manually tested
Change-Id: I810bef142968e2c2bdab62579bc0adbc5d4fae0a
|
|
Test: atest RoleManagerTest
Change-Id: I1826214b175d3f70d5c08d2e1d6ec8dc25183dfe
|
|
Test: atest CtsSafetyCenterTestCases
Bug: 264251865
Change-Id: I6727d62145e2826e29c439215d99981b79ef1f37
|
|
API feedback from b/258197471:
> * replace setActions with addActions, which doesn’t clear the
> Actions list
> * there’s a typo in the Java doc
I fixed up the corresponding tests.
Test: atest SafetySourceIssueTest
Bug: 258197471
Change-Id: I87ea0ad41b46c647fc7da8d09c1650abde0ffc05
|
|
- Control availability via configs declared in configs.xml in frameworks/base/core.
- Implemented NotesRoleBehavior for custom behavior:
-- Availability of role for personal and work profile are controlled via separate configs.
- Added the role name in RoleManager so that it can be managed by SysUI
and used by 3P apps.
Bug: 251199290
Test: Manually tested.
Change-Id: If2140972bc3a82bfc53163ebe7a1301ae2746745
|
|
* We are doing this as we will have multiple repos using this flag since
we will guard the safety label changes on this feature also. This flag
will therefore be used in Settings app as well as
PermissionController.
Bug: 261663929
Test: Used already to guard Permission Rationale feature
Change-Id: I303e1c2b6094500a1589ffaf1b771f3a9f2ca231
|
|
|
|
|
|
Test: atest CtsSafetyCenterTestCases
Bug: 262711124
Change-Id: Ibd4799d8ad7115f43c7d60122cb1576b38c14417
|
|
Test: atest CtsSafetyCenterTestCases
Bug: 243936990
Bug: 244323615
Change-Id: Ic4aa737aa9c1d15762ee01306d4e825f2f0a12a3
|
|
with it
Bug: 261652173
Test: atest CtsPermission3TestCases:AppDataSharingUpdatesTest
Change-Id: If7aa462f422dccde71f7e65da7cc3038b6e4150b
|
|
|
|
Notifications as SystemApi"
|
|
Test: atest CtsSafetyCenterTestCases
Bug: 224513865
Change-Id: Icfeb02857850f1a79eb761bb6d368f33db8a1e9d
|
|
SystemApi
We add this feature flag as SystemApi as it will be used across packages
(PermissionController, Settings and Platform code)
Bug: 261652173
Test: Will be used to guard the Safety Label Change Notifications
feature and so will be tested then.
Change-Id: Ia65d7c468a757de13feda32fa1a79299b39eaa63
|
|
Test: atest CtsSafetyCenterTestCases
Bug: 260054163
Change-Id: I829a3b4af7717a396dbff0bf5f7681baefbe3713
|
|
As per API review feedback provided in b/260734125, it is not necessary
to maintain consistency with the AIDL naming, hence changing to an
overload.
Test: atest SafetyCenterManagerTest
Bug: 260734125
Change-Id: I54d7a0e1e8222a2875e9ca87b78b98421af3412a
|
|
Cert hashes will be used in a signature check on other APIs where
currently a package name only check is used.
Test: atest SafetySourceTest SafetyCenterConfigTests
Bug: 252726218
Change-Id: Iac01b010e8ef39e9217738642d90bc5cf1d141ed
|
|
|
|
This is needed to surface more granular information in Safety Center,
e.g. "Tips available" or "Actions taken".
Bug: 260070587
Test: atest CtsSafetyCenterTestCases
Change-Id: Ia727319d6a26911ff2d7f369a6a693acd390d7e8
|
|
* changes:
Fix throws javadoc in config API
Allow packageName for static sources
|
|
Bug: 254637768
Test: atest --no-bazel-mode CtsSafetyCenterTestCases
Change-Id: I1d2d2b46b9a8381edfac75791c674be8b2e06e3b
|
|
|