Six under-the-hood Android N features you should know more about

Android N has a bunch of big new features in store for its users—the ones who eventually receive the update and don’t have those features torn out or replaced by their phone’s manufacturer, anyway. We’ve already covered a lot of the biggest user-facing stuff, including the multi-window multitasking mode, the revamped notifications and quick settings, and the new UI customization options.

But every year there are a few smaller or hidden features that are important to the platform but don’t get as much of a spotlight, either because they’re hidden under the covers or they appeal to a narrower audience. As we’ve done for Android L and M, we’ve looked at the developer docs and come up with a handful of new additions that you ought to know about as you’re playing with these early developer builds.

ART JIT

Google formally switched from the Dalvik Java runtime to the Android Runtime (ART) back in version 5.0, and it has continued to make new changes and optimizations since. Android N introduces a big one with far-reaching consequences—after switching entirely to ahead-of-time (AOT) code compilation in the first versions of ART, this version re-introduces just-in-time (JIT) compilation under certain circumstances to speed things up in areas where ART slowed down.

The main drawback with ART’s purely AOT compilation is app install times. Every app is compiled on your device as you install it instead of being compiled when you run it, which makes launching apps and using them faster but lengthens the amount of time it takes to install new apps and update old ones. Most egregiously, your apps need to be re-optimized every time you install an update. If you have dozens of apps, this means that even if you install one of the smallish monthly Nexus security updates, your phone or tablet is going to sit there churning for 20 or 30 minutes.

Android N gets rid of this step. ART will now use JIT compilation when an app is installed or after an OS update is applied, making app installations and system updates much quicker. That’s not to say that Google is throwing out all of the benefits of AOT compilation—rather, it uses code profiling to figure out which parts of the apps you use frequently, and it can use either AOT or JIT compilation depending on which one makes the most sense for a given app. AOT compilation is only done “when the device is idle and charging,” in an effort to preserve battery life.

Quick Settings API

You already know that Android N revamps the quick settings panel, making it easier to customize and quicker to use. What you may not know is that Android N actually includes an API that developers can use to make their own Quick Settings tiles.

Google says that these tiles “are reserved for controls or actions that are either urgently required or frequently used, and should not be used as shortcuts to launching an app.” Whether developers obey this rule is anyone’s guess, but it opens up some possibilities.

Data Saver

The Data Saver feature lets users on a metered network use less bandwidth by restricting background activity and lowering things like image size and streaming quality. Individual apps can be whitelisted by the user.

Developers will need to use Android’s ConnectivityManager API to read the phone or tablet’s Data Saver settings and adjust their data usage patterns accordingly. Hopefully users won’t be completely at the mercy of developers to make this feature useful, since Android developers aren’t always the fastest to pick up on new features and APIs.

Always on VPN

This one's all in the name. Android has had a VPN client for a long time, but in Android N Google has implemented an always-on VPN feature as part of its Android for Work initiative that will make it so that specific work apps always connect to the Internet through a specific VPN connection. Both end-users and device administrators should apparently be able to configure this, and it should work regardless of the VPN client app you use as long as they properly support Android’s intent filters. This should be a good security feature for people with apps they absolutely don’t want communicating in the clear on potentially dubious Wi-Fi networks.

Direct Boot

As of Android 6.0, all new Android devices that meet the minimum performance requirements need to have their storage encrypted. Android N makes this a little more complicated.

Storage in Android N is still encrypted, but data can be stored in two different locations. One is “credential encrypted storage,” which can only be unlocked when the user has unlocked her phone. The other, “device encrypted storage,” can be read after the device boots but before it is fully unlocked. This new post-boot pre-unlock state is called “Direct Boot” mode. If you’ve used an encrypted Android phone, you might have noticed that the emergency dialer is available before you unlock anything; we assume that Direct Boot is designed to offer a similar sort of functionality to third parties.

By default, apps won’t run in Direct Boot mode. But developers will be able to register components of their apps to run in this mode. The examples Google lists are “Apps that have scheduled notifications, such as alarm clock apps,” “Apps that provide important user notifications, like SMS apps,” and “Apps that provide accessibility services, like Talkback.”

Google wants basic functionality to be available to users even if their encrypted phones unexpectedly shut down or reboot. System updates, a dead battery, or a particularly spectacular crash could trigger such a reboot, and if that happens, apps that support Direct Boot should still be able to perform basic functions if you don’t or can’t fully unlock your phone.

Supporting this feature properly is going to be a balancing act. The device encrypted storage should protect data so that people who remove the flash chips from your phone, hook the phone to a computer in recovery mode, or try to infect your phone with some kind of rootkit can’t pull data from it. But if your phone can perform a “verified boot” (so, if the bootloader hasn’t been tampered with in some way), then some data could be exposed to third parties. The biggest risk is for notifications; your message history might be protected, but new notifications coming through apps configured to use Direct Boot could be exposed. Let’s hope developers use this one responsibly.

OpenGL ES 3.2 (but no Vulkan, at least not yet)

Android N brings official support for the OpenGL ES 3.2 graphics API to the platform, which is fine. But it doesn’t really bring a lot of new features to the table for Android, since OpenGL ES 3.1 and the Android Extensions Pack were already supported back in Lollipop and OpenGL ES 3.1 + Android Extensions Pack = (basically) OpenGL ES 3.2. It’s good that people who want to port OpenGL ES code between different platforms don’t have to worry about Android-specific extensions, but developers also won’t be able to do a whole lot more with the API than they’re already doing.

The bigger question is about Vulkan, the Khronos Group’s open alternative to low-overhead graphics APIs like Microsoft’s DirectX12 and Apple’s Metal. Google has already announced that Vulkan will serve as Android’s low-overhead graphics API, and there’s evidence in the source code and in Android’s NDK  that the company is working on support already. But it’s still not listed as an official feature of the N release. It may still be added—the APIs aren’t scheduled to be finalized until the fourth preview build, due sometime in June—but as of this writing it’s not there.

The most likely explanation is that Vulkan, while it has been kicking around in draft form for about a year, was only formally finalized last month. More recent GPU hardware from ARM and Qualcomm supports Vulkan at a hardware level, but GPU drivers and game engines will need to start supporting it before Android could really take advantage of it anyway. If it has to wait until the next release, it won’t be the end of the world, and OEMs who want it sooner are capable of taking things into their own hands anyway.