Android 7.0 for Developers: New Features, Performance Upgrades & Other Stuff You Won’t Care About

View all articles

Google formally announced Android 7.0 Nougat a few weeks ago, but as usual, you’ll have to wait. Most users won’t get their over-the-air (OTA) updates until early next year. Many others will receive them a week from never, as some device vendors simply don’t bother.

This may sound like a snarky pet peeve of mine, but Android fragmentation is no joke; it’s been a serious headache for users and developers for years. Android 7.0 won’t solve that issue, which is a shame because it enables a number of new features and performance improvements that users would surely enjoy.

Developers shouldn’t get their hopes up, however; there aren’t any game-changers here. Let’s look at the key tweaks under Android’s hood and the new opportunities they present, from most to least impactful.

  1. New JIT compiler, complementing ART’s existing AOT compiler
  2. Multi-window support
  3. Support for Vulkan API
  4. Direct boot
  5. Direct reply and bundled notifications
  6. Daydream virtual reality (VR) mode
  7. UI, accessibility tweaks, and background optimization

This is obviously not a comprehensive list of all new features; I settled on the top seven. You can get an in-depth overview of Android 7.0 if you head over to Google’s developer paradise. I will spare you the unnecessary fluff and provide you with useful info in a condensed, easy-to-digest form.

1. New JIT Compiler, Profile-Guided Compilation

JIT compilation is back, and while it might sound like a throwback to the days of Dalvik, it’s not. This time around, Google added a JIT compiler with code profiling to ART, to complement ART’s existing AOT compiler. And profile-guided compilation is the buzzword of the day.

A big user benefit: Large apps, which used to take minutes to install, now take seconds.

ART creates a profile for each app’s hot methods and various device conditions. It can precompile hot methods to deliver optimal performance, reduce RAM use, decrease power consumption, and more.

JIT and AOT Compiler in Android 7.0

Android 7.0: New features, performance boosts, and other stuff you won’t care about.

An added benefit is the sheer speed of installs and updates. Since profiling means there’s no optimizing step, Google even claims large apps, which took minutes to install on Android 6.0, can now be installed or updated in a matter of seconds. On a personal note, I hope this applies to World of Tanks Blitz as well, because it’s the only Android game worth my time.

Over the past couple of years, a lot of progress has been made in mobile storage. Many current-generation devices use fast UFS 2.0 storage, which delivers a significant performance boost compared to eMMC storage of yesteryear. Android 7.0 should enable software engineers to fully leverage this new storage standard and unlock even greater performance.

Check out one of my previous blog posts to find out what Google’s compiler plans mean for Android developers in more detail.

Developer impact: Profile-guided compilation should enable superior performance and efficiency gains. Installs and updates will be much faster, and, thanks to Google’s extensive documentation, implementation should be relatively easy. Less waiting for everyone. This is a good thing.

2. Multi-Window Support

Hold on a second—didn’t we already see multi-window features on Android? Yes and no; some forks offered multi-window support, but now it’s native. There are two split-screen implementations: side-by-side and one-above-the-other. This is more or less standard when it comes to mobile devices, but unfortunately, I haven’t had a chance to try it out yet.

Android 7.0 Multi-Window support

And, to be honest, I’ve never been a fan of multi-window functionality on mobile devices, because most users simply don’t need it.

However, it’s not just about smartphones. Google is also quietly working on smart TV offerings, so multi-window support will extend to these devices as well, but with a twist. With more display real estate to play with, app builders will be able to use picture-in-picture mode on TVs, and some functionality will be vendor-specific. Vendors will be able to decide whether or not to enable freeform mode. This means purveyors of oversized phablets, tablets, and other devices with big displays might allow users to play around with window size and position, which sounds similar to Microsoft’s approach, first implemented on Windows 8.x.

Developer impact: Multi-window support isn’t a game-changer, but it will provide an immediate opportunity on Android tablets and smart TVs, with the latter also getting picture-in-picture and the ability to record video. The problem? Android TVs aren’t very common and Android tablets were never very popular, especially when it comes to productivity applications that stand to gain most from multi-window support.

And who knows? Maybe a very bright developer will create a killer smartphone app that takes advantage of it. I won’t hold my breath.

3. Vulkan API

This is another potentially powerful update under the hood. Sure, it won’t get as much press and consumer interest as more gimmicky features, but make no mistake: Vulkan API is a big deal.

If case you missed it, Vulkan API is a new, low-overhead, close-to-metal API for graphics processing units (GPUs). And not just for 3D games but for GPU compute as well. Basically, it’s the follow-up to OpenGL and should enable superior performance on multithreaded processors along with cross-platform compatibility. It should also save thousands of man-hours in driver development.

So why isn’t it getting more buzz? Well, it’s a new standard and introducing an entirely new graphics API usually takes a couple of years. That’s why consumers don’t care, and why Android developers should care.

And now we wait ... Vulkan API support might not seem important now, but in a couple of years it will be huge.

To learn more about Vulkan implementation in Android 7.0, read the full Vulkan API overview I wrote earlier this year or check out Google’s dev resources.

Developer impact: Vulkan API’s time will come. It’ll reduce CPU overhead, thus boosting GPU performance and reducing power consumption in 3D games. However, adoption is bound to be slow, because we’re talking about an extremely potent and complex graphics API, not just a cosmetic tweak.

4. Direct Boot

What happens to a locked Android 7.0 device? It runs in a secure direct boot mode until the user unlocks the device.

To make this possible, Android 7.0 has two storage locations for data, with two different encryption solutions:

  • Device encrypted storage is available in direct boot and can be accessed regardless of whether the device is locked or unlocked.
  • Credential encrypted storage is still the default location and it’s available only after the user unlocks the device.

Most of the implications are obvious: Apps that need to operate in direct boot mode, prior to the device being unlocked, must be enabled to do so. By default, apps cannot run in direct boot, but developers can register different app components that need to run in this state.

This should include apps that deliver important or scheduled notifications, such as messaging and calendar apps. Apps that require access to storage have to rely on device encrypted storage, which is protected with a key that becomes available after the device performs a verified boot. Access does not extend to data associated with user credentials, namely PINs and passwords. Credential encrypted storage is not available until the device boots up and is unlocked by the user, but once it’s accessed, it remains available until the device is powered down.

Developer impact: Direct boot is supposed to improve security without compromising user experience and responsiveness. Implementation should be straightforward, but in some cases it will involve a fair amount of tedious work. Still, it sounds like a small tradeoff for added security.

5. Direct Reply & Bundled Notifications

It sounds like it’s related to direct boot, but direct reply is a different beast, allowing users to respond to messages and notifications from the notification screen. The inline reply action is available through a new button in the notification. In practice, users should be able to reply to notifications without accessing apps, and the system will take care of everything else.

The system can only do its magic if developers take their time to enable inline reply retrieval, by calling getResultsFromIntent(), which returns a bundle with the required text response. With Android 7.0, Google provides developers with a new method of representing queued notifications: bundled notifications. The solution is similar to the notification stack on Android Wear.

Bundled notifications are just that: similar missives presented in a single group, with a clean hierarchy, and with the parent notification on top. Users can then expand the bundle to access more information and take appropriate action, or easily dismiss everything if they’re not interested.

However, bundled notifications are not meant for use with all types of notifications. Google makes this point clear in Android notification best practices. Ideally, the approach should be used for applications that generate a large volume of similar or related notifications, such as messaging apps.

Starting in Android 7.0 (API level 24), users can respond directly to text messages or update task lists from within the notification dialog. On a handheld, the inline reply action appears as an additional button displayed in the notification. When a user replies via keyboard, the system attaches the text response to the intent you’d specified (for the notification action) and sends it to your handheld app.

Developer impact: Direct reply and bundled notifications should improve user experience in a number of scenarios. And judging by Google’s documentation, they shouldn’t be difficult to implement, either. Obviously, email, messaging, and social apps stand to gain the most from inline reply, though the approach could be implemented elsewhere.

6. Daydream Virtual Reality

Google’s recent focus on VR proves the search giant is not immune to hype. We all remember Google Cardboard and Google Glass, which was an ill-fated crack at the augmented reality space.

Unlike Glass, Cardboard didn’t simply wither and die, but it remains more of an experiment than a real product. Google improved the concept and it’s about to be relaunched in a few weeks, with a new name: Google Daydream. Daydream is, more or less, an evolutionary step. It looks like a tweaked Cardboard headset, but substantive changes are hard to spot.

Virtual reality on Android 7.0 is going to be disappointing. Not because the tech isn’t there, but because there isn’t any good content.

Support is coming soon, in the next generation of Android phones, but designers and developers can test their concepts on the current-gen Nexus 6P, currently the only Daydream-compliant device.

Google describes Daydream as the next-generation VR solution for mobile, with improved interactivity and better responsiveness compared to Cardboard. The company says it made improvements at all levels of the Android stack to improve responsiveness. This should allow Android 7.0 to access sensor data faster, and render the appropriate VR scene at the correct time, drastically reducing latency. Daydream also comes with a new wireless controller with APP and HOME buttons.

Unfortunately, none of these tweaks will address the biggest problem facing VR: lack of content. The good news is that things are picking up and Google is promising to deliver more content on Daydream through a number of partnerships covering everything from sitcoms to games.

My position on mobile VR remains somewhat conservative, as I outlined in my Google Cardboard overview. My views were partially vindicated by recent market research, which seems to suggest demand for VR remains soft. Google is unable to address all the teething problems facing mobile VR today. It’s not a matter of complacency; Google must wait for better hardware.

Even before I tried Cardboard, I knew battery life and thermals would be an issue, and so did Google. Moving forward, this will remain a lingering problem. In fact, Google clearly states that the thermal performance of the Nexus 6P is “not representative” of upcoming Daydream-ready phones:

“Expect the 6P to thermally throttle CPU and GPU performance after a short period of use, depending on workload.”

We will have to wait for chipmakers and smartphone vendors to introduce a new generation of products before we can truly take advantage of Daydream.

Developer impact: Daydream VR might offer a few new possibilities, but this isn’t as straightforward as it seems. While many tech companies are climbing aboard the VR train, consumers are not. Right now, it’s a lonely and expensive ride.

7. UI, Accessibility Tweaks & Background Optimization

Google polished the UI, added a few features, and fine-tuned performance in an effort to provide an even smoother user experience. Here’s a taste of what’s new:

  • Partial support for about 100 new languages, along with improved language packs and new local variants for major languages like Spanish and English.
  • Multiple locales in Settings, which will greatly improve the experience for multi-local and bilingual users.
  • Improved WebView, the in-app browser. It will rely on the Chrome APK (as of version 51) to render pages, reducing memory usage and bandwidth requirements. The standalone WebView APK will no longer be updated as long as Chrome rendering is enabled.
  • Android for Work updates to improve security and allow always-on VPN support. A quick-toggle feature will allow users to switch between work and personal modes.
  • Project Svelte, which is Google’s name for a range of background optimizations that change the way apps run to reduce RAM usage. Google says it will continue extending and updating JobScheduler and GCMNetworkManager, but at the same time, its removing three widely used broadcasts: CONNECTIVITY_ACTION, ACTION_NEW_PICTURE, and ACTION_NEW_VIDEO. If your app relies on any of them, you’ll have to migrate to JobScheduler. You can check the geeky details at Google.
  • UI tweaks to the Welcome screen and Quick Settings tile, which now includes a new API that can be used in third-party apps. Notification enhancements include two new custom view APIs.
  • Google Assistant, Google Allo, Google Duo.

Developer impact: These new features and tweaks are welcome additions to Android, but they’re unlikely to generate a lot of new opportunities.

Android 7.0: What’s the Bottom Line?

It’s fair to say that Android 7.0 isn’t a huge deal for developers. It’s an incremental improvement, mostly about optimization. It won’t facilitate the creation of earth-shattering apps and services that weren’t possible before.

But I don’t see anything wrong with that. Smartphones are already feature-packed and people are getting tired of gimmicks, so it’s understandable Google chose to focus on improving performance, power efficiency, security, and overall user experience. And, like iOS, Android is now mature. If you’re disappointed by the lack of new features, I suggest you get used to it because it’s the new normal.

The days of rapid hardware and software evolution in mobile are long gone. Incremental is the new normal.

Come to think of it, the biggest piece of news around Android 7.0 isn’t the OS itself. It’s Google’s decision to launch new Pixel phones designed to take advantage of everything the OS has to offer. From a hardware perspective, they’re not particularly special—they’re based on off-the-shelf technology just like their Nexus-series predecessors. But Google’s business model for Pixel is very different, with the focus on controlling the end-to-end user experience and adding value in an Apple-like way.

It’s too early to speculate what impact Pixel will have on the rest of the Android ecosystem, but this much is certain: It’ll be a delicate balancing act. Google could choose to reserve some functionality solely for its in-house Pixel phones, but at the same time it can’t overplay its hand. It can’t afford to alienate Android vendors and render their products less competitive by adding too many Pixel-exclusive features.

How this all plays out remains to be seen, but in the meantime we should focus on making the most of Android 7.0. Actually, make that 7.1, which is in Beta and will likely be released shortly.

Hiring? Meet the Top 10 Freelance Android Developers for Hire in December 2016
Don't miss out.
Get the latest updates first.
No spam. Just great engineering and design posts.
Don't miss out.
Get the latest updates first.
Thank you for subscribing!
You can edit your subscription preferences here.

Comments

eddnav
Thanks for the insightful article, my work with Xamarin has kept me off the loop these past two months and this was just what I needed to get a bit of what I missed. Still have a bunch of I/O stuff to catch up though.
xgqfrms
Yeah! It's super cool!
comments powered by Disqus