Encryption protects your data if your phone falls into someone else's hands. The new Google Pixel and Pixel XL are encrypted by default to offer strong data protection, while maintaining a great user experience with high I/O performance and long battery life. In addition to encryption, the Pixel phones debuted running the Android Nougat release, which has even more security improvements.

This blog post covers the encryption implementation on Google Pixel devices and how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was file-based encryption. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.

Direct boot uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software. This secures encrypted data in two ways:

TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.

TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach from full-disk encryption (FDE). The natural choice for Linux-based systems is the industry-standard eCryptFS. However, eCryptFS didn't meet our performance requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and Android became the first consumer of this technology. ext4 encryption performance is similar to full-disk encryption, which is as performant as a software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which gives them the ability to write encrypted data at line speed to the flash memory. To take advantage of this, we modified ext4 encryption to use this hardware by adding a key reference to the bio structure, within the ext4 driver before passing it to the block layer. (The bio structure is the basic container for block I/O in the Linux kernel.) We then modified the inline encryption block driver to pass this to the hardware. As with ext4 encryption, keys are managed by the Linux keyring. To see our implementation, take a look at the source code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with inline encryption benefits Pixel users, FBE is available in AOSP and ready to use, along with the other features mentioned in this post.

Android Studio 2.2 launched recently with many new and improved features. Some of the changes are easy to miss because they happened under the hood in the Android Gradle plugin, such as the newly rewritten integrated APK packaging and signing step.

APK Signature Scheme v2

With the introduction of the new APK Signature Scheme v2 in Android 7.0 Nougat, we decided to rewrite how assembling APKs works in the Android Gradle plugin. You can read all about the low-level technical details of v2 signatures in the documentation, but here's a quick tl;dr summary of the info you need as an Android app developer:

The cryptographic signature of the APK that is used to verify its integrity is now located immediately before the ZIP Central Directory.

The signature is computed and verified over the binary contents of the whole APK file, as opposed to decompressed file contents of each file in the archive in v1.

An APK can be signed by both v1 and v2 signatures at the same time, so it remains backwards compatible with previous Android releases.

Why introduce this change to how Android verifies APKs? Firstly, for enhanced security and extensibility of this new signing format, and secondly for performance - the new signatures take significantly less time to verify on the device (no need for costly decompression), resulting in faster app installation times.

The consequence of this new signing scheme, however, is that there are new constraints on the APK creation process. Since only uncompressed file contents were verified in v1, that allowed for quite a lot of modifications to be made after APK signing - files could be moved around or even recompressed. In fact, the zipalign tool which was part of the build process did exactly that - it was used to align ZIP entries on correct byte boundaries for improved runtime performance.

Because v2 signatures verify all bytes in the archive and not individual ZIP entries, running zipalign is no longer possible after signing. That's why compression, aligning and signing now happens in a single, integrated step of the build process.

If you have any custom tasks in your build process that involve tampering with or post-processing the APK file in any way, please make sure you disable them or you risk invalidating the v2 signature and thus making your APKs incompatible with Android 7.0 and above.

Should you choose to do signing and aligning manually (such as from the command line), we offer a new tool in the Android SDK, called apksigner, that provides both v1 and v2 APK signing and verification. Note that you need to run zipalignbefore running apksigner if you are using v2 signatures. Also remember the jarsigner tool from the JDK is not compatible with Android v2 signatures, so you can't use it to re-sign your APKs if you want to retain the v2 signature.

In case you want to disable adding v1 or v2 signatures when building with the Android Gradle plugin, you can add these lines to your signingConfig section in build.gradle:

v1SigningEnabled false
v2SigningEnabled false

Note: both signing schemes are enabled by default in Android Gradle plugin 2.2.

Release builds for smaller APKs

We took this opportunity when rewriting the packager to make some optimizations to the size of release APKs, resulting in faster downloads, smaller delta updates on the Play Store, and less wasted space on the device. Here are some of the changes we made:

Files in the archive are now sorted to minimize differences between APK builds.

All file timestamps and metadata are zeroed out.

Level 6 and level 9 compression is checked for all files in parallel and the optimal one is used, i.e. if L9 provides little benefit in terms of size, then L6 may be chosen for better performance

