Background
* This is part of the work to support
a credential management app on
unmanaged devices.
Changes
* Add a preference controller which will only
be enabled if there is a credential management app.
* Add a fragment to display details on the credential
management app and its policy. Add a remove button
to remove the credential management app.
* Link CredentialManagementAppAdapter to new fragment
and add expander.
Manual Testing
* Verify preference is disabled if there is no credential
management app.
* Verify preference summary shows credential mangement
app name if a credential management app exists.
* Verify fragment details page displays the
authentication policy correctly.
Bug: 165641221
Test: Manual testing
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.security.CredentialManagementAppFragmentTest
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.security.CredentialManagementAppControllerTest
Change-Id: I06d6b88d0c89022f7a6cbf3031834defcb54bd51
Background
* This is part of the work to support
a credential management app on
unmanaged devices.
Changes
* Show FAB for detailed/long manage credentials
authentication policy.
* Hide FAB for short manage credentials
authentication policy.
* Unexpand FAB once the user start starts
scrolling.
* Hide FAB once the user has scrolled to
the bottom.
Manual Testing
* Verify FAB is shown for a detailed/long policy:
https://screenshot.googleplex.com/BUb4LGz3GD6AozS
* Verify FAB is hidden for a short policy
* Verify FAB is hidden when user has scrolled to the
bottom:
https://screenshot.googleplex.com/6FQRqto3r3jzfXH
* Verify FAB is unexpanded (text hidden)
when the users start scrolling:
https://screenshot.googleplex.com/4FfAt5MsCfrAwQK
Bug: 165641221
Test: Manual Testing
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.security.RequestManageCredentialsTest
Change-Id: Ied2ef726ad4dcc3f92c20249f80294f0a3071a8a
Background
* This is part of the work to support
a credential management app on
unmanaged devices.
Changes
* Add new activity to Settings to display
a screen to the user requesting whether
the calling app can manage their
KeyChain credentials.
* Display the authentication policy
Manual Testing
* Verify screen is not displayed if intent
action is not android.security.MANAGE_CREDENTIALS
* Verify screen is not displayed if authentication
policy is not valid
* Verify button panel is visible if all items in the
authentication policy are displayed
* Verify button panel is not visible if not all items
in the authentication policy are displayed. Verify
that scrolling to the bottom of the item list, the
button panel becomes visible.
Bug: 165641221
Test: Manual testing
make RunSettingsRoboTests -j ROBOTEST_FILTER=com.android.settings.security.RequestManageCredentialsTest
Change-Id: Ie23b226f1a285b3de6ec3e91b8880d9144bb24a3
Since Bedtime mode can suppress AoD, after reviewed by UX, we decide
update the summary to "Unavailable because Bedtime mode is on" when AoD
is suppressed by Bedtime mode.
Bug: 168790245
Test: manual & robotest
Change-Id: Id2511cb0ad93b44f6bf701a707b7ddef9438653d
Remove the summary of the homepage IA if silky home enabled.
Fixes: 170933968
Test: robotest & visual with turning on/off silky home
Change-Id: I502b6590cece9b80e9923109fe0582cc4d9a1c56
The multitude of slightly different launchConfirmationActivity(*)
methods are a big unsustainable pyramid. It's too difficult to
read, too difficult to track which clients are interested in which
parameters, and too difficult to add new parameters, since we need to
1) Read through all of them and find one that's the closest
2) Try not to affect other callers, so potentially add yet another
3) Modify the internal paths, which all basically call each other
until it reaches the biggest launchConfirmationActivity which
has ALL of the parameters
This change should have no behavioral change.
Note: CredentialStorage doesn't need returnCredentials anymore as of
ag/6073449
Test: make -j56 RunSettingsRoboTests
Test: Manually traced code paths for each invocation. A few hidden
dependencies (such as explicitly setting challenge=0 with
hasChallenge=true) were found. Left them the way they were in
case they were intended
Test: Enroll face, fingerprint
Test: Enable developer options
Test: Change to PIN, Pattern, Password, then back to PIN (so each
type requests confirmation)
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL,
authenticate
Test: adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
(shows confirm credential screen)
Fixes: 138453993
Change-Id: Ic82ef3c3ac2e14d624281921f2d816bcdacbd82b
Since storage type is mandated as hardware-backed, this preference is no longer meaningful.
Bug: 160225361
Test: atest SettingsRoboTests
Change-Id: I9b6c1d6afdd3563201b1e85673acf4d8cb81c0a1
This change includes the following commits from internal R branch
which are related to certificate management:
0206e76f46 CredentialStorage: Install keys using KeyChain
09ceea53d9 Added functionality to select type of certificate to be installed from the Settings app
3acf3f5433 WiFi certificates installable from Wifi sub-preference
8439fd15f7 Fix strings for certificate installation in Settings
Bug: 161347472
Test: builds & manual testing
Change-Id: Ia59dc4780254fab4f34c2f61b25f3b4e56ed7b77
Controller can't find the target preference to handle the click event.
Store the preference keys to match the clicked item.
Fixes: 158716163
Test: run robotest and manually test the click behavior
Change-Id: Ie243206ceffef013c56c4ea29c14fe56da510fb6
- The "Smart Lock" item is a trust agent which comes from
TrustAgentManager, so add it to dynamic index.
Fixes: 148867137
Test: manual test the search result and run Settings robotest
Change-Id: I7cd3a9df89a9b9378fa49cc2cb2127c778b795f2
By design, we still need to show app pinning description
after user enables feature.
Test: Rebuilt rom, and see description.
Fix: 151332926
Change-Id: Ic9a2d7baec865358471ac0210648642ebd9fd65a
If device supports guest user mode, app pinning
recommends guest feature to user.
Test: Rebuilt rom and see correct string in app pinning.
Fix: 151332926
Change-Id: I6c03ecfe075fba2f4dedca18f65893f328e680aa
The purpose of this change is to resolve a number of security issue
around screen pinning.
See more detail go/screen-pinning-allows
There're a few change for Settings app.
- Rename the screen pinning to app pinning.
- Change the string description for app pinning.
- Pop up a warning dialog while user is enabling this feature.
Test: Rebuilt rom and see new ui flow.
Bug: 151332926
Change-Id: Ife07d7b95ab5dccb2aed7f2bc8fa32f97763bd63
When unifying work profile challenge, keep the device lock
as long as it will still meet password requirement after unification.
If not, prompt the user to set a new device lock and only unify
work challenge after a compliant device lock is set.
Bug: 148630506
Fix: 149682344
Test: make RunSettingsRoboTests
ROBOTEST_FILTER='ChooseLockGenericTest|ChooseLockPasswordTest|ChooseLockPatternTest|LockUnificationPreferenceControllerTest'
Change-Id: I99cde2650902927f6a4cc7c0cc7c6016e0dc283f
- Assign metrics category to perferences at an earlier stage in
DashboardFragment for better usability.
Bug: 137559984
Test: robotest
Change-Id: Icd4185efa0e655be20c4b673a1380fa42140923f
If one sim hide the preference and another one show the preference,
the preference always hide. The root cause is config value is wrong.
It should get config with subid.
Bug: 149800931
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
Change-Id: I91b551bc363b8ecb0a4b6b40e9de79c74ccd76fd
Merged-In: I91b551bc363b8ecb0a4b6b40e9de79c74ccd76fd
- getActiveSubscriptionIdList
To use getActiveSubscriptionInfoList to get subscription Id list
- getActiveSubscriptionInfoList(Z)
To use getActiveSubscriptionInfoList() instead
Bug: 144478274
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
make RunSettingsRoboTests ROBOTEST_FILTER=MobileNetworkUtilsTest
Change-Id: I4d6113561906af5c9e4ac7737aefac17c926059a
Merged-In: I4d6113561906af5c9e4ac7737aefac17c926059a
If one sim hide the preference and another one show the preference,
the preference always hide. The root cause is config value is wrong.
It should get config with subid.
Bug: 149800931
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
Change-Id: I91b551bc363b8ecb0a4b6b40e9de79c74ccd76fd
eSIM has a feature that requires an auth check before deletion, this
adds a security check before allowing the security feature to be turned
off.
TogglePreferenceController was changed to BasePreferenceController to
separate updating the state from UI press and updating from code.
Bug: 150568010
Test: mp settingsg and manual testing
Change-Id: I9e74e173720dce7b25d2d8a1e9004862cdb5e2e0
We decided to punt extra certificate to post-R.
This reverts commit c8a1960cf4.
Test: Treehugger
Bug: 112038744
Change-Id: Ic53e58944faebe7aa427975ebd77ce783bdddaf2
adds an authentication confirmation before deleting an eSim
this feature is turned on/off in the security page
Bug: 138861284
Test: mp settingsg
Change-Id: I32e0e3bff2091ec1097b3c37fa066d966e3373df
we shouldn't take users so deep into the settings IA because it's easy
to feel lost in settings after clicking on a result without additional
context.
Bug: 143055215
Test: robotest & manual
Change-Id: I337cb5ead31e1e4e7bf9be78132e90630f83ee43
This reverts commit 08f2a58459.
Reason for revert: design changed, we decide to take the user to
the entry after clicking on a search result.
It's opposite with what we did, so we revert related CL first.
Test: robotest
Change-Id: Iadb9a94a7ef7838be34a54499e2d934d6396c336
- getActiveSubscriptionIdList
To use getActiveSubscriptionInfoList to get subscription Id list
- getActiveSubscriptionInfoList(Z)
To use getActiveSubscriptionInfoList() instead
Bug: 144478274
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SimLockPreferenceControllerTest
make RunSettingsRoboTests ROBOTEST_FILTER=MobileNetworkUtilsTest
make RunSettingsRoboTests ROBOTEST_FILTER=TelephonyBasePreferenceControllerTest
Change-Id: I4d6113561906af5c9e4ac7737aefac17c926059a
- remove duplicate index preference
- default set searchable = false when the preference has fragment
- make some fragments indexable
Bug: 143057584
Test: robotest & manual
Change-Id: I4d64f6106d2f92f0a45e8c7e26388677f593f412
The new certificate can be installed from Settings ("Install a
certificate > App Source certificate"). The installation flow includes
a warning with user authorization to proceed, then a prompt for reboot
(now or later).
Installed certificate can be managed in "User credentials". The name is
currently a hash of hex numbers.
Upon deletion, there will also be a promot for reboot (now or later).
Test: Only see the new setting entry if feature is enabled
Test: Install from Settings, see the expected file name in
/data/misc/keysetore/user_0. Reboot also works.
Test: Able to see the certificate in Settings after installed
Test: Able to delete the certificate, which triggers confirmation dialog
to reboot. Reboot works.
Test: add certificate, see dialog, "not now" / tapping elsewhere does
nothing
Test: atest RestrictedEncryptionPreferenceControllerTest
Bug: 112038744
Change-Id: I7a4494ea0f243730df2212076588074d8774ae23
Users have reached out to us asking where are their settings and
cannot understand why things disappear.
Test: LockScreenPreferenceControllerTest
Change-Id: I05b182a26724fd14b0a8240e280f216ebf4d43b9
mPreferenceKey in BasePreferenceController is set via the second
argument of the constructor and has a getter. It doesn't look necessary
to override the getter to return the key. The given one also looks
inconsistent.
Test: atest com.android.settings.security
Bug: 139173976
Bug: 112038744
Change-Id: I6e20b46675308f7dbb8f82f7e372bf94f21e4bed
This is part of the changes to improve the UX and language for installing certificates.
Previously, the different types of certificate used the same installation flow.
Due to concerns around users installing CA certificates without understanding the conseqences,
this CL introduces a new warning dialog when a CA certificate is installed from settings.
Bug: 139173976
Test: Atest com.android.settings.security
manual testing from Settings by selecting the certificate type
preference and ensuring the installation flow still worked as expected.
Screenshot of the screen: https://hsv.googleplex.com/5046848484016128
Change-Id: If95bffd1e68f14734fb20e8cc4b60eeb1c372358
This is part of the changes to improve the UX and language for installing certificates.
Previously, the different types of certificate used the same installation flow. This CL
introduces a new settings page, where the type of certificate to be installed can be selected.
Bug: 139173976
Test: Atest com.android.settings.security
manual testing from Settings by selecting the certificate type
preference and ensuring the installation flow still worked as expected.
Change-Id: Iea7c91aa3801e429f0e22d29469958f4151b3cba
- Use SettingsLib Indexable
- Directly use resource id in getPreferenceScreenResId
Bug: 135053028
Test: roboletric
Change-Id: I05f493b55e8b6e2091301e9231ba5615215618e6
