Canonical explanation of Android Encryption and Vulnerabilities
I envision it works like this:


Storage is encrypted using synchronous random key.
When the user chooses or changes a password that is based on whatever input, be it a password comprised of letters and numbers and characters, or be it a pin code, or pattern swipe, or finger print, or any other input, an asynchronous encryption algorithm is used to encrypt the master key, such that correct identification ends up decrypting the input resulting in the master key, which in turn makes it possible to encrypt and decrypt storage.
The moment the user logs out, the memory holding the master key is overwritten


The big trick here is that asynchronous encrypting of the master key. Once Android has the master key, it has the ability to exchange data with the storage. Only when the user is logged in, that master key is known. Asynchronous encryption is what is called public key encryption. What happens is that a public key encrypts data (the master key in this case), and a private key decrypts data. Not to be confused with the storage encryption here. The storage is just synchronous encryption. There the same key is used to encrypt and decrypt. But the finding/retrieval of that "master" key, is the biggie. It means that if at one point you have a weak login method, like for intance "1234" as a pincode, and you change your mind, and change the pincode to "5364", which is harder to guess, unless that earlier "1234" was stolen, snooped on, at any point, the security has just become better. Same deal when changing the login method to a full password that is impossible to guess or dictionary attack. The storage itself does not need to be re-encrypted at all. It's all about hiding that master key - internally. The user never sees that master key, because it's most probably just a random hash code of sorts - nothing will ever "find" or "guess" that hash code. Not even the NSA or any other security body on the planet could ever find a matching key like that.
The only attack vector is hoping for a weakness on the user's part. Perhaps the user chose a pincode login. If it's 4 digits, then it's a maximum of 10000 possible pincodes. The OS might "block" the device after trying out a few in a short time. The solution is then to "hack" the OS, so that it becomes possible to try all possible pincodes without the OS intervening and blocking the device. I believe that is how the FBI eventually got access to a phone of a criminal. A third party company (some Israeli company from what I recall) did the hacking for the FBI I think. They bypassed that pincode-try limit.
If the login is a full password, and if the user picked a strong password, and you're sol. Not in a life time with all the cpu power on the planet will hack that in a million years. I'm not buying any of the NSA can decrypt anything rumors. I think those people watched one too many men-in-black movies. All one has to do is look at the scientific documents about the various encryption algorithms (eg. AES), and you'll know that hacking simply won't happen, except in the olden days when there were 40 bit keys. Those days are long gone. AES128 is already unhackable I think, and if anyone is concerned, jumping to AES256 makes it more secure by a magnitude to the size of the universe pretty much.
Maybe one day quantum computers might decrypt it, but I'm skeptical. Not sure if it is possible to have a probability system simply highlight the solution. We'll see about that, eventually. Perhaps that's a few lifetimes away anyway. Nothing to worry about right now.

So, end of day, the security limitation lies entirely on the login method that is used. One can change the method without having to re-encrypt the storage. All this because of the asynchronous public key encryption of the master key.