Google Nexus 5 Review

The K release of Android has been in the works for a while, and introduces platform changes that help slim the platform down even more, speed up system performance, and also introduce some new APIs and features.

There’s a bit of a discontinuity here since there’s been a lot of discussion about the new Google Experience Launcher that came with the Nexus 5, although the reality is that this isn’t canonically a part of KitKat so much as it is the exclusive (as of this writing) launcher for the Nexus 5. I won’t walk through every pixel of change since I think others have that covered, and chances are they’re already very familiar to most readers given Google’s quick rollout to Google Play editions of the HTC One and SGS4, Nexus 7, Nexus 7 (2013), Nexus 4, Nexus 10, and of course almost all the Moto Xes by now.

From a UI perspective, KitKat makes a number of immediately obvious visual changes. The top status bar and bottom navigation bar are now translucent with a subtle gradient. I like this change as it manages to make the still rather static use of pixels for the navigation bar at least useful for looking at your wallpaper.

Another obvious immediate change is that a lot of holo’s blue is now white. Truth be told it seems like Windows and Android (starting really with Honeycomb) loved blue perhaps a little too much. It used to be that Android overused green as the highlight color, something which hilariously enough still shines through in some other OEM skins. In KitKat, put simply, white is the new blue, and orange is the new white. The status icons are now white as well and simplified to not show data transmission arrows.

It took some time to get used to data transmission arrows not hinting to me when I was connected to the network and could expect that bits were flowing, thankfully they do still exist in the settings shade, and it’s here you’ll also see status indicators change color (remember, orange is the new white) if there’s no connection to Google. Oh and the old abacus-like settings icon is changed to a cog, although the abacus settings icon still exists in a ton of Google’s first party apps.

The stock apps get tweaks too, clock changes its picker, the lock screen loses the two different font weights and instead uses just one. Lock screen now also has full-screen album or movie art that corresponds to what you’re listening to or projecting using Chromecast.

There’s a new full screen “immersive mode” that hides all system UI and reduces distractions that developers can use. An edge swipe gets you back to a view with the system UI visible.

The phone app gets a big functional change by including more Google+ and Maps integration. The new UI hides the dialer by default, instead encouraging users to dial using their contacts by typing into a search bar that searches through contacts and nearby places. The result is you can dial businesses just by typing their names – I was searching for a camera store while in San Francisco and just typed the name of the store and hit dial at one point. Incoming caller ID also now looks up incoming callers against Google Maps listings, and at some point in the future, against people that have associated their numbers with Google profiles. On one hand it’ll be nice to have contact photos and caller ID populate automatically without having to curate an address book, on the other there are obviously privacy concerns to address. Smart dialing was a new feature in 4.3, that is now shipped turned on by default in 4.4 if you pull up the dialer.

An improvement I’m sure a ton of people will enjoy is the inclusion of color emoji in KitKat. Android’s prior emoji support left a lot to be desired and felt like it was stuck back in 2010. The new emoji and support straight from the Google keyboard will undoubtedly please a lot of people.

KitKat also adds printing support, either over local WiFi or cloud based. There’s new APIs for printer manufacturers to use and build print services that can be distributed over Google Play. I haven’t printed things in forever, so the most relevant part of printing support from my perspective is how this can also just be used to generate PDFs.

A new storage access framework comes with a revamped picker. The new picker is a dramatic improvement that integrates cloud and local storage services in one view, should the provider integrate with the APIs needed. Google does a good job with its own Google Drive service, I hope at some point Dropbox integrates the same way.

The Google experience launcher (actually Google Search) is the big Nexus 5 exclusive (for now), and includes a number of changes over the stock launcher. Chief among those is the ability to trigger Google Now by saying “OK Google” from the home screen or inside the interface – the device does need to be in the screen-on state as well. It doesn’t activate the phone the same way the Moto X does, which is always listening for “OK Google Now” using a C55x DSP even when the screen is off. I find it a bit curious that Nexus 5 doesn’t use keyword activation using Snapdragon 800 and WCD9320’s voice activation feature, and it’s a bit puzzling that there’s already search-activation phrase fragmentation between the two devices, although Moto X probably added another word to decrease false positive activations from power off.

The Google experience launcher changes the widget panel navigation around, going left gets you to the Google Now and search, additional widget panels are added to the right, and you’re no longer limited to just five. The launcher’s apps view changes as well, there’s no apps and widgets tab, just a grid of apps, and it’s translucent like the rest of the UI. Widgets move to a menu you can get to by long pressing on a blank part of a home screen.

KitKat adds formal support for third party SMS clients with a shared SMS provider and official APIs, and Nexus 5 dives head in with Hangouts as the default SMS client on the device. Unfortunately the merging of SMS and Google Talk Google+ Hangouts instant message threads is half-baked at best. The two exist in the same application, but the implementation is still basically a discrete one, with two different conversation views for SMS and Hangouts. It’s also frustrating to switch between SMS and Hangouts conversations quickly sometimes since you have to do this from the conversations view not the threads view. Notifications also are surfaced separately for Hangouts and SMSes.

