diff options
| author | Eran Messeri <eranm@google.com> | 2017-11-20 12:48:52 +0000 |
|---|---|---|
| committer | Eran Messeri <eranm@google.com> | 2017-11-21 17:01:39 +0000 |
| commit | 19d19048e46a44f9cd92f9b3c2b45d9603283f15 (patch) | |
| tree | e42d13f7541b8f038533d58780fe708745feebd8 /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 5f52b4dfe539e2c8226e173630645df1285daae5 (diff) | |
DevicePolicyManager: Make installed keys user-selectable by default.
After Change-Id: Ibaba2ddd4f94fced1a2a7bfcfb91189302ec7f3a was merged,
KeyChain, by default, made keys installed in it not user-selectable,
which means users could not choose those keys in the Certificate
Selection prompt.
This is the correct behaviour (secure by default), but means the
DevicePolicyManager has to explicitly set keys as user-selectable
to be compatible with the previous behaviour.
This CL does the following:
* Adding an installKeyPair variant to the DevicePolicyManager to
allow specifying user-selectability of the key.
* Make old installKeyPair variants delegate to the new variant,
with the default of setting installed keys user-selectable.
* Modify the DevicePolicyManager service definition and service to
take the extra user-selectability parameter and set the value
in KeyChain.
Note that the reason the CTS test started failing is not related to
this change but a CTS Verifier test should catch the problem this
CL is solving.
Part of the fix for b/69337278
Bug: 69337278
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement
Change-Id: Ifc240ed4a20a9d00bc6140dfb45bd1140e1f8260
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions