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.
This is obviously not a comprehensive list of ###em
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.
Android 7.0: New features, performance boosts, and other stuff you won’t care about.
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 ###a href="find" class="redactor-linkify-object">https://www.toptal.com/android... 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.
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.
However, it’s not just about smartphones. Google is also quietly working on smart TV offerings, so ###a href="https://developer.android.com/guide/topics/ui/multi-window.html?utm_source=anddev&utm_medium=blog" rel="noopener noreferrer" target="_blank">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.
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 ###a href="Android" class="redactor-linkify-object">https://www.toptal.com/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.
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.
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:
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.
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 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 ###em
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 ###a href="my" class="redactor-linkify-object">https://www.toptal.com/virtual... 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.
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:
GCMNetworkManager, but at the same time, its removing three widely used broadcasts:
ACTION_NEW_VIDEO. If your app relies on any of them, you’ll have to migrate to
JobScheduler. You can ###a href="https://developer.android.com/topic/performance/background-optimization.html" rel="noopener noreferrer" target="_blank">check the geeky details at Google.
Developer impact: These new features and tweaks are welcome additions to Android, but they’re unlikely to generate a lot of new opportunities.
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.