Google can claim that SMS and IM are now merged nicely together under one roof, but it’s still basically two discrete threads and views. It’s amazing to me that it’s 2013 and nobody has still been able to merge the two together the same way WebOS did with the Palm Pre.

KitKat also brings DSP accelerated audio decode, or “audio tunneling to DSP.” This was another thing that silicon vendors would add in for OEMs, allowing them to have very low power playback of MP3s and other codecs that could be processed in the appropriate IP block on their SoC. Qualcomm’s MSM8974 has two Hexagon DSPs inside, one QDSP6 V5A for applications to use, one QDSP6 V5H which runs the baseband. The V5A DSP now can offload playback of most common audio formats natively, which Nexus 5 uses.

We’ve been expecting it for a long time now, and with 4.4 the WebKit based rendering backend for WebView is out in favor of a Chromium open source one. This brings better HTML5 support and (thankfully) the ability to remotely debug WebViews over USB using Chrome.

Closed captioning support for videos is also added, and gets a setting option under Accessibility. Apps using VideoView can deliver caption streams for rending now, and VideoView can auto display captions in WebVTT format.

A cool new feature is the new screen recording tool which is a part of Android 4.4. Using “screenrecord” on a device tethered over adb, you can easily make videos of exactly what’s on screen for walkthroughs or tutorials, or of course, reviews. The best part is that it uses the encoder onboard the device and seems to have essentially negligible performance impact on the device while you’re using it. I’ve settled on a bitrate of 10 Mbps as this seems to produce results free of encode artifacts. Recordings do seem to be limited to 3 minutes.

./adb shell screenrecord –verbose –bit-rate 10000000 /sdcard/recording.mp4

I used the screenrecord utility to record a simple demo of the new photo editor which is a part of the gallery in KitKat. The new nondestructive gallery editor includes 9 filters, 11 borders, and allows for cropping and changing around things like exposure, contrast, saturation and sharpness on images. There’s an auto button as well if you’re lazy but still want to add some more pop. What’s interesting about the Gallery application is that it’s implemented using Renderscript on Android and is impressively fast at applying new filters and finally rendering out the finished image.

There are a bunch of other software platform improvements in KitKat as well. The platform has been tuned to run well on devices with 512 MB of RAM, with more options for OEMs to manage memory on their devices. I originally started by trying to compare a Nexus 4 running 4.4 vs 4.3’s fresh boot memory footprint, but soon learned that the improvements seem to really change Android’s behavior as memory pressure is increased rather than lower the at-boot footprint. With a fresh install and fresh boot I didn’t notice much difference on the Nexus 4.

Fresh Install:
N4 - 4.4 1523 MB free of 1834 MB
N4 - 4.3 1522 MB free of 1870 MB

What has changed are the tools available to developers – dumpsys meminfo now gives more streamlined output with an easier to parse summary of memory use for processes and the total system. Comparing side by side between 4.3 and 4.4 it’s obvious how much this tool has been improved.

Total RAM: 1899564 kB 
Free RAM: 1104240 kB (545300 cached pss + 329160 cached + 229780 free) 
Used RAM: 606528 kB (453388 used pss + 89024 buffers + 11460 shmem + 52656 slab)
Lost RAM: 188796 kB

There’s a new procstats tool (dumpsys procstats) which gives per process breakdowns with run times, memory footprint, and other info. There’s also an in-device view under debugging that exposes a simpler summary of this information, with what percentage of the time the device was under different levels of memory pressure.

Android has been smooth and performant on the higher end devices for a while now, with almost all the jank and stutter that used to crop up being smoothed over with butter. That said, there were still project butter related improvements in KitKat which bear going over and improve the 2D rendering pipeline further. Google’s Romain Guy went over a number of these changes in a Google+ post.

 
New on-screen overdraw counter option, the stock Twitter app remains a heavy overdrawer

First off, batching and merging in the rendering pipeline has been improved further. One big improvement is shared texture memory support for most common holo assets. Android will now generate a single texture with all the framework assets for a given device to be shared among all processes, which helps save memory and also helps with batching and merging of draw operations. 

There are also further improvements to batching and merging draw operations, with more operations being merged together in KitKat. There’s also better font cache management which helps remove pressure that would otherwise get added with things like the new Emoji support, and asynchronous texture upload support which also helps apps that use a lot of glyphs.

I touch on it in the display section but Android 4.4 also adds software vsync support. This helps make animations even smoother by triggering redraws just ahead of hardware vsync. 

A while back, Android got the ability to visualize UI overdraw on-screen. This tool is improved in KitKat with a new view that shows a simple counter for tallying overdraw in a view, in addition to the older color coded region visualization. A big new improvement is automatic overdraw avoidance, which comes with KitKat, this can now remove simple cases of overdraw and avoid them entirely, like windows that are completely covered up.

ART - Android Runtime

