Embeded industry make poor drivers. Google is trying to fix that mess... by using as many apis as possible (so poor state of drivers is clearly visible and manufacturers NEED to take action).
So maybe this time they just said. "*Facepalm* That's WHAT?", and started their own.
Alternatively, Google wants unified capabilities for their crypto chips, and rolled sleeves them-selfs.
Too bad doing the encryption/decryption on the CPU will cause higher power consumption during disk I/O. Of course, there are people who don't trust black box encryption accelerators so that could be a reason. Then again, the ARM world is full of closed proprietary hardware and software. Another one won't make much difference.
It is either not being used, or is being used improperly by Google on the Nexus devices:
<link to codeaurora removed as anandtech thinks it's spam, even though it's a link to CodeAurora's gitweb, specifically to the dm-req-crypt implementation within the vold repo>
AOSP (and the Nexus devices) don't have dm-req-crypt support in vold. That's inefficient since it leads to (my guess) a DMA setup and teardown for every 512 bytes of data.
This isn't the first time Google has left out Qualcomm performance features. Qualcomm's open-source bionic Krait optimizations have been in Qualcomm's CAF reference repos with an Apache license since 4.1 or 4.2 or so - Google still hadn't integrated all of them as of 4.4
Qualcomm also has a bunch of other optimizations that are closed-source so it's understandable that Google wouldn't use them, but the Krait bionic optimizations and lack of dm-req-crypt both appear to be Google ignoring opensource components that have a very high performance payoff.
Wow, that performance loss on the 6 should definitely have been considered unacceptable for the Nexus 6. Storage speed is such a large part of the feel of smartphone performance. To be honest, I'd leave it off, there's not much of import on my phones anyways, theifs can have my music.
So, is the Nexus 5 using FDE on Lollipop? Why does it do so much better, both than the 6 and itself on 4.4? Just a bug? Or is it using a different type of encryption, or none at all?
Only new devices will have it enabled, new as in shipping with Lollipop. The Nexus 5 gets an OTA to Lollipop so it won't just enable itself, but I can't speak for users who flash an image from Google. I have the Nexus 5 rolled back to KitKat for the time being for doing version comparisons in the Android Lollipop review.
I'd imagine they are expecting the arm-v8a cryptographic extensions to handle the problem. That's one of the reasons why I thought/hoped that the n6 would be aarch64.
I'm sure it won't have much of an impact, but would you guys be able to run the battery tests again with encryption off? Kinda curious to see if it effects battery performance at all. (I doubt it would because it shouldn't be writing anything to disk during this time).
"Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display. "
Do you notice the same frame rate issues on other QHD devices using Snapdradon 805?
Could you do a battery life test on a non FDE device as well, please ? I was shocked that the nexus 6 did that much worse than the nexus 5, this implementation of encryption in software must attribute towards lower power efficiency.
I just sent back my Nexus 9. Coming from an iPad air those lags are not acceptable. I can't stand a wallpaper that reloads when I tap the home button. Lollipop is far from a finished product.
Easy enough to fix with a third-party launcher that offers the ability to stay in memory.
But I have to wonder why you even bothered with Android if you want everything handed to you on a platter?
I get that as far as initial polish and presentation go, Android still lags though it's been making great strides. But to forego one of Android's chief advantages (changing things to get what you want) and just return a device?
It's like buying a sports car and taking it back because you can't do all your driving in second gear. Or buying a leatherman only for the screwdriver.
Why do you give google get a free pass for releasing unfinished products? Very bizarre!
A more valid car analogy would be buying a car with door locks that only activate half the time. Your solution is to replace the locks while 99.9% of the world would take the POS back for a refund.
I'm a tech enthusiast and I like both iOS and Android. There are pros and cons on both. This is not the point. But the Nexus 9 to me RIGHT NOW is a beta product. I didn't personally tried other devices with lollipop but what I heard is that the problems are the same (lags, unprectidable performances,...)
I feel for all the android fanbois that buy an N9 because it's an android tablet. They are getting screwed for their money considering the value of an iPad air 2.
So how come GPU with 50% more horsepower, and 30GB/s based S805, its still not enough? i think we are seeing lack of software optimizations, not QHD/big resolutions lags.
Because QHD represents a 78 percent increase in pixels of 1080p?
Even if chip companies say they "support QHD" or "4k" they may do it JUST BARELY, which means you really should wait at least until the 3rd generation of a GPU "supporting QHD" before you start using QHD. Ideally you should use a GPU that is at least 4x more powerful than the one that "just barely" supports a certain resolution, to minimize stress/power consumption.
I've been particularly loud about this subject for the past year. Mobile GPUs are at least 2 generations behind compared to current mobile screen resolutions IMHO. The resolution spec race *above a certain point* is mobile experience's worst enemy. I believe Snapdragon 801 (and similar) GPUs are PERFECT for 720p. On the other hand, Snapdragon 805 (and current Mali T760MP6) is great for 1080p max.
Mind you, current ~5" 1080p panels are far from perfect, and consumers will appreciate more improvement to these panels instead of higher resolutions, especially since we've reached a point of diminishing returns on anything above 440ppi. If someone can tell the sub-pixels apart on a 5" 1080p panel it'll most likely be due to pentile or similar sub-pixel arrangements.
I seriously hope OEMs like Samsung, Sony, and HTC stick with 5-5.2" 1080p panels for 2015 so we can actually FEEL the difference 20nm and ARMv8 chips will have to offer. We're BARELY noticing the performance and efficiency benefits of the newer silicon. Or at least (for God's sake) allow us to revert back to 720p in the power options if they opt for 1440p panels (since we'll have perfect scaling that way, and arguably better 720p panels at that :P . You know, since each pixel will have significantly more sub-pixels in a 1440p panel running at 720p).
I'll be picking up (and recommending) whoever sticks with 1080p in a decent flagship in 2015. They'll all have 64bit processors and faster AES anyway, so this article's issues won't be a problem for any of these flagships.
Considering their Compact versions tend to be one screen resolution lower than the full-sized Xperia, if the Z4 is 1440p next year, then the Z4 Compact should be 1080p. :)
"Admitting" isn't quite what it is. I've mentioned several times before that I like their "current" CPU/GPU to screen resolution configurations. But that doesn't mean Apple is doing that for the sake of what I mentioned above. Don't forget that the iPhone 4/4S had a relatively underpowered GPU/CPU pushing its resolution, and the same true about the first two retina iPads... It's only NOW that their SoCs are keeping up with the resolutions they have on their devices, and it's only recently that iOS can somewhat handle non-doubled-scaling to certain point (not perfectly though). Again, it's not that Apple are "doing it right", it's more like there isn't any way else they can do it, and I so to happen the "current" configuration.
I would argue that they are doing it for that sake. Retina display was a statement: after this, you get hugely diminishing returns. Let's focus on the fastest UI possible and implement with compiled apps! (yay no ART!)
This is something that's bugged me about Android phone OEMs: pushing the GPUs to their max, instead of using "too much GPU" for the resolution.
A Snapdragon 800 or 801 (Adreno 330) with a 720p screen would fly. Instead, they're saddled with 1080p screens where they aren't always smooth.
A Snapdragon 805 (Adreno 420) with a 1080p screen would fly. Instead, they're saddled with 1440p screen where they aren't always smooth.
And so on.
Just because a GPU "supports" a resolution doesn't mean it should be run at that resolution. Even "supporting" a resolution at 60 fps isn't enough these days.
The problem is NOT enabling encryption by default, but doing it on devices that don't have hardware acceleration for AES encryption - such as every single device with an ARMv8 chip. Those devices should have no problem with default encryption.
Except there are almost no ARMv8 Android devices. The point is that enabling it by default is a problem when none of the devices running your OS have hardware support.
Can you add run the same tests for a Nexus 9? Since that uses ARMv8, it should support encryption in hardware and hopefully less of a hit in read/write speeds.
Lots of reports of original nexus 7 (2012) being rendered pretty unusable with lollypop. I have one (not updated yet) and have been holding off as performance is already terrible with kitkat due to it having very very bad flash memory. Perhaps this is the reason why lollipop is killing it?
Only Lollipop shipped devices have encryption enabled by default (currently Nexus 6 & Nexus 9). If you update an older device to Lollipop, you have to manually enable encryption in the Security settings.
I just got the OTA update for my Nexus 10 yesterday to Lollipop, haven't noticed any slow downs, it seems to be performing exactly the same actually. It "supposedly" should be faster since it's now using the ART runtime, but it should only affect app startups and such.
Oh, one more request please. An article with a showdown/comparison of all 2014 flagships after being updated to Android 5.0 (5.1?) later this year since most of them will be updated early December. "Before and after" performance and battery life charts would be nice.
I hope they get this sorted out soon - as I plan to get a Nexus 6 to replace my Nexus 5.
My subjective experience with my year old Nexus 5 - Since the OTA 5.0 Upgrade I have seen a HUGE speed increase with everything I can throw at it - it's almost like it's a completely different phone now. I will not be a happy camper if the N6 is actually slower than my (old) N5. As long as we have the option to turn it off while Google figures this out - as they prob will do sooner or later like most things that don't work right at launch time.
Perhaps this is a stupid question, but can I deduce from the fact that you needed a non-FDE image from Motorola to do this analysis that it is not possible to (just) turn FDE off? In other words, if you buy a new device that has FDE enabled, you're stuck with FDE?
A PIN or password lock will keep the contents of your phone safe from 99.999% of thieves. I see no advantage to NAND encryption for consumers except for the most highly sensitive data. I'd rather Google focus more on connectivity encryption and generally protecting online privacy via Tor-like solutions.
This isn't about security; it's about complying with a California law requiring that phone owners have a "kill switch" for their phone: a way to delete all their data by remote if it gets lost or stolen. The best way to do that is encrypt the data, and if the kill code is sent, the phone securely deletes the encryption keys.
"Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties."
You need to read up on how android's encryption work in version 5.0, as the system no longer relies on passcodes for default encryption but 128 to 256 generated keys. This is used REGARDLESS if the user sets a passcode or not, or uses a pattern lock.
Setting a password will be used to re encrypt the key, but is no longer necessary to use.
Passwords are generated and hashed using scrypt multiple times and for devices that support it, the encryption key is signed by a key stored in a protected memory area. Thus, offline attacks against the key are useless.
Come on guys, you are supposed to be at the top of your game.
All this talk about big resolution is wrong imho. There was devices with S4 pro, and 1200p (nexus 7 2013) which absolutely flies when you enable ART. I have a hard time to believe that gpu 2x faster cant push 1440p, same can be said for S600 - HTC M7 and other S600 based 1080p devices with stock or close to stock Android.
While it's true that this protects against offline attacks, the issue is that it's trivial to turn the device on and pull user data over adb if a password isn't used as well.
I'm aware. When I wrote that it's protected by the passcode but that things are encrypted regardless, it was meant to imply that you don't need the passcode for FDE to work. It doesn't change that users aren't really protected unless they put a passcode because someone who gets a hold of your device without a passcode can just access everything freely anyway.
With that kind of performance hit unless you are a terrorist guarding your attack plans the encryption just isn't worth it. The FDE is a good idea though and their first try was a valiant effort. I'm sure with the nexus 7 the SOC designers will have some fixed function in the SOC to fix this problem. I'm happy with my galaxy note 2 still. It's only 2 years old and still does everything I need it to do quickly. I was going to get a note 4 for the 700mhz block a support for t-mobile but now that performance has started to hit a plateau I expect my next phone to last a good 5-6 years and for it to last that long I'm going to wait for 64 bit as I have the feeling later versions of android are going to require 64 bit to run. So if i want to use cyanogenmod to keep my phone up to date for 6 years 64 bit is going to be crucial. I'm sure next fall the note 5 will most likely use the snapdragon 810 for some 64 bit action.
If only apple would sell the A8 chip for the galaxy note boy o boy would that be sweet. As much as I hate the iphone apples A8 soc is miles ahead of every other phone soc. The more powerful dual cores is such a better design than less powerful 4 cores as single threaded performance is really what determines the speed of almost every single app. Multi tasking is rarely needed on a phone so having your power budget. spread over 2 cores instead of 4 is just much better in every way. Also the powervr graphics are the best SoC graphics design as well. power vr 6 series consistently slaughters adreno and mali and nvidia can't get their single kepler core design into a phone which is the only hope of dethroning power vr 6 series and their 7 series is around the corner.
What I would love to see happen is nvidia really step their game up and make their next gen erista chip fit in a phones tdp with some rly nice 2nd gen dual core denver cpu's and a maxwell smm for the graphics as this is really the only hope for android to catch up to apples superior soc design. Since maxwell is so much more power efficient than kepler and with efficiencies they can gain in 2nd generation of denver dual core cpu. Nvidia may finally crack the code and remove qualcomm from having the fastest android phone soc. A galaxy note 5 with 2nd gen dual core denver cpu's and maxwell gpu would really be an amazing phone that could finally keep up with apples performance.
You shouldn't publish a front-page table of results that are totally bogus. That's non-standard practice and many people will overlook the text below which explains that these could not be real.
The first paragraph explains that the table that follows demonstrates how Androbench provides inaccurate results under Lollipop. The table follows the explanation.
Maybe Google are doing this to force OEMs to use better flash? It seems obvious that android devices skimp on this when compared to the flash performance seen on Apple's devices. If that was the point, though, they should perhaps have set a better example with the N6?
Not sure what the point of encryption on the phone is for android devices. All info gets sent through Google servers (they are just an advertising company) which law enforcement has access to already...
This is a disaster for google. In order for their iphone killer to eek even barely close to the iphone in performance you have to remove security features. ouch. they should just disable it across the board to make the fbi happy and to make it easier for thieves to root the phone and resell it. let android deal with device theft.
Great article. Can you guys do the same test on ios 8 with an iPhone and iPad? Wondering if Apple suffers from same degradation. Should be easy enough, since seeing our clearing the passcode enables our disables encryption on ios 8.
No they don't, you can see that in the NAND performance from the iPhone 6 review. Every iOS device has an AES 256 crypto engine built into the direct memory access path between the system memory and flash.
Thanks for the explanation, I have done some more research, and the statement above seems to be true, at least for every phone since iphone 5s, and every tablet since the Air 1. While Apple is not perfect, this demonstrates why the ios platform remains the superior mobile platform.
This is not Nexus 9 or Android 5.0 specific. On my Nexus 5 with Android 4.4.4 Wallpaper reloads often, even with >1GB of free RAM. This is just crappy Java garbage collection.
Using Action Launcher which has the "stay in memory" option on 4.4.4 Nexus 5, the wallpaper (non animated) is reloading every 2-3 hours, causing 1-2 sec lag.
Hopefully Google won't back down from having this enabled and sites like AnandTech and others can continue to remind people that the state of storage in mobile (phones and tablets) is truly abysmal.
Maybe Google got fed up with trying to get manufacturer's to use decent storage and decided to force FDE to force their hands. I can hope, at least... But then they didn't make Motorola use a decent storage solution for the N6, so probably not.
I don't get why this causes such a huge performance hit. I've been using FDE (in Linux) on spinning disks and SSDs for years with parely any noticeable preformance issues. And this is entirely software driven encryption (meaning the CPU has to do the work of encrypting/decrypting). It's not built into the hard drives. Lots of tests have shown on desktops, this kind of FDE causes barely a blip in read/write performance.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
91 Comments
Back to Article
jruhe - Thursday, November 20, 2014 - link
I wonder what the "Qualcomm hardware cryptographic engine" (qce & qce40 & qce50) in Snapdragon SoCs is good for.Krysto - Thursday, November 20, 2014 - link
No idea, but I heard Google didn't want to use Qualcomm's drivers for it. Maybe because they couldn't have made them open source - or who knows.przemo_li - Friday, November 21, 2014 - link
That would be first!Reality may be smplier.
Embeded industry make poor drivers. Google is trying to fix that mess... by using as many apis as possible (so poor state of drivers is clearly visible and manufacturers NEED to take action).
So maybe this time they just said. "*Facepalm* That's WHAT?", and started their own.
Alternatively, Google wants unified capabilities for their crypto chips, and rolled sleeves them-selfs.
aden32 - Thursday, November 20, 2014 - link
Too bad doing the encryption/decryption on the CPU will cause higher power consumption during disk I/O. Of course, there are people who don't trust black box encryption accelerators so that could be a reason. Then again, the ARM world is full of closed proprietary hardware and software. Another one won't make much difference.Entropy512 - Monday, November 24, 2014 - link
It is either not being used, or is being used improperly by Google on the Nexus devices:<link to codeaurora removed as anandtech thinks it's spam, even though it's a link to CodeAurora's gitweb, specifically to the dm-req-crypt implementation within the vold repo>
AOSP (and the Nexus devices) don't have dm-req-crypt support in vold. That's inefficient since it leads to (my guess) a DMA setup and teardown for every 512 bytes of data.
This isn't the first time Google has left out Qualcomm performance features. Qualcomm's open-source bionic Krait optimizations have been in Qualcomm's CAF reference repos with an Apache license since 4.1 or 4.2 or so - Google still hadn't integrated all of them as of 4.4
Qualcomm also has a bunch of other optimizations that are closed-source so it's understandable that Google wouldn't use them, but the Krait bionic optimizations and lack of dm-req-crypt both appear to be Google ignoring opensource components that have a very high performance payoff.
tipoo - Thursday, November 20, 2014 - link
Wow, that performance loss on the 6 should definitely have been considered unacceptable for the Nexus 6. Storage speed is such a large part of the feel of smartphone performance. To be honest, I'd leave it off, there's not much of import on my phones anyways, theifs can have my music.So, is the Nexus 5 using FDE on Lollipop? Why does it do so much better, both than the 6 and itself on 4.4? Just a bug? Or is it using a different type of encryption, or none at all?
Brandon Chester - Thursday, November 20, 2014 - link
Only new devices will have it enabled, new as in shipping with Lollipop. The Nexus 5 gets an OTA to Lollipop so it won't just enable itself, but I can't speak for users who flash an image from Google. I have the Nexus 5 rolled back to KitKat for the time being for doing version comparisons in the Android Lollipop review.tfouto - Thursday, November 20, 2014 - link
Can you check this Thread? There are lot's of people complaining of battery draining, on Nexus 5 Lollilop.tfouto - Thursday, November 20, 2014 - link
Forgot to say which thread was:http://forum.xda-developers.com/google-nexus-5/hel...
tfouto - Thursday, November 20, 2014 - link
http://forum.xda-developers.com/google-nexus-5/hel...jeffreii - Thursday, November 20, 2014 - link
http://forum.xda-developers.com/nexus-6/developmen...Nexus 6 thread to disable encryption.
toyotabedzrock - Thursday, November 20, 2014 - link
Could you test the Nexus 5 performance with encryption enabled? And do you know if the a15 used in the Nexus 10 has any encryption acceleration?I find it to be very short sighted of Google to not have an encryption accelerator. It would help even just for browsing on Google's web properties.
tuxRoller - Thursday, November 20, 2014 - link
I'd imagine they are expecting the arm-v8a cryptographic extensions to handle the problem.That's one of the reasons why I thought/hoped that the n6 would be aarch64.
m-p-3 - Thursday, November 20, 2014 - link
I flashed my Nexus 4 with the factory image (including a system wipe) and the encryption wasn't forced.i4mt3hwin - Thursday, November 20, 2014 - link
I'm sure it won't have much of an impact, but would you guys be able to run the battery tests again with encryption off? Kinda curious to see if it effects battery performance at all. (I doubt it would because it shouldn't be writing anything to disk during this time).Mbonus - Thursday, November 20, 2014 - link
"Unfortunately, I haven't noticed any improvements to many of the areas where there are significant frame rate issues such as Messenger and Calendar. I speculated in the Nexus 6 review that the performance issues may simply be the result of insufficient GPU performance or memory bandwidth to drive the QHD display. "Do you notice the same frame rate issues on other QHD devices using Snapdradon 805?
nevertell - Thursday, November 20, 2014 - link
Could you do a battery life test on a non FDE device as well, please ? I was shocked that the nexus 6 did that much worse than the nexus 5, this implementation of encryption in software must attribute towards lower power efficiency.Brandon Chester - Thursday, November 20, 2014 - link
I don't think it's going to have much of an impact but I'll run it now.Brandon Chester - Thursday, November 20, 2014 - link
https://twitter.com/nexusCFX/status/53557853945072...nevertell - Friday, November 21, 2014 - link
Sorry for misguiding you and thank you for your time. I really appreciate that.So the battery life is suboptimal because of the display.
benjdm - Friday, November 21, 2014 - link
Thanks Brandonmacs - Thursday, November 20, 2014 - link
I just sent back my Nexus 9.Coming from an iPad air those lags are not acceptable. I can't stand a wallpaper that reloads when I tap the home button. Lollipop is far from a finished product.
sweenish - Thursday, November 20, 2014 - link
Easy enough to fix with a third-party launcher that offers the ability to stay in memory.But I have to wonder why you even bothered with Android if you want everything handed to you on a platter?
I get that as far as initial polish and presentation go, Android still lags though it's been making great strides. But to forego one of Android's chief advantages (changing things to get what you want) and just return a device?
It's like buying a sports car and taking it back because you can't do all your driving in second gear. Or buying a leatherman only for the screwdriver.
steven75 - Thursday, November 20, 2014 - link
Why do you give google get a free pass for releasing unfinished products? Very bizarre!A more valid car analogy would be buying a car with door locks that only activate half the time. Your solution is to replace the locks while 99.9% of the world would take the POS back for a refund.
Deelron - Thursday, November 20, 2014 - link
There's a difference between changing the things you want and fixing problems. Yay for customizing, boo for fixing.macs - Thursday, November 20, 2014 - link
I'm a tech enthusiast and I like both iOS and Android. There are pros and cons on both. This is not the point. But the Nexus 9 to me RIGHT NOW is a beta product. I didn't personally tried other devices with lollipop but what I heard is that the problems are the same (lags, unprectidable performances,...)tralalalalalala40 - Friday, November 21, 2014 - link
I feel for all the android fanbois that buy an N9 because it's an android tablet. They are getting screwed for their money considering the value of an iPad air 2.andrewaggb - Monday, November 24, 2014 - link
Companies screw up, but it's definitely not a free pass. You have a small window of time to make things right.Sounds like this is a mistake. Going up against the ipad air 2 you needed your complete A game.
tuxRoller - Thursday, November 20, 2014 - link
Yup pretty awful.My 2013 n7 is jankier now than with 4.4.
ART, as currently implemented, has been a bust. They really oversold android l.
psyside1 - Thursday, November 20, 2014 - link
So how come GPU with 50% more horsepower, and 30GB/s based S805, its still not enough? i think we are seeing lack of software optimizations, not QHD/big resolutions lags.Krysto - Thursday, November 20, 2014 - link
Because QHD represents a 78 percent increase in pixels of 1080p?Even if chip companies say they "support QHD" or "4k" they may do it JUST BARELY, which means you really should wait at least until the 3rd generation of a GPU "supporting QHD" before you start using QHD. Ideally you should use a GPU that is at least 4x more powerful than the one that "just barely" supports a certain resolution, to minimize stress/power consumption.
psyside1 - Thursday, November 20, 2014 - link
I bet my money that GPU is not the problem, you will see later on with updated the lag will be non existent.sonicmerlin - Friday, November 21, 2014 - link
Since Android doesn't prioritize the UI thread that's not possiblelilmoe - Thursday, November 20, 2014 - link
+999I've been particularly loud about this subject for the past year. Mobile GPUs are at least 2 generations behind compared to current mobile screen resolutions IMHO. The resolution spec race *above a certain point* is mobile experience's worst enemy. I believe Snapdragon 801 (and similar) GPUs are PERFECT for 720p. On the other hand, Snapdragon 805 (and current Mali T760MP6) is great for 1080p max.
Mind you, current ~5" 1080p panels are far from perfect, and consumers will appreciate more improvement to these panels instead of higher resolutions, especially since we've reached a point of diminishing returns on anything above 440ppi. If someone can tell the sub-pixels apart on a 5" 1080p panel it'll most likely be due to pentile or similar sub-pixel arrangements.
I seriously hope OEMs like Samsung, Sony, and HTC stick with 5-5.2" 1080p panels for 2015 so we can actually FEEL the difference 20nm and ARMv8 chips will have to offer. We're BARELY noticing the performance and efficiency benefits of the newer silicon. Or at least (for God's sake) allow us to revert back to 720p in the power options if they opt for 1440p panels (since we'll have perfect scaling that way, and arguably better 720p panels at that :P . You know, since each pixel will have significantly more sub-pixels in a 1440p panel running at 720p).
I'll be picking up (and recommending) whoever sticks with 1080p in a decent flagship in 2015. They'll all have 64bit processors and faster AES anyway, so this article's issues won't be a problem for any of these flagships.
Endda - Thursday, November 20, 2014 - link
"I'll be picking up (and recommending) whoever sticks with 1080p in a decent flagship in 2015."I highly doubt any of the major Android OEMs(Sony, Motorola, HTC, Samsung or LG) will use a 1080p display in their actual flagship smartphone in 2015
phoenix_rizzen - Thursday, November 20, 2014 - link
Considering their Compact versions tend to be one screen resolution lower than the full-sized Xperia, if the Z4 is 1440p next year, then the Z4 Compact should be 1080p. :)tralalalalalala40 - Friday, November 21, 2014 - link
So finally admitting only Apple is doing it right :)lilmoe - Saturday, November 22, 2014 - link
"Admitting" isn't quite what it is. I've mentioned several times before that I like their "current" CPU/GPU to screen resolution configurations. But that doesn't mean Apple is doing that for the sake of what I mentioned above. Don't forget that the iPhone 4/4S had a relatively underpowered GPU/CPU pushing its resolution, and the same true about the first two retina iPads... It's only NOW that their SoCs are keeping up with the resolutions they have on their devices, and it's only recently that iOS can somewhat handle non-doubled-scaling to certain point (not perfectly though). Again, it's not that Apple are "doing it right", it's more like there isn't any way else they can do it, and I so to happen the "current" configuration.tralalalalalala40 - Saturday, November 22, 2014 - link
I would argue that they are doing it for that sake. Retina display was a statement: after this, you get hugely diminishing returns. Let's focus on the fastest UI possible and implement with compiled apps! (yay no ART!)phoenix_rizzen - Thursday, November 27, 2014 - link
This is something that's bugged me about Android phone OEMs: pushing the GPUs to their max, instead of using "too much GPU" for the resolution.A Snapdragon 800 or 801 (Adreno 330) with a 720p screen would fly. Instead, they're saddled with 1080p screens where they aren't always smooth.
A Snapdragon 805 (Adreno 420) with a 1080p screen would fly. Instead, they're saddled with 1440p screen where they aren't always smooth.
And so on.
Just because a GPU "supports" a resolution doesn't mean it should be run at that resolution. Even "supporting" a resolution at 60 fps isn't enough these days.
Krysto - Thursday, November 20, 2014 - link
The problem is NOT enabling encryption by default, but doing it on devices that don't have hardware acceleration for AES encryption - such as every single device with an ARMv8 chip. Those devices should have no problem with default encryption.Brandon Chester - Thursday, November 20, 2014 - link
Except there are almost no ARMv8 Android devices. The point is that enabling it by default is a problem when none of the devices running your OS have hardware support.lilmoe - Thursday, November 20, 2014 - link
Note 4 with Exynos 5433 (7410)??Brandon Chester - Thursday, November 20, 2014 - link
I said almost no devices. The only two I know of is the Exyno 5433 Note 4 which most people will not get, and the Nexus 9.Brandon Chester - Thursday, November 20, 2014 - link
Exynos*R3MF - Thursday, November 20, 2014 - link
whatever theoretical storage bandwith penalty there is from FDE is makes no practical impact on my N5 using FDE.rman18 - Thursday, November 20, 2014 - link
Excellent article and investigative work. This site continues to impress me, now its time for me to go shut off encryption on my Nexus 6.mmrezaie - Thursday, November 20, 2014 - link
Can you also check the effect on battery life?Brandon Chester - Thursday, November 20, 2014 - link
Test is running now. Will put up a tweet with results.Brandon Chester - Thursday, November 20, 2014 - link
https://twitter.com/nexusCFX/status/53557853945072...jwcalla - Thursday, November 20, 2014 - link
What the hell is going on over there at Google?BinaryTB - Thursday, November 20, 2014 - link
Can you add run the same tests for a Nexus 9? Since that uses ARMv8, it should support encryption in hardware and hopefully less of a hit in read/write speeds.Dribble - Thursday, November 20, 2014 - link
Lots of reports of original nexus 7 (2012) being rendered pretty unusable with lollypop. I have one (not updated yet) and have been holding off as performance is already terrible with kitkat due to it having very very bad flash memory. Perhaps this is the reason why lollipop is killing it?BinaryTB - Thursday, November 20, 2014 - link
Only Lollipop shipped devices have encryption enabled by default (currently Nexus 6 & Nexus 9). If you update an older device to Lollipop, you have to manually enable encryption in the Security settings.I just got the OTA update for my Nexus 10 yesterday to Lollipop, haven't noticed any slow downs, it seems to be performing exactly the same actually. It "supposedly" should be faster since it's now using the ART runtime, but it should only affect app startups and such.
lilmoe - Thursday, November 20, 2014 - link
Can you request a Nexus 9 with encryption turned off from Nvidia? I'm curious to see how that affects the K1 chip.lilmoe - Thursday, November 20, 2014 - link
Oh, one more request please. An article with a showdown/comparison of all 2014 flagships after being updated to Android 5.0 (5.1?) later this year since most of them will be updated early December. "Before and after" performance and battery life charts would be nice.nedjinski - Thursday, November 20, 2014 - link
I hope they get this sorted out soon - as I plan to get a Nexus 6 to replace my Nexus 5.My subjective experience with my year old Nexus 5 -
Since the OTA 5.0 Upgrade I have seen a HUGE speed increase with everything I can throw at it - it's almost like it's a completely different phone now.
I will not be a happy camper if the N6 is actually slower than my (old) N5.
As long as we have the option to turn it off while Google figures this out - as they prob will do sooner or later like most things that don't work right at launch time.
tralalalalalala40 - Friday, November 21, 2014 - link
#lollibatterygaterandomlinh - Thursday, November 20, 2014 - link
This isn't boding well for picking a Nexus 6... is there no way other than loading a different boot img as suggested by an XDA thread to disable FDE?elian123 - Thursday, November 20, 2014 - link
Perhaps this is a stupid question, but can I deduce from the fact that you needed a non-FDE image from Motorola to do this analysis that it is not possible to (just) turn FDE off? In other words, if you buy a new device that has FDE enabled, you're stuck with FDE?MikeMurphy - Thursday, November 20, 2014 - link
A PIN or password lock will keep the contents of your phone safe from 99.999% of thieves. I see no advantage to NAND encryption for consumers except for the most highly sensitive data. I'd rather Google focus more on connectivity encryption and generally protecting online privacy via Tor-like solutions.EyelessBlond - Friday, November 21, 2014 - link
This isn't about security; it's about complying with a California law requiring that phone owners have a "kill switch" for their phone: a way to delete all their data by remote if it gets lost or stolen. The best way to do that is encrypt the data, and if the kill code is sent, the phone securely deletes the encryption keys.sprockkets - Thursday, November 20, 2014 - link
"Google's move to enable FDE by default also may not be very helpful with real world security without a change in user behaviour, as much of the security comes from the use of a passcode. This poses a problem, because the users that don't use a passcode doesn't really benefit from FDE, but they're still subject to the penalties."You need to read up on how android's encryption work in version 5.0, as the system no longer relies on passcodes for default encryption but 128 to 256 generated keys. This is used REGARDLESS if the user sets a passcode or not, or uses a pattern lock.
Setting a password will be used to re encrypt the key, but is no longer necessary to use.
Passwords are generated and hashed using scrypt multiple times and for devices that support it, the encryption key is signed by a key stored in a protected memory area. Thus, offline attacks against the key are useless.
Come on guys, you are supposed to be at the top of your game.
psyside1 - Thursday, November 20, 2014 - link
All this talk about big resolution is wrong imho. There was devices with S4 pro, and 1200p (nexus 7 2013) which absolutely flies when you enable ART. I have a hard time to believe that gpu 2x faster cant push 1440p, same can be said for S600 - HTC M7 and other S600 based 1080p devices with stock or close to stock Android.JoshHo - Thursday, November 20, 2014 - link
While it's true that this protects against offline attacks, the issue is that it's trivial to turn the device on and pull user data over adb if a password isn't used as well.Brandon Chester - Thursday, November 20, 2014 - link
I'm aware. When I wrote that it's protected by the passcode but that things are encrypted regardless, it was meant to imply that you don't need the passcode for FDE to work. It doesn't change that users aren't really protected unless they put a passcode because someone who gets a hold of your device without a passcode can just access everything freely anyway.sprockkets - Friday, November 21, 2014 - link
OK I see your point, thanks.Laststop311 - Thursday, November 20, 2014 - link
With that kind of performance hit unless you are a terrorist guarding your attack plans the encryption just isn't worth it. The FDE is a good idea though and their first try was a valiant effort. I'm sure with the nexus 7 the SOC designers will have some fixed function in the SOC to fix this problem. I'm happy with my galaxy note 2 still. It's only 2 years old and still does everything I need it to do quickly. I was going to get a note 4 for the 700mhz block a support for t-mobile but now that performance has started to hit a plateau I expect my next phone to last a good 5-6 years and for it to last that long I'm going to wait for 64 bit as I have the feeling later versions of android are going to require 64 bit to run. So if i want to use cyanogenmod to keep my phone up to date for 6 years 64 bit is going to be crucial. I'm sure next fall the note 5 will most likely use the snapdragon 810 for some 64 bit action.If only apple would sell the A8 chip for the galaxy note boy o boy would that be sweet. As much as I hate the iphone apples A8 soc is miles ahead of every other phone soc. The more powerful dual cores is such a better design than less powerful 4 cores as single threaded performance is really what determines the speed of almost every single app. Multi tasking is rarely needed on a phone so having your power budget. spread over 2 cores instead of 4 is just much better in every way. Also the powervr graphics are the best SoC graphics design as well. power vr 6 series consistently slaughters adreno and mali and nvidia can't get their single kepler core design into a phone which is the only hope of dethroning power vr 6 series and their 7 series is around the corner.
What I would love to see happen is nvidia really step their game up and make their next gen erista chip fit in a phones tdp with some rly nice 2nd gen dual core denver cpu's and a maxwell smm for the graphics as this is really the only hope for android to catch up to apples superior soc design. Since maxwell is so much more power efficient than kepler and with efficiencies they can gain in 2nd generation of denver dual core cpu. Nvidia may finally crack the code and remove qualcomm from having the fastest android phone soc. A galaxy note 5 with 2nd gen dual core denver cpu's and maxwell gpu would really be an amazing phone that could finally keep up with apples performance.
tipoo - Thursday, November 20, 2014 - link
Yep. Denver is handicapped by being a process node behind Apple right now, I'd love to see what they can do on the next node.name99 - Friday, November 21, 2014 - link
You mean the node that will be competing against the A9X manufactured on 16nm FF+?Hmm, I think I can predict how that will go down...
Arbie - Thursday, November 20, 2014 - link
You shouldn't publish a front-page table of results that are totally bogus. That's non-standard practice and many people will overlook the text below which explains that these could not be real.Brandon Chester - Thursday, November 20, 2014 - link
The first paragraph explains that the table that follows demonstrates how Androbench provides inaccurate results under Lollipop. The table follows the explanation.tfouto - Friday, November 21, 2014 - link
there should/could be some comparative benchmarks like boot time, and loading heavy apps/games, to have a real indication, instead of raw benchmarks.NimbusTLD - Thursday, November 20, 2014 - link
Could we see results for Nexus 5 Lollipop with FDE to complete this picture?kage117 - Thursday, November 20, 2014 - link
can you turn off fde manually?dbqqq - Friday, November 21, 2014 - link
Why did you need a factory image with FDE disabled by default? Shouldn't be enough to disable encryption from the settings?Brandon Chester - Friday, November 21, 2014 - link
You can't disable it from Settings.Valantar - Friday, November 21, 2014 - link
Maybe Google are doing this to force OEMs to use better flash? It seems obvious that android devices skimp on this when compared to the flash performance seen on Apple's devices. If that was the point, though, they should perhaps have set a better example with the N6?tralalalalalala40 - Friday, November 21, 2014 - link
Not sure what the point of encryption on the phone is for android devices. All info gets sent through Google servers (they are just an advertising company) which law enforcement has access to already...fanterrific - Friday, November 21, 2014 - link
now can you do the battery and camera snapshot latency tests with FDE off?tralalalalalala40 - Saturday, November 22, 2014 - link
This is a disaster for google. In order for their iphone killer to eek even barely close to the iphone in performance you have to remove security features. ouch. they should just disable it across the board to make the fbi happy and to make it easier for thieves to root the phone and resell it. let android deal with device theft.konradsa - Sunday, November 23, 2014 - link
Great article. Can you guys do the same test on ios 8 with an iPhone and iPad? Wondering if Apple suffers from same degradation. Should be easy enough, since seeing our clearing the passcode enables our disables encryption on ios 8.Brandon Chester - Sunday, November 23, 2014 - link
No they don't, you can see that in the NAND performance from the iPhone 6 review. Every iOS device has an AES 256 crypto engine built into the direct memory access path between the system memory and flash.konradsa - Monday, November 24, 2014 - link
Thanks for the explanation, I have done some more research, and the statement above seems to be true, at least for every phone since iphone 5s, and every tablet since the Air 1. While Apple is not perfect, this demonstrates why the ios platform remains the superior mobile platform.Shark321 - Sunday, November 23, 2014 - link
This is not Nexus 9 or Android 5.0 specific. On my Nexus 5 with Android 4.4.4 Wallpaper reloads often, even with >1GB of free RAM. This is just crappy Java garbage collection.Shark321 - Sunday, November 23, 2014 - link
Using Action Launcher which has the "stay in memory" option on 4.4.4 Nexus 5, the wallpaper (non animated) is reloading every 2-3 hours, causing 1-2 sec lag.Kumouri - Monday, November 24, 2014 - link
Hopefully Google won't back down from having this enabled and sites like AnandTech and others can continue to remind people that the state of storage in mobile (phones and tablets) is truly abysmal.Maybe Google got fed up with trying to get manufacturer's to use decent storage and decided to force FDE to force their hands. I can hope, at least...
But then they didn't make Motorola use a decent storage solution for the N6, so probably not.
koltregaskes - Thursday, December 18, 2014 - link
Has this test been re-run on Android 5.01?cb474 - Monday, December 22, 2014 - link
I don't get why this causes such a huge performance hit. I've been using FDE (in Linux) on spinning disks and SSDs for years with parely any noticeable preformance issues. And this is entirely software driven encryption (meaning the CPU has to do the work of encrypting/decrypting). It's not built into the hard drives. Lots of tests have shown on desktops, this kind of FDE causes barely a blip in read/write performance.