I’ve reading something about encryption and got this:
One benefit of full-disk encryption is that it makes wiping the flash storage very fast.
All of the data stored on the device is stored encrypted under a particular encryption key K. The system also stores an encryption of K under the user’s PIN.
To wipe the entire drive, all you have to do is wipe the spot that stores the encryption of K (which is just one block). Once that block is gone, there is no way to decrypt the data on the drive (since K cannot be recovered), so the entire drive is as good as wiped. The wiping process can be done very quickly, since it only has to erase one block. This means that security / anti-theft apps can wipe your device if it gets stolen and you detect that it was stolen, and the wipe will take effect almost immediately. Without full-disk encryption, wiping the device might take a lot longer.
Yes, At and AMS do share various security keys and communicate via broadcasts; AT could stuck on resolving shared keys or its own storage certs in case when the encryption of system partition will be changed. On the other hand, if AT will use the generic script for i.e. formatting memory and SD card, it should not find all the data, because the encryption is different or the sums of stacks will not fit. So the AT functionality wil not be working OK and might cause strange behavior or force close behind the memory.
Hope the programmers answer again the final word.
All that I read about Android encryption is frightening: we can’t do some updates, ROM flashes, etc. I can’t remember but I always kept the idea that encryption does not fit with my usage profile.
So let us answer it here; the android encryption is based on dm-crypt and is provided by linux kernel and all the operation is quite tricky. Basic encryption / decryption is done on file system, so mainly /data directory (where applications data and applications are placed) is maintained. There is framework in DVM, which is providing the mount and file operations services with encrypted files. The problem is with the initial password insert, because the system partition is basically still encrypted and the password is not provided - there is some minimal UI for providing it, but, unfortunatelly, it runs with system services and apps, which has to be restarted, file system remounted and services must be triggered to run again with synced data. Here, as you may be can see now, the avast scaner or file shield can experience very difficult times - in case you have crypted your device, our scanner can extensively drain battery (application restart and getting priority in apps race) and CPU; in the worst scenario (encryption key is corrupted) the /data partition is not mounted and no application will be able to run, or, will force close soon. So, generally said, it is safe to use avast on encrypted device, but encryption itself has many traps along.