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
- Add function getXmlResourceId, Fragments don't need to write
xml resource id twice.
- Remove getPreferenceControllers from Indexable.java. Because it will
move to SettingsLib later for other apps which don't need this function
Bug: 135053028
Test: robolectric
Change-Id: I1e74519aecdea3dde64a5aea79f08d766dbc0003
This is part of the work to unify the manual certificate
installation flow (via "Install from storage" in the Settings
app) with the programmatic one (using
DevicePolicyManager.installKeyPair).
The change to CredentialStorage is the crux of this work, where
the key is no longer installed by calling Keystore directly.
Instead, a new AsyncTask, InstallKeyInKeyChain, was created, which
calls KeyChainService.installKeyPair with the key data and associated
certificates (as well as the UID of the designated service, to allow
installation into the WiFi Keystore).
Once that task completes, if the key was installed successfully,
then it is marked as user-selectable.
Test: Manual CtsVerifier tests: KeyChain Storage Test, CA Cert Notification Test
Test: cts-tradefed run commandAndExit cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Bug: 138375478
Change-Id: I7c4b4ea725a34307f58d27252c2958771001636f
Fixes: 134700640
Test: atest FaceSettingsLockscreenBypassPreferenceControllerTest
Test: enabling/disabling setting through Settings > Security > Face unlock
works as expected
Test: preference controller no longer seen in Settings > Display > Lock screen display
Change-Id: I54807ad92fac62398a2b9dab93dd638775a09c8d
Currently the code assumes that the user always has a pin or
password or pattern. If there's no password confirmKeyGuard() will
return false, so the acttivity will finish without doing anything.
With this change if there's no PIN/password/pattern, the credential
clearing task will be launched straightaway as the user presses "OK"
the confirmation prompt.
Bug: 127697771
Test: manual
Change-Id: Iac4af0abfc7430ed197e04f833bf203c3f66f52e
Relating to packages/apps/Settings
Bug: 120484642
Test: manual - test setting and unlocking passwords/pins/patterns.
automated - 20 of about 500 tests fail due to fragile synthetic
password test code.
Change-Id: Idec8338d141c185bef67ade12035fdb2fa9d17ea
This CL moves two toggles for trust agent extend unlock mode from
Security > Settings to Developer Options instead. It also updates some
of the configuration strings to reflect that this toggles behavior for
trust agents in general.
No new logic is being added here, this simply moves options intended
only for internal dogfooding to a more appropriate location in
preparation for the public Beta.
Bug: 111435975
Bug: 120871688
Test: Manually verified that the settings show up in Developer Options
and work as intended.
Change-Id: I2b6705d50fa783089a5c0dfabf76677af44209f7
This CL is essentially a one-line change that sets the
ONLY_ONE_TRUST_AGENT boolean to false.
Bug: 111431046
Test: Tested manually that this works correctly
Change-Id: Ia8f06235467e3223ef1e441a62d941a64a2d7c93
Additional clean-up work related to removal of screenlock dependency
from the credentials installation flow:
* Move the CredentialStorage class to security/ so that Enterprise team
owners could review changes to it.
* Remove the ConfigureKeyGuardDialog class as it is no longer used.
* Remove attempt to unlock KeyStore from VPN settings.
* Remove intents that will no longer be sent from the manifest.
Bug: 120901345
Test: m -j RunSettingsRoboTests
Test: Manual with CtsVerifier
Change-Id: Ia708ede3366892d74c148f3712a63858d5ab53b7
Add owners from the Android Enterprise team to source files that are
either owned or are mostly modified by the Android Enterprise team.
Test: gerrit uploader
Bug: 33166666
Change-Id: I8b4ec7c8895b02c45a6a14d52a3742334234904a
Replace getActiveSubscriptionInfoList() with
getActiveSubscriptionInfoList(true) so that settings will not show
hidden subscriptions to the user in various pages.
Bug: 121396526
Test: manual
Change-Id: I717999fed7d3a5a037914239694bef52df7c6207
This CL adds settings (and two toggle controls) that help configure
how trust (from Trust Agents) should be interpreted by the platform,
allowing them to function in a purely extend unlock mode (where they
can extend how long an already unlocked device stays unlocked, but
cannot unlock a locked device).
These are temporary settings to help with dogfooding the new behavior,
and will eventually be removed. b/120871688 below is the tracking bug
to remove them.
Bug: 111435975
Bug: 120871688
Test: Tested with SmartLock modalities to confirm behavior in both
legacy and extend unlock modes is WAI.
Change-Id: If25098520ba98e82c98cc51fb226d8f2ce1aba80
"Show password" will be moved in Settings > Privacy.
Since each of things should only exist in one place,
we remove it in Security page.
Test: visual
Bug: 116628158
Change-Id: I9f9083b88d7a20faa9bd28ded2cf8c3b9a5622fd
- Create some location icons for different scenario.
- Remove Location in Security page.
- Move Location Setting to top level page.
Test: robotest, visual
Bug: 116628158
Change-Id: I3f57ef49a396877bfbeaefea7dc4f4051e0ccc65
- Condition is already supported in PersonalSettingsFragment
- Suggestion is already supported in PersonalSettingsFragment
- Static/dynamic tiles are supported in TopLevelSettings
Change-Id: I51882e3bd0919ad95109baefac683d98667c11e3
Fixes: 110405144
Test: robotests
Settings page for gesture that allows the display to wake up.
Can be configured via overlays using config_dozeWakeScreenSensorType
Bug: 111414690
Test: manual
Test: make RunSettingsRoboTests ROBOTEST_FILTER=WakeScreenGesturePreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=WakeScreenGestureSettingsTest
Change-Id: Ic44f0ee9e781bda3b06cf4896217b324b9e3606c
This means that in some cases RestrictedLockUtils has to be used and in
some RestrictedLockUtilsInternal.
This causes a lot of trivial code changes.
I also updated the ordering of the imports in all affected files.
Bug: 110953302
Test: Built
make -j RunSettingsRoboTests
Change-Id: I9bdf8b89134f853bae4f38c81af436715c73e924
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
When possible, remove or simplify getNonIndexable() logic in fragments,
and use searchable="false" in xml to suppress index.
Change-Id: I5bdf5bc7d5494a64cdd9e230a51321a4b210af69
Fixes: 112608186
Test: robotest and manual search
Because there is no other options for 'None' or 'Swipe, there is no
necessary for showing the gear icon to show options.
'Lock screen message' could be found in
Settings > Display > Lock screen display.
Add testcase to verify the ChangeScreenLockPreferenceController's
behavior.
Test: make ROBOTEST_FILTER=ChangeScreenLockPreferenceControllerTest \
RunSettingsRoboTests -j40
Change-Id: Icdcd672261749d106162053d6f5228cee420a810
Fixes: 110848852
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