Native libraries are stored uncompressed and page aligned in the APK. This brings support for the android:extractNativeLibs="false" option from Android 6.0 Marshmallow and lets applications use less space on the device as well as generate smaller updates on the Play Store

Zopfli compression is not used to better support Play Store update algorithms. It is not recommended to recompress your APKs with Zopfli. Pre-optimizing individual resources such as PNG files in your projects is still fine and recommended.

These changes help make your releases as small as possible so that users can download and update your app even on a slower connection or on less capable devices. But what about debug builds?

Debug builds for installation speed

When developing apps you want to keep the iteration cycle fast - change code, build, and deploy on a connected device or emulator. Since Android Studio 2.0 we've been working to make all the steps as fast as possible. With Instant Run we're now able to update only the changed code and resources during runtime, while the new Emulator brings multi-processor support and faster ADB speeds for quicker APK transfer and installation. Build improvements can cut that time even further and in Android Studio 2.2 we're introducing incremental packaging and parallel compression for debug builds. Together with other features like selectively packaging resources for the target device density and ABI this will make your development even faster.

A word of caution: the APK files created for Instant Run or by invoking a debug build are not meant for distribution on the Play Store! They contain additional instrumentation code for Instant Run and are missing resources for device configurations other than the one that was connected when you started the build. Make sure you only distribute release versions of the APK which you can create using the Android Studio Generate Signed APK command or the assembleRelease Gradle task.

To deliver the best user experience right out of the gate, Firebase Test Lab for Android allows you to test your apps and ensure their compatibility with multiple device configurations, across OS versions, screen orientations, and locales. With a single click, you can run your tests on hundreds of device configurations in Google Cloud and receive your results quickly.

Today, we’re excited to announce the availability of the Android 7.1 Developer Preview on Firebase Test Lab virtual devices. In addition to testing the Android 7.1 Developer Preview on your physical Android Device with the Android Beta program, or on your local Android Emulator, you can use the Firebase Test Lab to scale your app testing to hundreds of Android virtual devices.

You can also use Firebase Test Lab to perform your own testing. If you don’t have any test scripts, Robo test is ideal for doing your basic compatibility testing on the new platform. It crawls your app in an attempt to find crashes. You can also use the Espresso Test Recorder in Android Studio to record your own instrumentation tests without writing any code.

From now until the end of December (12/31/2016), Firebase Test Lab will be offered at no charge on the Firebase Blaze plan for all virtual devices, to help you ensure the compatibility of your app with the Android 7.1 Developer Preview release, as well as with other Android releases.

Now that Nougat has begun to roll out, we wanted to recap these updates in a single overview and highlight a few new improvements.

Direct Boot and encryption

In previous versions of Android, users with encrypted devices would have to enter their PIN/pattern/password by default during the boot process to decrypt their storage area and finish booting. With Android 7.0 Nougat, we’ve updated the underlying encryption scheme and streamlined the boot process to speed up rebooting your phone. Now your phone’s main features, like the phone app and your alarm clock, are ready right away before you even type your PIN, so people can call you and your alarm clock can wake you up. We call this feature Direct Boot.

Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys. Essential apps can opt-in to run in a limited state after reboot, and when you enter your lock screen credential, these apps then get access your user data to provide full functionality.

File-based encryption better isolates and protects individual users and profiles on a device by encrypting data at a finer granularity. Each profile is encrypted using a unique key that can only be unlocked by your PIN or password, so that your data can only be decrypted by you.

Encryption support is getting stronger across the Android ecosystem as well. Starting with Marshmallow, all capable devices were required to support encryption. Many devices, like Nexus 5X and 6P also use unique keys that are accessible only with trusted hardware, such as the ARM TrustZone. Now with 7.0 Nougat, all new capable Android devices must also have this kind of hardware support for key storage and provide brute force protection while verifying your lock screen credential before these keys can be used. This way, all of your data can only be decrypted on that exact device and only by you.

The media stack and platform hardening