Probably the biggest change people have asked about is the new Android runtime (ART) which is introduced as an experimental feature in Android 4.4. The Android source page on ART doesn’t give much color beyond that it’s an experimental runtime alternative to Dalvik, the longstanding runtime for Android. If you’re not familiar, the Dalvik virtual machine runs processes and apps on android devices which are written in Java, compiled to bytecode, then converted to a .dex (Dalvik executable) format to be executed by the Dalvik VM.

Most Android enthusiasts will remember the large performance increase that came with Android 2.2’s introduction of a JIT (Just In Time) compiler, which dramatically accelerated some applications. Although it hasn’t undergone any dramatic performance improvements since, truth be told, Dalvik has been tuned considerably by silicon vendors and improved by Google since the introduction of JIT in Android 2.2. Most users are familiar with the “Android is upgrading” prompt which happens after a dalvik-cache wipe, and masks further optimizations (DexOpt running) to .dex files and building the dalvik-cache partition.

With ART, instead of a JIT the runtime moves to an AOT (Ahead Of Time) compilation model, which takes place at boot over the same “Android is upgrading” dialog, and takes quite a bit longer. If you watch logcat while this is happening, you can see dex2oat (the new ART file format) running and compiling out files and building the dalvik-cache.

I/art ( 615): DexFile_isDexOptNeeded cache file /data/dalvik-cache/data@app@com.google.android.apps.maps–2.apk@classes.dex does not exist for /data/app/com.google.android.apps.maps–2.apk
I/PackageManager( 615): Running dexopt on: com.google.android.apps.maps I/dex2oat ( 951): dex2oat: /data/dalvik-cache/data@app@com.google.android.apps.maps–2.apk@classes.dex
W/dex2oat ( 951): Compilation of com.google.zxing.g.a.s[] com.google.zxing.g.a.s.f() took 126.362083ms

At present, ART is compatible with ARMv7, x86, and MIPS, but not yet compatible with ARMv8 or AArch64. In addition only AOT compilation of bytecode to native code is supported at present, though I suspect a JIT mode will come as well in the future. It’s obvious to me that ART is a work in progress, and its introduction in 4.4 is primarily to prepare silicon vendors for the inevitable switch to it as the default runtime at some point in the future. I think it’s easy to speculate that ART’s introduction might be in preparation for the inevitable switch to 64-bit (again, AArch64).

The performance associated with the VM underlying Android obviously translates to performance and battery life of the whole platform, at least for Java applications, and thus has huge importance. To investigate the performance deltas associated with ART I turned to two Nexus 5s and two Moto Xes, with Dalvik on one set, ART on the other. I brought out some of our old benchmarks which were written in Java or designed as Java benchmarks to test what’s different. As has been widely publicized you can switch between runtimes under developer options on the Nexus 5 and other KitKat devices, although there are a few apps that don’t behave nicely with ART, the majority work just fine.

The first table shows the delta between Nexus 5 with Dalvik selected and ART selected as the runtime, and a few benchmarks that are written in Java and thus test the performance of the runtime. Because garbage collection makes benchmarking on top of Android using Java apps non-determinstic with run to run variance, I ran these a lot of times and took and average.

AndEBench has interesting behavior, you can see up to a 10 percent improvement in performance in single thread, although the average ends up being around 7 percent. The two and four thread runs however lag behind Dalvik, clearly there’s some thread dispatch tuning that needs to take place. Caffeinemark, a classic Java benchmark, shows a substantial 50 percent performance improvement, and good old, somewhat dated Linpack (the Java version) shows a 30 percent improvement. I would take Caffeinemark and AndEBench as sort of the high and low bounds for what kind of performance improvements we might expect from ART, ultimately it depends on whether the compiler can create faster native code than Dalvik.

I spoke with a silicon vendor who was impressed with ART, but noted that the caffeinemark scores I was seeing were already close to what they could already get out of Dalvik. For a while, optimized and further tuned versions of Dalvik have undoubtedly come with the BSPs given to OEMs to build their software. With how quickly a few OEMs have rolled out updates, we get the chance to look at Qualcomm’s Dalvik vs ART pretty easily by looking at a Moto X.

Interestingly enough if the comparison is not the stock Dalvik (Nexus 5) vs ART but rather the customized, tuned Dalvik from Qualcomm (Moto X) vs ART, the story is very different, with at most a 19 percent improvement in caffeinemark and essentially equivalent performance elsewhere. It’s no surprise that I saw a lot of interest around sideloading and replacing libdvm.so on Nexus 5 with the one from Moto X or other Qualcomm 4.4 devices.

ART offers a performance improvement, of course it also introduces a few tradeoffs, like increased storage use in the dalvik-cache and potentially longer installation time and initial boot as AOT compilation runs. ART is experimental by Google’s measure, so it’s really premature to gauge performance right now, but it obviously has promise.

All around, KitKat is another sizable update to Android, with a ton of awesome improvements all around. I like the UI refinements and the improvements to the 2D rendering pipeline a whole lot and think Android has really matured into a capable computing platform.