Final Words

The Nexus 9 is undoubtedly an aspirational device. For a long time now, Google and the Android tablet market in general have been in a position similar to Amazon’s Fire tablet. This has meant that the margin on the hardware itself has been quite low, and while quality was possible to achieve there were often sacrifices made in order to reach the targeted price point. This was seen in the form of lower CPU and GPU bins in the SoC, lower quality NAND, and generally poorer displays.

The Nexus 7 (2013) did manage to mostly avoid these issues, but Google had set the bar for price and performance to the point where OEMs would have issues with maintaining acceptable profit margins on a device. The Nexus 9 changes this strategy by reaching for a higher price point and attempting to deliver a no-compromise tablet in return. To figure out whether Google has succeeded, it’s worth going over each aspect of the device before coming to any sort of judgment.

The first and quite possibly most important aspect of the Nexus 9 is the SoC. To this end, the Nexus 9 is the very first Android device with AArch64 support enabled in Android. NVIDIA’s Tegra K1 with Denver is effectively the state of the art when it comes to SoCs in the Android OEM space, and no other device has launched with this SoC. While the fact that the SoC is built around the ARMv8 ISA is important, the architecture of the CPU itself is easily one of the most interesting designs we’ve seen in years. Unfortunately, while the design of the CPU is academically interesting it doesn’t seem that this produces real-world benefits. The Nexus 9 has one of the fastest SoCs we’ve seen to date, but this comes at the cost of worse power efficiency than the Cortex A15 version of the Tegra K1.

Another piece of the puzzle is the design, which is one of the key differentiators for a high-end mobile device. While one can debate the merits of various materials, it seems to be clear that an all-metal unibody chassis would’ve greatly improved the design of the Nexus 9 and justified its positioning better. While there is some level of give in the back cover, the buttons are quite thin and hard to find, and there’s a noticeable seam where the back cover and metal frame meet, the design isn’t actually all that bad in practice. Unfortunately, this seems to be a bit of a sore point as well for the Nexus 9 when compared against the iPad lineup.

While the SoC and design are often points of distinction for a premium tablet, the display is critical for any tablet. In this regard, the Nexus 9 does surprisingly well. With a 4:3 aspect ratio, high resolution, and high quality color calibration HTC and Google have outfitted the Nexus 9 with a great display. Unfortunately, there’s a great deal of variability present in these displays that presents itself in the form of backlight bleed along the edges of the display. While my unit only has a slight amount of bleed along the top edge of the device, other units can have more or less backlight bleed depending upon variance in production.

The one aspect that seems to be the product of a poor design choice is the high reflectivity of the display. Although I’m reasonably sure that the display is laminated due to the lack of an obvious gap between the display and glass, it seems that the optical material between the display and glass is poorly designed as I can see a distracting double reflection in the display. The Nexus 9 also compares unfavorably to the iPad Air 2 in this case as the anti-reflective coating on the iPad Air 2 is far superior to just about anything I’ve seen on the market.

Although I previously noted that the power efficiency of the SoC isn’t up to scratch, overall battery life is quite good on the Nexus 9. With a combination of a large battery and efficient display, Google and HTC have managed to compensate for the power consumption issues that come with Denver’s performance. Unfortunately, it seems that Kepler’s desktop-first design results in worse power efficiency than what we see on competing solutions such as the “GXA6850” found in competing SoCs. Even if this is compensated for by the ability to enable desktop-class gaming, the Nexus 9 doesn’t appear to support full OpenGL to begin with, unlike the SHIELD Tablet. This means that the extra capabilities enabled by the GPU are effectively wasted, which hurts the value proposition for the device overall. In light of the launch of the Tegra X1, I can't help but wonder how different the experience of the Nexus 9 would be with NVIDIA's latest SoC.

Outside of these primary elements of the tablet, there seems to be a reasonable level of attention to detail. The camera is acceptable, even if the focus and capture latency aren’t the greatest. The audio quality from the speakers is also quite good, and really helps to enable a great experience when watching any kind of video or listening to music without earbuds/headphones. The software experience is acceptable, although Google continues to fight issues with ecosystem support for tablets.

With all of this in mind, it’s hard to give a resounding recommendation of the Nexus 9. The Nexus 9 is a step towards a high-end Android tablet, but not the leap that Google was hoping for. If you want an Android tablet near the size of the Nexus 9, I can’t really recommend anything else. The Galaxy Tab S falls short on account of performance and battery life, and despite the somewhat unremarkable design of the Nexus 9 I believe that it is nicer than the Galaxy Tab S. However, if one were to assume that OEMs are currently readying devices to truly carry the torch of the high-end tablet, the Nexus 9 is a hard sell. I suspect that this wouldn’t be nearly as difficult if the Nexus 9 had a lower price point of $300 and $350 USD for the 16GB and 32 GB WiFi variants, and $450-$500 for the 32GB LTE variant. Google has managed to get close to the mark with the Nexus 9, but like the Nexus 6 it seems that it’s up to the OEMs to cover the remaining distance.

WiFi Performance, GNSS, Misc
Comments Locked

169 Comments

View All Comments

  • PC Perv - Wednesday, February 4, 2015 - link

    It is clear, even though you did not say, why no one other than NV and Google will use Denver in their products. Thank you for the coherent review, Ryan.

    P.S. I can't wait for the day SunSpider, Basemark, and WebXPRT disappear from your benchmark suit.
  • jjj - Wednesday, February 4, 2015 - link

    You always make those kind of claims about dual core vs more cores but you have never attempted to back them up with real world perf and power testing.
    In real use there are alerts and chats and maybe music playing and so on. While your hypothesis could be valid or partially valid you absolutely need to first verify it before heavily insisting on it and accepting it as true. Subjective conclusions are just not your style is it, you test things to get to objective results.
    And it wold be easy you already have "clean"numbers and you would just need to run the same benchmarks for perf and power with some simulated background activity to be able to compare the differences in gains/loses.
  • PC Perv - Wednesday, February 4, 2015 - link

    Where would you put the performance of "backup" ARM-only part of Denver? Cortex-A7? Is it measurable at all?

    Also, why don't Samsung use F2FS for their devices? I thought it was developed by them.
  • abufrejoval - Wednesday, February 4, 2015 - link

    While the principal designer seems to be a Korean, I'm not sure he works for Samsung, who typically used Yet Another Flash File System (YAFFS).
  • Ryan Smith - Wednesday, February 4, 2015 - link

    It's not measurable in a traditional sense, as the DCO will kick in at some point. However I'd say it's somewhere along the lines of A53, though overall a bit better.
  • Shadowmaster625 - Wednesday, February 4, 2015 - link

    The design philosophy of the DCO does make a lot of sense. When your mobile device starts to bog down and you start cursing at it, what is it usually doing? It is usually looping or iterating through something. The DCO wont help with small blocks of code that execute in 500uS, but you dont need help with that sort of code anyway. What you want to improve is exactly the type of code the DCO can improve: the kind of code that takes several dozen milliseconds (or more) to execute. That is when you begin to notice the lag in your cpu.
  • mpokwsths - Wednesday, February 4, 2015 - link

    Joshua & Ryan,

    please update the charts with the bench results of the newer version of Androbench 4: https://play.google.com/store/apps/details?id=com....
    (I had previously commented on the fact that you can't safely compare the i/o results of different OS AND different bench apps).

    Androbench 4 is redesigned it to use multiple i/o threads (as a proper i/o bench app should have) and produces vastly improved results on both Lollipop and earlier Android devices.

    You will not be able to compare the newer results with older ones, but at least it will put an end to this ridiculus ι/ο performance difference between iOS and Android, the one you persistently -but falsly- keep projecting.
  • Andrei Frumusanu - Wednesday, February 4, 2015 - link

    I tested this out on several of my devices and could see only minor improvements, all within 10%. The performance difference to iOS devices does not seem to be a dupe at all.
  • mpokwsths - Wednesday, February 4, 2015 - link

    My results strongly disagree with you:
    Nexus 5: Seq Write: 19MB/s --> 55 MB/s
    Rand Write: 0.9 --> 2.9 MB/s

    Sony Z3 Tablet: Seq Write: 21 MB/s --> 53 MB/s
    Rand Write: 1,6 MB/s --> 8MB/s
    Seq Read: 135 MB/s --> 200MB/s

    I can upload pics showing my findings.
  • mpokwsths - Wednesday, February 4, 2015 - link

    Meet the fastest Nexus 5 in the world:https://www.dropbox.com/s/zkhn073xy8l28ry/Screensh...

    ;)

Log in

Don't have an account? Sign up now