For a few years now, Google has had a generally consistent tablet strategy. Instead of chasing after the ~10 inch tablet segment and focusing upon the high end, we’ve seen tablets closer to the ~7 inch display size at extremely low cost. While this has been an immensely successful strategy in driving hardware adoption, the formfactor made it possible for the tablet to be closer to a large phone than a small tablet. The flexibility of Android’s scaling system meant that an app designed for a phone worked acceptably well for a small tablet, even if the space efficiency was a bit poor. There’s no question that the Nexus 7 (2013) was and still is a great tablet, but even now it’s obvious that there’s a dearth of applications designed specifically for the larger display. The other issue is that of cost. With the Nexus 7 line, Google managed to integrate an incredible amount of hardware into a tablet priced well below the ~500 USD price point that the original iPad established. This is great for the consumer and no doubt great for Google, but the Nexus 7 line was good enough that there wasn’t much in the way of competition.

This brings us to the Nexus 9, Google’s attempt at changing the Android tablet space. From the start, this device seems to be intent on pushing the Android tablet to a more premium segment. Rather than a purely cost-optimized polymer design, we see the addition of an aluminum ring that runs around the side of the device, which definitely helps with in-hand feel. The tablet itself seems to have high-end aspirations as the launch platform for NVIDIA’s Tegra K1-64, which has two Denver CPU cores rather than the traditional 4+1 Cortex A15 setup, along with dual front-facing speakers and a large 9” display with 4:3 aspect ratio. I’ve included the basic specs in a spec sheet below, to avoid spending too much time going over the basics.

  Nexus 9
SoC 2.3GHz 64-bit dual core Tegra K1 Denver SoC
Display 8.9" 2048x1536 IPS LCD
Network WiFi only or 2G / 3G / 4G LTE SKU
Dimensions 153.68 x 228.25 x 7.95mm, 425g WiFi, 436g LTE
Camera 8MP Rear Facing (IMX219) with F/2.4 aperture, 1.6MP FFC (OV9760)
Battery 6700 mAh (25.46 Whr)
OS Android 5.0 Lollipop
Connectivity 802.11a/b/g/n/ac + BT 4.1, USB2.0, GPS/GNSS, NFC

Unfortunately, in the case of the Nexus 9 while we can make some early observations the version of firmware that we received dates was built on August 29th, and in the time since it’s quite likely that there have been significant changes in all directions. We still don't have a newer build, so all the tests will be done on older firmware. The full review will have final numbers as it will be done using shipping firmware.

At any rate, the hardware of the Nexus 9 definitely fits the bill of a premium tablet. While for the most part every Nexus device in the past year has shared the same industrial and material design elements, HTC seems to have added a few extra touches to differentiate this product from other Nexus devices. The most obvious and prominent of these touches is the metal ring, which has a brushed texture similar to what we saw on the M8.

There are also dual front-facing speakers that flank the display, which are definitely great for video and music content when compared to a single speaker on the bottom or back of the device. However, for the most part the design is very much a Nexus device with its minimalistic design and soft-touch plastic back cover.

CPU Performance and Battery Life
Comments Locked


View All Comments

  • jhenzie - Tuesday, November 11, 2014 - link

    Final compilation has always been on device and ART can consume Dex
  • frostyfiredude - Monday, November 3, 2014 - link

    ART bytecode most certainly IS optimized for 64-bit assuming they didn't throw in native methods or odd languages. "Apps built in Java will automatically gain these benefits, with no changes to existing code. Apps built on other languages, built with the Android NDK r10b [0], can compile for 64-bit architectures to access the features listed above."
  • buttdill - Tuesday, November 4, 2014 - link

    ART compiles java bytecode to the appropriate native bytecode: it should generate AArch64 instructions if the hardware supports it. The java bytecode is platform-independent so it doesn't care about AArch64, so purely Java apps don't need to do anything special to be 64-bit, just be run by a 64-bit interpreter.

    And while there is no Dalvik, there is still native code: these are the apps which don't "run purely on ART bytecode". This native code has to be recompiled by the developers to include AArch64 insruction set.
  • Zarsus - Wednesday, November 5, 2014 - link

    ART will compile any non-native Android app to 64-bit when viable just as Java VM will compile any java code to 64-bit when viable.

    What makes you think ART doesn't do that when it makes sense anyway?
  • Samus - Monday, November 3, 2014 - link

    Well yeah, but how many Apple apps are 64-bit? How many Windows apps?

    Apple is going to have the short-term advantage in just a few months, though, as they are requiring their devs to publish 64-bit versions of apps when they update them after February...

    I think the timeframe Apple is giving is a little aggressive, but commendable. Google should consider doing the same thing, but because of the way Play Store works (no screening) I doubt they will.
  • darwinosx - Monday, November 3, 2014 - link

    Apple has been 64 bit for a year and ART is still a runtime. Many iOS apps are 64 bit and they are complied for the shot part.
  • kron123456789 - Monday, November 3, 2014 - link

    "Well yeah, but how many Apple apps are 64-bit?" — I think almost all of them. All the benchmarks, at least.
  • noelbonner - Tuesday, November 11, 2014 - link

    There are a number of tablets that are higher ranked in CONSUMER BASED rankings (like for example).
  • craighamilton - Saturday, December 6, 2014 - link

    Not a big fan of Nexus 9... there are plenty of tablets that have higher user satisfaction
    (see for example...)
  • chizow - Monday, November 3, 2014 - link

    How so? That's exactly the point, Apple had the opportunity to go with a significantly bigger battery with their larger screen size but didn't, in fact the battery on the Air 2 is smaller than the Air 1. We also know for a fact it is harder to get bigger batteries into devices the smaller they get, and large tablets can scale battery much higher due to size/surface area.

Log in

Don't have an account? Sign up now