Don't use the FDE flow to support metadata encryption; just provide a
vold service which directly mounts the volume and use that.
Bug: 63927601
Test: Boot Taimen to SUW with and without metadata encryption.
Change-Id: Ifc6a012c02c0ea66893020ed1d0da4cba6914aed
Bug: 64766105
Test: FBE boots, forceencrypt boots, set pattern, reboots, encryptable
boots and can be encrypted
Change-Id: I8c6dc0acdc37c3a6f1bea28d5607ed8938a4eb0c
This reverts commit 5687066dcc.
Reason for revert: ag/2966951 fixes the underlying problem.
Bug: 66739076
Bug: 65737446
Test: reboot-cycle.sh doesn't show a problem.
Change-Id: If4b9c5cc39e9e905d2b1e78f091609be641fc22a
vdc is typically invoked very early during boot, where it races with
vold starting up. The default getService() implementation waits a
whole second between retrying, so write a local getServiceAggressive()
that only waits 10ms between attempts.
Test: builds, boots
Bug: 65737446
Change-Id: I581db3afcf7f81dd7cd9cc84dc03194759861669
Init is no longer calling vdc with logwrapper, so it must take care of
logging to kmsg directly.
Test: observe logging in kmsg on boot and stderr on normal usage
Change-Id: Ie3e59da433bd154f121ce103dea0c59eb0bab069
Give callers the option of preparing CE and/or DE storage. The
framework will only prepare CE storage after the CE keys have been
unlocked for that user.
When init is calling enablecrypto, kick off the work in a thread so
that we can make other calls back into vold without causing
deadlock. Leaves blocking call intact for framework callers.
Clean up 'vdc' tool to send useful transaction numbers, and
actually watch for the matching result to come back. This fixes
race conditions when there are multiple 'vdc' callers.
Also add other system and misc directories to match spec.
Bug: 25796509
Change-Id: Ie4f853db6e387916b845d2b5fb92925d743b063d