Since the class 'android.security.KeyStore' is going away, the UID_SELF
constant is being moved to a more appropriate location in KeyProperties.
Update code that references this constant to use the new location. No
change in behavior; the value of the constant remains the same.
Bug: 326508120
Test: build
Flag: NONE mechanical refactoring with no behavior change
Change-Id: Iaca5b20c37b7952df8f26a99b3f7391c5a7f01b6
* Only the Settings app can reset credentials
via com.android.credentials.RESET.
* com.android.credentials.INSTALL should still be
callable by CertInstaller.
Manual testing steps:
* Install certificate via Settings
* Verify unable to reset certificates via test app
provided in the bug (app-debug.apk)
* Verify able to reset certificates via Settings
* Verify com.android.credentials.INSTALL isn't changed
Bug: 200164168
Test: manual
Change-Id: I9dfde586616d004befbee529f2ae842d22795065
(cherry picked from commit 4c1272a921)
Merged-In: I9dfde586616d004befbee529f2ae842d22795065
Allows settings applications on other platforms to re-use values by
migrating to Settings.secure and moving HideNonSystemOverlayMixin to
SettingsLib.
Bug: 184967544
Test: atest SettingsUnitTests
Change-Id: If9aaeca29ebb8b481d75622934503e368d7435d3
Settings#CredentialStorage could be overlaid to
trick user into clearing all credentials.
Disallow non-system overlay on activity.
Test: Trigger the debug apk again, and no overlay
Bug: 176753731
Change-Id: I657de039d667f5aee0941336e9361ae04f056c33
Merged-In: I657de039d667f5aee0941336e9361ae04f056c33
Settings#CredentialStorage could be overlaid to
trick user into clearing all credentials.
Disallow non-system overlay on activity.
Test: Trigger the debug apk again, and no overlay
Bug: 176753731
Change-Id: I657de039d667f5aee0941336e9361ae04f056c33
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
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
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
