Android implements the device encryption in a module of Vold (Volume Daemon) called cryptfs that makes the calls to the kernel which actually encrypt the device. When a user encrypts the device, Vold reboots the device and begins encrypting the data partition. During the encryption process Vold disables everything that is not a core service on the device. Android requires that the user create a passcode if they have not already set one at the beginning of the encryption process, which is one of the criticisms of the implementation since the decryption process is tied to the users screen unlock passcode which isn't super complex. Once the device is encrypted, according to the documentation at the AOSP page, the encrypted master key is stored in the footer of the data partition. As far as I know Android's implementation only encrypts the data partition, which would be user and app data. Once the device is encrypted the user will have to enter their passcode whenever the phone is locked. Before they can access their data, the kernel mounts a tmpfs/data that reads from the actually encrypted block devices. Your screen unlock passcode hashed and used to decrypt the master key. This is the description on the Notes on the encryption implementation.
The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.
Once the device is encrypted, the only way to undo it is to wipe data. I don't think that the default implementation you get in the AOSP source encrypts the SD card since not all android devices have a removable card, like the Galaxy Nexus, but I guess device manufacturers could add support in for that. The AOSP documentation on the FDE implementation is available here, Android Notes on Encryption Implementation. It's pretty thorough compared to some of the other AOSP docs. You might be interested to check out this blog post, Cold-boot encryption key recovery on an Android phone that has some information on attempting key recovery with CyanogenMod7.
His conclusions were:
The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.
But he was running CyanogenMod7 so I don't know if that is generally applicable to stock ROMs on devices or ROMs built straight from AOSP, but maybe there is some more information and research out there about the potential for key recovery.
Hope this helps some.