In Android Nougat, we’ve both hardened and re-architected mediaserver, one of the main system services that processes untrusted input. First, by incorporating integer overflow sanitization, part of Clang’s UndefinedBehaviorSanitizer, we prevent an entire class of vulnerabilities, which comprise the majority of reported libstagefright bugs. As soon as an integer overflow is detected, we shut down the process so an attack is stopped. Second, we’ve modularized the media stack to put different components into individual sandboxes and tightened the privileges of each sandbox to have the minimum privileges required to perform its job. With this containment technique, a compromise in many parts of the stack grants the attacker access to significantly fewer permissions and significantly reduced exposed kernel attack surface.

In addition to hardening the mediaserver, we’ve added a large list of protections for the platform, including:

App security improvements

Android Nougat is the safest and easiest version of Android for application developers to use.

Apps that want to share data with other apps now must explicitly opt-in by offering their files through a Content Provider, like FileProvider. The application private directory (usually /data/data/) is now set to Linux permission 0700 for apps targeting API Level 24+.

To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.

With Network Security Config, developers can more easily configure network security policy through a declarative configuration file. This includes blocking cleartext traffic, configuring the set of trusted CAs and certificates, and setting up a separate debug configuration.

We’ve also continued to refine app permissions and capabilities to protect you from potentially harmful apps.

To improve device privacy, we have further restricted and removed access to persistent device identifiers such as MAC addresses.

User interface overlays can no longer be displayed on top of permissions dialogs. This “clickjacking” technique was used by some apps to attempt to gain permissions improperly.

We’ve reduced the power of device admin applications so they can no longer change your lockscreen if you have a lockscreen set, and device admin will no longer be notified of impending disable via onDisableRequested(). These were tactics used by some ransomware to gain control of a device.

System Updates

Lastly, we've made significant enhancements to the OTA update system to keep your device up-to-date much more easily with the latest system software and security patches. We've made the install time for OTAs faster, and the OTA size smaller for security updates. You no longer have to wait for the optimizing apps step, which was one of the slowest parts of the update process, because the new JIT compiler has been optimized to make installs and updates lightning fast.
The update experience is even faster for new Android devices running Nougat with updated firmware. Like they do with Chromebooks, updates are applied in the background while the device continues to run normally. These updates are applied to a different system partition, and when you reboot, it will seamlessly switch to that new partition running the new system software version.

We’re constantly working to improve Android security and Android Nougat brings significant security improvements across all fronts. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at security@android.com.

As we put the finishing touches on the next release of Android, which will begin to roll out to consumers later this summer, we’re releasing the 4th Developer Preview of Android N, including the Android N final SDK. And thanks to your continued feedback over the last three releases, all of the APIs are now final as well. If you’ve already enrolled your device in the Android Beta Program, (available at android.com/beta) you will receive an update to this Developer Preview shortly.

Get your apps ready for Android N

The final SDK for Android N is now available for download through the SDK Manager in Android Studio. It gives you everything you need to develop and test against the official APIs in the Android N platform. Once you’ve installed the final SDK, you can update your project’s compileSdkVersion to API 24 to develop with the Android N APIs and build and test on the new platform, for new features such as Multi-window support, direct-reply notifications, and others. We also recommend updating your app’s targetSdkVersion to API 24 to opt-in and test your app with Android N specific behavior changes. For details on how to setup your app with the final SDK, see Set up the Preview. For details on API level 24 check out the API diffs and the updated API reference, now hosted online.

Along with the Android N final SDK, we’ve also updated the Android Support Library to 24.0.0. This allows you to use multi-window and picture-in-picture callbacks, new notification features, methods for supporting Direct Boot, and new MediaBrowser APIs in a backward compatible manner.

Publish your apps to alpha, beta or production channels in Google Play

Now that you have a final set of APIs, you can publish updates compiling with, and optionally targeting, API 24 to Google Play. You can now publish app updates that use API 24 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, you can test your app’s backward-compatibility and push updates to users whose devices are running Developer Preview 4.

To make sure that your updated app runs well on Android N, as well as older versions, a common strategy is to use Google Play’s beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to Get Developer Preview 4

Developer Preview 4 includes updated system images for all supported Preview devices as well as for the Android emulator. If you are already enrolled in the Android Beta program, your devices will get the Developer Preview 4 update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. As always, you can also download and flash this update manually. The N Developer Preview is available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices and the Sony Xperia Z3.