We decided to punt extra certificate to post-R.
This reverts commit c8a1960cf4.
Test: Treehugger
Bug: 112038744
Change-Id: Ic53e58944faebe7aa427975ebd77ce783bdddaf2
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
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
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
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
