Software UI

In terms of software the 6P is able to sport the latest Android 6.0 Marshmallow, courtesy of course of being a Nexus device. There’s not terribly much to say about the OS that hasn’t been said already by Brandon’s analysis in the review of the Nexus 5X. This is due to the fact that all Nexus devices come equipped with the same software experience, but also due to the fact that Android 6.0 offers very little front-facing changes.


I’ll openly admit that I’m not too much of a fan of the stock Android experience: Over the years Google’s stock Android has always been praised as the “pure” experience and how Android should be. I find this a bit unfortunate as I find there’s a lot of usability flaws in the stock. It’s the simple things that most other OEM skins add that I find the most lacking in stock Android, examples being the lack of an auto-brightness toggle in the quick settings or even having a brightness slider directly available in the notification shade itself which reduces the motions to get to the settings.

My biggest gripe however are the navigation buttons and Google’s lack of an option to reorder them. While I understand the design decision and logic behind having a back button on the left, it makes no sense in terms of usability for the majority of people that are right-handed. The back button is by far Android’s most used navigation button, so I found the Nexus 6P’s larger size to exacerbate the issue as I need to always change grip or stretch my thumb to able to reach it properly. Still having this huge ergonomics issue after this many years is basically inexcusable – the notion that it’s more intuitive to have it on the left is a poor rationale as “unintuitive” use-methods can be learned and taught, but my thumb stopped growing a long time ago and I imagine so did everybody else’s. Virtually all OEMs recognize this issue and either come by default with reversed navigation buttons or by at least offering the option to rearrange them. Here’s hoping that Google listens and adds this as a stock option for future Android releases, similarly how they did for many other past features that were pioneered by third-party vendors.

Ambient display is a great feature that takes advantage of the 6P's AMOLED screen. Every time you pick up the device it will show you a minimalistic greyed out view of your current notifications without having to press any buttons. The detection is a bit finicky and sometimes goes off too easily as I often saw ambient display trigger itself while the device was just laying steadily on my table, and also sometimes when you do want it to go off when you pick up the device it might decide not to. However when it does work it works well, and it also enables you to directly unlock the phone from there. I do wish the display period had been configurable as sometimes where you have a lot of notifications the screen will go back off before you can read all of them.

Other than some of the aforementioned annoyances, the stock Android experience is a good one. In terms of performance, there were some concerns that I’ll reiterate in the PCMark writing sub-test but otherwise the device is fluid as you’d expect it to be. I may be biased when saying this but I just don’t think stock Android is an “exciting” experience or a platform where we see lots of innovation. I’m aware that there are groups who vehemently adhere to Google’s design decisions, but for me personally it just doesn’t do it as it comes with too many daily usability regressions.

NAND Performance

In terms of NAND storage, the Nexus 6P uses a Samsung eMMC module. In fact, this is the same “BGND3R” variant as found in this year’s HTC One M9. For testing I also ran the NAND benchmarks on an unencrypted data partition to be able to analyze Android’s full disk encryption overhead that is now obligatory for all new devices shipping with 6.0 Marshmallow.

Internal NAND - Sequential Read Internal NAND - Sequential Write

As we can see the unencrypted numbers perform as expected and within range of the HTC One M9’s performance. The encrypted numbers which come as default with the device are the more concerning ones as we see a decrease in read performance of up to 84% and write performance decreases by 43%.

The Nexus 6P uses software decryption, accelerated by ARMv8 cryptography instructions. Google claims that this method is actually faster than using Qualcomm’s Snapdragon built-in SoC dedicated hardware crypto unit, which points out to a possible severe lack of performance and readiness on the part Qualcomm's SoC. We were curious to determine if this was solely an issue for Qualcomm and re-did some encrypted and unencrypted runs on the Note 5 and found that the overhead of encryption on that platform is very minimal, pointing out to that the degradation seems to be limited to Qualcomm's SoCs. It would be interesting to see if the Snapdragon 820 will be able to offer improvements in this regard.

In the end, the Nexus 6P’s out-of-the-box performance on the encrypted data partition seems very lackluster and it may affect application speed. One has to remember that it’s only the data partition that is encrypted, as we see no degradation on the internal or system partitions as they remain unencrypted.

WiFi Performance

The Nexus 6P comes naturally with 802.11ac WiFi in 2x2 MIMO configuration, all powered by Broadcomm's BCM4358 WiFi SoC. This is the same chipset found in other devices such as the Galaxy S6, so hopefully performance will be similar.

WiFi Performance - UDP

And indeed we see excellent WiFi performance from the 6P as we reach up to an average of 467Mbps, up there among one of the fastest WiFi implementations in today's smartphones.

Introduction & Design System & CPU Performance
Comments Locked


View All Comments

  • tuxRoller - Monday, December 21, 2015 - link

    Do you have a reference for saying that they don't make use of idle loops and dvfs?
    If that's the case, and I don't think it is, then what apple has done is even more amazing: the highest performing soc available is capable of being run FLATOUT for half a day on their tiny batteries. If they made use of even minimal power saving a9 devices would last for DAYS.
  • tipoo - Tuesday, December 22, 2015 - link

    I think they probably meant the GFXbench battery run test and final run FPS test, every other SoC throttles down by the last one, where A9 keeps a high speed but kills the battery sooner.

    I think that speaks more to the throttling issues of other SoCs, even if it accidentally raises gaming battery life.
  • tipoo - Tuesday, December 22, 2015 - link

    "anyone who knows hardware knows single threaded architectures will score higher"

    So explain, please. And neither iOS nor A9 are single threaded, all SoCs since the A5 with the exception of the A8X are dual cores, A8X being tri-core. iOS scales to threads just fine as shown with the third core being used just fine in the A8X. Apple just chose higher per-core performance, since it's more usable than the same performance spread across 8 cores.
  • NEDM64 - Monday, December 28, 2015 - link

    "Android was built to be a true multi-tasking OS...Apple was not..."

    Fanboy tears?

    "Apple" OS's, based on their open-source project, Darwin, are microkernel-based, non-peremptitive multitasking operating systems.

    Just like OS X, iOS is a truly multitasking OS.

    And if you want to cry even more, then explain why the Pixel C doesn't offer side-by-side multitasking and iPads with iOS 9 do?
  • usman_raza - Wednesday, December 16, 2015 - link

    2nd Comment :)
  • Anustart - Wednesday, December 16, 2015 - link

  • AL KASR - Wednesday, December 16, 2015 - link

    thanks, but what about random read and random write for the nand, which is the most important!
  • Andrei Frumusanu - Wednesday, December 16, 2015 - link

    I had to leave them out due to an issue with the 3.6 version of the benchmark not being able to complete those sub tests, we'll be investigating the matter and in the future we'll also migrate to AndroBench 4.0.

    Here's the 4.0 scores for the device:

    Encrypted: 75.7MB/s seq read, 40.6MB/s seq write, 7.4MB/s rand read, 1.0MB/s rand write.
    Unencrypted: 179.7MB/s seq read, 52MB/s seq write, 14.73MB/s rand read, 6.3MB/s rand write.
  • Olaf van der Spek - Wednesday, December 16, 2015 - link

    Why do the random scores take such a hit from encryption? The SoC should be fast enough to encrypt 6.3MB/s so I can't think of a reason for rand write to drop to 1.0MB/s..
  • Andrei Frumusanu - Wednesday, December 16, 2015 - link

    The random test uses 4KB segments and it's likely that due to that there's a lot of system overhead when making such short I/O operations.

Log in

Don't have an account? Sign up now