File-based encryption security and backup/restore considerations I'm evaluating making the move to file-based encryption on my device, but am having trouble finding satisfying answers to the following questions:


Apps can place data in either a Credential Encrypted (CE) or Device Encrypted (DE) storage, but does this necessarily mean all files in /data/ are encrypted? What if I run echo 1 &gt; /data/test.txt from a shell? Is test.txt encrypted via CE?
I want my data to be protected with more than a four-digit PIN. Can a separate boot passphrase still be used to unlock encryption?
To enable FBE, /data/ needs to be wiped. Can I restore a pre-FBE TWRP backup after enabling it to fully restore my data?
Does TWRP still prompt for encryption password at boot as it does with full-disk encryption?
Can I make TWRP not prompt for encryption password so I can run automated backups via OpenRecoveryScript?
If I create a backup without providing my encryption password, is TWRP smart enough to restore the encrypted data as-is on restore?
Are there any other TWRP backup or restore caveats I should be aware of before diving in?
Apps can place data in either a Credential Encrypted (CE) or Device Encrypted (DE) storage, but does this necessarily mean all files in /data/ are encrypted?

What will be encrypted and which key is used depends on the encryption policy. The encryption policy specifies on a per-directory base what to encrypt. Exclusions (no encryption) seem to be possible, too.
The currently used policy us hard-coded in the source code of Android.
There you can read that currently some exclusions are known:

/data/apex
/data/data
/data/lost+found
/data/media
/data/misc_ce
/data/misc_de
/data/system_ce
/data/system_de
/data/user
/data/user_de
/data/vendor_ce
/data/vendor_de

For some of those exclusions there is an encryption policy for a subdirectory specified. However If I understand it correctly placing a files directly into one of those directories means that no encryption will be applied.