tree e44b0ff21875a7fd51ca4d41639624a89002bc75
parent 47be3bb627879495b8b6426a7f5b5680d9b1ee6b
author Eric Biggers <ebiggers@google.com> 1697744830 +0000
committer Eric Biggers <ebiggers@google.com> 1698181258 +0000

Rename methods for unlocking, locking, and protecting CE storage

Users have many cryptographic keys, such as:

- Storage (file-based encryption) keys, both CE and DE
- Keystore super keys, both AfterFirstUnlock and UnlockedDeviceRequired
- Keystore client keys
- Synthetic password and the Keystore key that encrypts it

Unfortunately, many StorageManager, vold, and LockSettingsService
methods refer simply to "UserKey".  It isn't clear or consistent which
key(s) they mean.  For example, unlockUserKey unlocks CE storage,
createUserKey creates both the CE and DE keys, and
unlockUserKeyIfUnsecured unlocks CE storage but also does other things.
With the planned fixes to handle Keystore super keys more similarly to
the CE storage key (b/296464083), this confusion will increase further.

This CL is the first part of fixing this.  It renames the following
StorageManager methods to make it clear that they deal with CE storage:

   unlockUserKey => unlockCeStorage
   lockUserKey => lockCeStorage
   setUserKeyProtection => setCeStorageProtection

In addition, it starts the renaming of:

   isUserKeyUnlocked => isCeStorageUnlocked

However, isUserKeyUnlocked is used more widely and is also a @TestApi,
so for now it still exists alongside the new name.  Later CLs will
convert the remaining callers of isUserKeyUnlocked to use the new name.

No change in behavior except for some changed log messages.

Bug: 306204742
Flag: exempt, mechanical refactoring
Test: presubmit
Change-Id: I202ebbfd2b4f79fedb3ed120a8ad81500c126894