[General Topics] optimumpro:
I have been invited by the OP to say a few words about security:

First of all you might want to cross-reference Security Discussion thread here:

http://xdaforums.com/general/security . There is plenty of info there.

Second, and maybe this should be the first: you have to understand one limitation: Everything we talk about is a protection against software exploits. If you are targeted by 3 letter agencies, they won't go that way: they will simply enter your phone over the air through a modem , which is located in your baseband partition. Baseband is a closed source mini operating system with its own kernel. And what's even worse is that baseband is hooked directly into phone's hardware: camera, mike, gps module and ram. In addition, baseband is usually hidden in the same module where your cpu sits, so there is nothing you can do about it (closed source and physically inaccessible).

A few words about disk encryption. First of all, it is not FDE (full disk encryption), the way it is done in Linux with cryptsetup and luks. In Android, you can only encrypt data partition, so your system is open. Second, until LP 5.1.1, software based encryption could be defeated by Google. Just do a search and you will find info referencing Google being able to reset encryption password and make data available in response to a search warrant. Apparently, this has to do with a default password, which is literally "default_password" hardcoded in sources). Now, reportedly this could no longer be done in LP 5.1.1 because of hardware based encryption. However, a word of caution here: there are 2 ways of encrypting data with the help of hardware in Android. By the way, there is the third way, the way it is done on Iphone, where your master key sits in a hardware module. Well, there is a special data acquisition software that can get that key in about 40 seconds. So, it is backdoored and that's the problem with hardware based encryption. Now, back to Android's 2 ways: one way is when you use linux type luks software encryption (the way it was done pre lollipop 5.1), but the key is signed with a certificate that sits in a hardware module. This way, it would be difficult to dump data image and do bruteforcing offline. So, the snoop will have to work on the phone. But even if he gets the certificate, he would still need to deal with luks, and there are ways of changing sources to make that virtually impossible. That's the preferred way: always mixing software with hardware, so that even if hardware is backdoored, there is still software to overcome. This is how encryption is done on LP 5.1.1 by default. The other way is when encryption itself is done by a proprietary (usually cpu manufacturer) encryption. To give you an example with Quallcom: they have developed dm_req_crypt instead of linux's dm_crypt where everything, encryption, random number generation and enthropy is controlled by the chip. And we have no idea how it is done. See a problem with that? Closed source and total control. If Quallcom compromised enthropy, then your encryption is futile. So, not a good option. But luckily, the second way is available, but not implemented by default, yet...