Glossary
File-Based Encryption (FBE)
File-based encryption is how Android encrypts user data per file with keys tied to the lock screen, splitting storage into CE and DE classes.
File-based encryption (FBE) is the storage encryption scheme Android has used since Android 7 and requires for devices launching with Android 10 or later (full-disk encryption was dropped entirely in Android 13). Instead of one key for the whole userdata partition, each file's contents and name are encrypted with keys that belong to a storage class.
| Storage class | Available | Typical paths |
|---|---|---|
| Device Encrypted (DE) | After boot, before the user unlocks | /data/user_de/<user>/, /data/system_de/<user>/, /data/misc_de/<user>/, and system areas such as /data/system/ and /data/misc/ |
| Credential Encrypted (CE) | Only after the first unlock since boot | /data/user/<user>/ (/data/data/), /data/system_ce/<user>/, /data/misc_ce/<user>/, shared storage /data/media/<user>/ |
CE keys are protected by the user's PIN, pattern or password, usually with help from the Keystore and a hardware-backed secure element or TEE. That is why the lock state matters so much in acquisition: a phone in BFU (before first unlock) exposes only DE data even to a privileged extraction, while a phone in AFU (after first unlock) has CE keys in memory. Most devices launching with Android 11 or later also use metadata encryption, so a raw image of userdata without keys is ciphertext from the first block.
Practical consequences: keep a seized AFU phone powered and charging, record its lock state before anything else, and expect a chip-off or raw physical image of a modern phone to be unreadable. Apps choose where they store data, so some evidence (the telephony provider's mmssms.db, Wi-Fi configuration) sits in DE storage while most app sandboxes are CE. See Android acquisition methods and full file system extraction.