There are some inaccuracies and misleading information here:<p>- Encryption keys are derived from various inputs including the user credentials, not stored in the TEE. The TEE is involved in key derivation and is really supposed to use a hardware-bound key not directly accessible to software including itself but it's an implementation detail that varies by device.<p>- Pixel phones ship with file-based encryption. It's not an option. A phone either uses FDE or FBE. If it uses FBE, then it supports Direct Boot (partial functionally before the user credentials for encryption are enabled via device-encrypted storage class) and per-profile encryption keys. It enables a bunch of possible improvements like authenticated encryption down the road, but isn't much of a security improvement itself. Nexus 5X and 6P only offered a partial implementation as preview for developers tucked away in the hidden developer options, not a user-facing option.<p>- Credential-based encryption is enabled by default when setting a lockscreen method.<p>- Android has a Keystore, that's not exclusive to iOS.<p>- Android doesn't use ECB even though it's implied that only iOS uses unique keys per block. Android does too.<p>There's some more, but I don't have time to go through and nitpick. It's clearly written based on interpreting other people's blog posts, etc. rather than direct knowledge of how it works or even reading the documentation. It doesn't even sound like they have experience using an Android device based on some statements they make.<p>The post totally misses out on things like key derivation and which data is kept at rest. The article misses the real remaining iOS encryption advantages (FBE data classes that Android hasn't added yet and more of the key derivation work is hardware-bound) and just tries to make it sound good by stating things that are not unique to iOS.