Key uses mostly public Keystore API which works the same for Keystore
and Keystore 2.0. The only exception is:
 * The public API does not allow for grants.
In this cases we fall back on hidden API.

Keystore 2.0 and KeyMint do not allow for key attestation outside of
key generation or import, so this patch also removes attestKey from
the KeyChainService implementation.

Test: KeyChain tests and CTS tests.
Bug: 171305387
Merged-In: Ieefaba81e36dc0adc87d0eebde8a0901c1687960
Change-Id: Ieefaba81e36dc0adc87d0eebde8a0901c1687960

This CL adds the underlying method to KeyChain. The method
returns UIDs of the grantee packages.

Bug: 179180345
Test: atest com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testKeyManagement
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testDelegatedCertInstallerDirectly
Test: atest android.admin.cts.DevicePolicyManagerTest
Test: atest KeyChainTests
Test: m RunKeyChainRoboTests
Change-Id: I73529e8871fd35ddff29f4cfddae97ed47587407
Merged-In: I73529e8871fd35ddff29f4cfddae97ed47587407

Background
* This is part of the work to support
  a credential management app on
  unmanaged devices.
Changes
* Add implementation for KeyChain API
  methods to manage the credential
  management app
* Intercept KeyChainActivity to choose
  alias provided by credential management
  app if provided.

Manual Testing
* Install TestDPC
* Request to manage credentials (fire intent).
  Add policy mapping: 'com.android.chrome' ->
  'client.badssl.com:443' -> 'testAlias'
* Install badssl user certificate as credential
  management app (TestDPC). Set alias to 'testAlias'
* Check certificate is installed in Settings
* Go to chrome > client.badssl.com
* Verify no certificate selection prompt is
  displayed. User is automatically authenticated.
* Remove credential management app from Settings
  Security > Encryption and credentials >
  Certificate management app
* Verify credential management app is removed and
  'testAlias' is uninstalled.

Bug: 179180345
Test: Manual Testing
      atest com.android.keychain.KeyChainServiceRoboTest

Change-Id: Ib3479c3b7bbd54cbc8e0782c8c58898399eda349
Merged-In: Ib3479c3b7bbd54cbc8e0782c8c58898399eda349

This change includes the following commits from internal R branch:

ecea8d8 Adding modern KeyChain tests
5f89de1 Expanding KeyChain service tests
bb63fca KeyChain: Adding user-selectability tests
83f9c58 Add tests for key generation & attestation
9b8aa0d KeyChain: Allow specifying UID of installed key
6e5d428 KeyChain: Delete obsolete test
3dbbb36 Fix KeyChain Robolectric tests
7cb0919 Show a dialog while certificates are loaded
e6435a7 KeyChain tests: Add TEST_MAPPING
be8a135 Throw IllegalArgumentException for invalid alias
114a9cc Add KEY_ALIAS_SELECTION_DENIED constant processing.
51a9b9f Log user ID when installing & removing CA certs
cbc62f2 Fix Cert Chooser dialog
3a91362 Inspect issuers when deciding on a certificate to display
03a1dc6 Fix theming of KeyChain activities
d1088a4 Fix cert selection dialog background
e18363f Protect against NullPointerException
02ff266 Add an exported flag in manifest
0a00ed1 Make cert selection prompt respect dark mode
fb9bae3 KeyChain: Log aliases from DPC
77192a0 Log certificate-related events
897f391 Revert "Add check for misprovisioned Pixel 2 device."

Bug: 161347472
Test: atest KeyChainTests
Change-Id: Id44c8cef275b9de7ed39d8033b19d662b44a638c

Handle better the case where a new key is installed/generated,
overriding a key that was associated with the same alias:
* When a new key is generated using an existing alias, remove the
  existing grants first - making the behaviour consistent with key
  import.
* When a key is removed, show a warning in the log that grants
  associated with this alias are lost.
* If the caller has no grant to access the key or the key with the
  specified alias does not exist, return null rather than throw (which
  is consistent with the documentation).

Bug: 123563258
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Test: m RunKeyChainRoboTests
Change-Id: I36a5941093545f757bdbff7360311212f4183e57

When the KeyChain database is created or upgraded, create entries in the
grants table for keys that already exist in KeyStore.

This fixes a bug where keys that were installed in KeyStore but never
used (in O) are accessible in newer releases.

Bug: 120039077
Test: m -j RunKeyChainRoboTests
Change-Id: Ic4935c80f37d77a3c83fea172f30fb42623b3ff6

Bug: 117904612
Test: make -j56 RunKeyChainRoboTests
Change-Id: I2a40fe8727eae089b613713a3acc55cd8c3e1331

The caller to KeyChain.choosePrivateKeyAlias can restrict the set of
aliases that are displayed to the user to select from by specifying the
issuers that the associated certificates should be issued by or the key
types that these certificates should contain.

Until now this functionality was not implemented. This was mostly
affecting Chrome
(https://bugs.chromium.org/p/chromium/issues/detail?id=753756).

Support this functionality by passing the issuers and key types into the
KeyChainActivity (from KeyChain) and, prior to displaying the aliases
associated with the certificates, check if each certificate adheres to
the criteria (key type, issues) specified.

Bug: 62910781
Test: m -j RunKeyChainRoboTests
Change-Id: Ia8aed02b020c8c17a9e15a8b6e395c32834d5332

Due to a bug, it is possible to have a "V1" KeyChain grants.db database
that is not actually V1, in the sense that it already contains the
userselectable table (this would happen on devices upgrading from P
to P).

That caused the code added for handling database upgrades to throw an
exception if it found a V1 database and tried to create the
userselectable table, when it already exists.

To resolve the issue, find out if the userselectable table exists during
a V1 database upgrade, and only proceed with creating and filling it if
it does not already exist.

This CL also adds a future-proofing test to make sure that the content
of V2 databases does not get modified during future upgrades.

Bug: 76143437
Test: m -j RunKeyChainRoboTests
Change-Id: Ia03cd132084ec740cc16de7cc5440fcf4e494765

A new table was added to KeyChain's grants.db, storing the
user-visibilty state of each alias KeyChain manages.

Formerly it was not created during an upgrade, which led to existing
keys being classified as non-user-selectable and essentially not usable.

Now, during upgrade, the table for user-visibility is created and the
existing aliases are all set as user-selectable in it.

Test: m -j RunKeyChainRoboTests
Bug: 73898958
Change-Id: I3b92a957f4e949c13363769ece531af438895ff9