Posted by Dave Burke, VP of Engineering

A couple of weeks ago we announced that a developer preview of Android 7.1 Nougat was on the way. You can get started with this new release today by downloading the SDK and tools. To get the 7.1 release on your eligible device, enroll your device in the Android Beta program. If your device is already enrolled, you'll receive the update automatically.

What’s in the Developer Preview?

The Android 7.1 Developer Preview gives you everything you need to test your app on the new platform or extend it with new features like app shortcuts and image keyboard support. It includes an updated SDK and tools, documentation and samples, as well as emulators and device system images for running your apps on supported devices.

We’re continuing the model we used in N and earlier releases, and with Android 7.1 being an incremental release there are a few differences to highlight:

• Since 7.1 has already launched on Pixel, we’re delivering the initial Developer Preview at beta quality for the Nexus lineup of devices. The goal is to tease out any device-specific issues.


• We’ve finalized the new APIs as API Level 25


• We’ve opened up publishing on Google Play for apps targeting the new API level, so you can update your apps soon as you are ready.

After the initial preview release, we plan to deliver an update in November followed by the final public release to the Android Open Source Project (AOSP) in December. Initially available on Nexus 5X, Nexus 6P, and Pixel C devices, we’ll extend the Developer Preview to other devices in November.

Get your apps ready for Android 7.1

To get started, update to Android Studio 2.2.2 and download API Level 25 platform, emulator system images and tools. The final API Level 25 SDK is available for download through the SDK Manager in Android Studio.

Once you’ve installed the API Level 25 SDK, you can update your project’s compileSdkVersion to 25 to build and test against the new APIs. If you’re doing compatibility testing, we recommend updating your app’s targetSdkVersion to 25 to test your app with compatibility behaviors disabled. For details on how to set up your app with the API Level 25 SDK, see Set up the Preview.

If you’re adding app shortcuts or circular launcher icons to your app, you can use Android Studio’s built-in Image Asset Studio to quickly help you create icons of different sizes that meet the material design guidelines.

The Google APIs Emulator System images shipped with the Android API Level 25 SDK include support for round icons and the new Google Pixel Launcher. The Google API system image allows you to test how your app’s circular app icons look in devices that support circular icons. Also, if you are developing live wallpapers, you can also use the the new system images with the Android Emulator to test the enhanced preview metadata in Android 7.1.

To help you add image keyboard support, you can use the Messenger and Google Keyboard apps included in the preview system images for testing as they include support for this new API.

Along with the API Level 25 SDK, we have also updated the Android Support Library to 25.0.0. The new version lets you add image keyboard support with compatibility back to API level 13. It also introduces BottomNavigationView widget, which implements the bottom navigation pattern from the material design guidelines.

For details on API Level 25 check out the API diffs and the updated API reference on the developer preview site.

You can use the Android Emulator in Android Studio to test your circular app icons & shortcuts in a launcher

You can use the Image Asset tool to quickly create circular icon assets.

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

Since the Android 7.1 APIs are final, you can publish updates compiling with, and optionally targeting, API 25 to Google Play. You can now publish app updates that use API 25 to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, push your app updates to users whose devices are running Android 7.1, such as Pixel and Android Beta devices.

How to Get Android 7.1 Developer Preview on Your Eligible Device

If you are already enrolled in the Android Beta program, then your eligible enrolled devices will get the Android 7.1 Developer Preview 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 to visit android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. If you have an enrolled device and do not want to receive the update, just visit Android Beta and unenroll the device. You can also download and flash this update manually.

We welcome your feedback in the Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release in December!

Posted by Dave Burke, VP of Engineering

Today, we’re taking the wraps off of Android 7.1 Nougat, the latest version of the platform. You probably saw a sneak peek of it at last week’s event. It’s an incremental update based on Android 7.0 but includes new features for consumers and developers — from platform Daydream VR support and A/B system updates to app shortcuts and image keyboard support.

We’ve already been working closely with device makers to get them ready for Android 7.1, and next we’ll give you access to this update so you can start getting your apps ready.

Later this month we’ll be bringing you the Android 7.1 platform as an open Developer Preview, similar to what we did for Android 7.0. You’ll be able to test and build on the new platform and try the latest features.

As always, we’ll deliver the Developer Preview through the Android Beta program, which makes it incredibly easy to participate.

What’s in Android 7.1?

Android 7.1 delivers the productivity, security, and performance of Android 7.0, along with a variety of optimizations and bug fixes, features, and new APIs (API level 25).

For developers, Android 7.1 adds new capabilities to help you drive engagement in your app and deliver an improved user experience, such as:

• App shortcuts API — lets you surface key actions directly in the launcher and take your users deep into your app instantly. You can create up to 5 shortcuts, either statically or dynamically.


• Circular app icons support — lets you provide great-looking rounded icon resources that match the look of Pixel and other launchers.


• Enhanced live wallpaper metadata — lets you provide metadata about your live wallpapers to any picker displaying the wallpapers as a preview. You can show existing metadata such as label, description, and author, as well as a new context URL and title to link to more information.

Android 7.1 also adds these much-requested developer features to the platform:

• Image keyboard support — expands the types of content that users can enter from their keyboards, letting them express themselves through custom stickers, animated gifs, and more. Apps can tell the keyboard what types of content they accept, and keyboards can deliver all of the images and other content that they offer to the user. For broad compatibility, this API will also be available in the support library.


• Storage manager Intent — lets an app take the user directly to a new Settings screen to clear unused files and free up storage space on the device.

For carriers and calling apps, the platform includes new APIs to support multi-endpoint calling and new telephony configuration options.

Image keyboard support: Let users input images and other content directly from a keyboard.

App shortcuts: Use app shortcuts to surface key actions and take users deep into your app instantly.

Get your apps ready

Android 7.1 is an incremental release, but it’s always important to make sure your apps look and run great — especially as devices start to reach consumers.

The Android 7.1 Developer Preview will give you everything you need to test your apps or extend them with new features like shortcuts or keyboard images. Included are the SDK with new APIs, build tools, documentation and samples, as well as emulators and device system images for running your apps on supported Nexus devices. We’ll also include a launcher and apps that support app shortcuts, and a keyboard and apps that support keyboard images.

If you want to receive the Developer Preview automatically, visit Android Beta and enroll your device. If you previously enrolled a device and haven’t unenrolled, your device will receive the update. If you already enrolled but don’t want to receive the update, visit Android Beta to unenroll the device as soon as possible.

Initially, we’ll offer the Developer Preview for Nexus 5X, Nexus 6P, and Pixel C devices, extending to other supported devices by the end of the preview. At the final release of the Android 7.1.x platform, due in early December, we’ll roll out updates to the full lineup of supported devices — Nexus 6, 5X, 6P, 9, Player, Pixel C, and supported Android One devices — as well as Pixel and Pixel XL devices.

Coming to consumer devices soon

We’re working with our partners to bring Android 7.1 to devices in the ecosystem over the months ahead, so we recommend downloading the Android 7.1 Developer Preview as soon as it’s available. Test your apps for compatibility and optimize them to look their best, such as by providing circular app icons and adding app shortcuts.

Meanwhile, stay tuned, we’ll be sharing more details about the Developer Preview soon!

Posted by Lily Sheringham, Google Play team

Papumba is an educational games developer based in Argentina, with a core team of four people and a vision to grow a global business.

Watch Gonzalo Rodriguez, CEO, and Andres Ballone, CFO, explain how working with a team of experts from across the world and adapting their games to local markets helped them find success globally.

Learn more about localized pricing and translation services to grow your app or game business globally on Google Play. Also, get the Playbook for Developers app to stay up-to-date on new features and learn best practices that will help you grow a successful business on Google Play.

By Jamal Eason, Product
Manager, Android

Android Studio 2.2 is available to href="https://developer.android.com/studio/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">download today.
Previewed at Google I/O 2016, Android Studio 2.2 is the latest release of our
IDE used by millions of Android developers around the world.

Packed with enhancements, this release has three major themes: speed, smarts,
and Android platform support. Develop faster with features such as the new
Layout Editor, which makes creating an app user interface quick and intuitive.
Develop smarter with our new APK analyzer, enhanced Layout Inspector, expanded
code analysis, IntelliJ’s 2016.1.3 features and much more. Lastly, as the
official IDE for Android app development, Android Studio 2.2 includes support
for all the latest developer features in Android 7.0 Nougat, like href="https://developer.android.com/studio/intro/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#code_completion">code
completion to help you add Android platform features like href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#multi-window_support">Multi-Window
support, href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#tile_api">Quick
Settings API, or the redesigned href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#notification_enhancements">Notifications,
and of course, the built-in href="https://developer.android.com/studio/run/emulator.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Android
Emulator to test them all out.

In this release, we evolved the Android Frameworks and the IDE together to
create the Constraint Layout. This powerful new layout manager helps you design
large and complex layouts in a flat and streamlined hierarchy. The
ConstraintLayout integrates into your app like a standard Android
support library, and was built in parallel with the new Layout Editor.

Android Studio 2.2 includes 20+ new features across every major phase of the
development process: design, develop, build, & test. From designing UIs with
the new ConstraintLayout, to developing C++ code with the Android
NDK, to building with the latest Jack compliers, to creating Espresso test cases
for your app, Android Studio 2.2 is the update you do not want to miss. Here’s
more detail on some of the top highlights:

Design

• Layout Editor: Creating Android app user interfaces is now
  easier with the new user interface designer. Quickly construct the structure of
  your app UI with the new blueprint mode and adjust the visual attributes of each
  widget with new properties panel. href="https://developer.android.com/studio/write/layout-editor.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Learn
  more.

• Constraint Layout: This new layout is a flexible layout
  manager for your app that allows you to create dynamic user interfaces without
  nesting multiple layouts. It is backwards compatible all the way back to Android
  API level 9 (Gingerbread). ConstraintLayout works best with the new Layout
  Editor in Android Studio 2.2. href="https://developer.android.com/training/constraint-layout/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Learn
  more.

Develop

• Improved C++ Support: You can now use href="https://developer.android.com/studio/projects/add-native-code.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">CMake
  or ndk-build to compile your C++ projects from Gradle. Migrating projects
  from CMake build systems to Android Studio is now seamless. You will also find
  C++ support in the new project wizard in Android Studio, plus a number of bug
  fixes to the C++ edit and debug experience. href="https://developer.android.com/studio/projects/add-native-code.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Learn
  more.

• Samples Browser: Referencing href="http://developer.android.com/samples/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Android sample code
  is now even easier with Android Studio 2.2. Within the code editor window, find
  occurrences of your app code in Google Android sample code to help jump start
  your app development. Learn more.

Build

• Instant Run Improvements: Introduced in Android Studio 2.0,
  href="https://developer.android.com/studio/run/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#instant-run">Instant
  Run is our major, long-term investment to make Android development as fast
  and lightweight. Since launch, it has significantly improved the edit, build,
  run iteration cycles for many developers. In this release, we have made many
  stability and reliability improvements to Instant Run. If you have previously
  disabled Instant Run, we encourage you to re-enable it and let us know if you
  come across further issues. (Settings → Build, Execution, Deployment → Instant
  Run [Windows/Linux] , Preferences → Build, Execution, Deployment → Instant Run
  [OS X]). For details on the fixes that we have made, see the href="https://developer.android.com/studio/releases/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Android Studio
  2.2 release notes.

• APK Analyzer: Easily inspect the contents of your APKs to
  understand the size contribution of each component. This feature can be helpful
  when debugging href="https://developer.android.com/studio/build/multidex.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">multi-dex
  issues. Plus, with the APK Analyzer you can compare two versions of an APK. href="https://developer.android.com/studio/build/apk-analyzer.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Learn
  more.

• Build cache (Experimental): We are continuing our
  investments to improve build speeds with the introduction of a new experimental
  build cache that will help reduce both full and incremental build times. Just
  add android.enableBuildCache=true to your
  gradle.properties file. href="http://tools.android.com/tech-docs/build-cache">Learn more.

Test

• Virtual Sensors in the Android Emulator: The Android
  Emulator now includes a new set of virtual sensors controls. With the new UI
  controls, you can now test href="https://developer.android.com/guide/topics/sensors/sensors_overview.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Android
  Sensors such as Accelerometer, Ambient Temperature, Magnetometer and more.
  Learn
  more.

• Espresso Test Recorder (Beta): The Espresso Test Recorder
  lets you easily create UI tests by recording interactions with your app; it then
  outputs the href="https://developer.android.com/topic/libraries/testing-support-library/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#Espresso">UI
  test code for you. You record your interactions with a device and add
  assertions to verify UI elements in particular snapshots of your app. Espresso
  Test Recorder then takes the saved recording and automatically generates a
  corresponding UI test. You can run the test locally, on your continuous
  integration server, or using href="https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog#run-ctl">Firebase
  Test Lab for Android. href="https://developer.android.com/studio/test/espresso-test-recorder.html">Learn
  more.

• GPU Debugger (Beta): The GPU Debugger is now in Beta. You
  can now capture a stream of OpenGL ES commands on your Android device and then
  replay it from inside Android Studio for analysis. You can also fully inspect
  the GPU state of any given OpenGL ES command to better understand and debug your
  graphical output. href="https://developer.android.com/studio/debug/am-gpu-debugger.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">Lean
  more.

To recap, Android Studio 2.2 includes these major features and more:

Learn more about Android Studio 2.2 by reviewing the href="https://developer.android.com/studio/releases/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">release notes
and the href="http://android-developers.blogspot.com/2016/05/android-studio-22-preview-new-ui.html">preview
blog post.

Getting Started

Download

If you are using a previous version of Android Studio, you can check for updates
on the Stable channel from the navigation menu (Help → Check for Update
[Windows/Linux] , Android Studio → Check for Updates [OS X]). You can also
download Android Studio 2.2 from the official href="https://developer.android.com/studio/index.html?utm_campaign=android studio_launch_2.2_091916&utm_source=anddev&utm_medium=blog">download page. To
take advantage of all the new features and improvements in Android Studio, you
should also update to the Android Gradle plugin version to 2.2.0 in your current
app project.

Next Release

We would like to thank all of you in the Android Developer community for your
work on this release. We are grateful for your contributions, your ongoing
feedback which inspired the new features in this release, and your highly active
use on canary and beta builds filing bugs. We all wanted to make Android Studio
2.2 our best release yet, with many stability and performance fixes in addition
to the many new features. For our next release, look for even more; we want to
work hard to address feedback and keep driving up quality and stability on
existing features to make you productive.

We appreciate any feedback on things you like, issues or features you would like
to see. Connect with us -- the Android Studio development team -- on our href="https://plus.google.com/103342515830390186255">Google+ page or on href="http://www.twitter.com/androidstudio">Twitter.

Posted by Xiaowen Xin, Android Security Team

Over the course of the summer, we previewed a variety of security enhancements in
Android 7.0 Nougat: an increased focus on security with our href="http://android-developers.blogspot.com/2016/06/one-year-of-android-security-rewards.html">vulnerability
rewards program, a new href="http://android-developers.blogspot.com/2016/04/developing-for-direct-boot.html">Direct
Boot mode, re-architected mediaserver and href="http://android-developers.blogspot.com/2016/05/hardening-media-stack.html">hardened
media stack, apps that are protected from href="http://android-developers.blogspot.com/2016/04/protecting-against-unintentional.html">accidental
regressions to cleartext traffic, an update to the way Android handles href="http://android-developers.blogspot.com/2016/07/changes-to-trusted-certificate.html">trusted
certificate authorities, strict enforcement of href="http://android-developers.blogspot.com/2016/07/strictly-enforced-verified-boot-with.html">verified
boot with error correction, and href="http://android-developers.blogspot.com/2016/07/protecting-android-with-more-linux.html">updates
to the Linux kernel to reduce the attack surface and increase memory
protection. Phew!

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 href="http://android-developers.blogspot.com/2016/04/developing-for-direct-boot.html">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 href="http://android-developers.blogspot.com/2016/05/hardening-media-stack.html">re-architected
mediaserver, one of the main system services that processes untrusted input.
First, by incorporating integer overflow sanitization, part of Clang’s href="http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html">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:

• Verified Boot: Verified Boot is now strictly enforced to
  prevent compromised devices from booting; it supports href="http://android-developers.blogspot.com/2016/07/strictly-enforced-verified-boot-with.html">error
  correction to improve reliability against non-malicious data corruption.
  
• SELinux: Updated SELinux configuration and increased
  Seccomp coverage further locks down the application sandbox and reduces attack
  surface.
  
• Library load order randomization and improved ASLR:
  Increased randomness makes some code-reuse attacks less reliable.
  
• href="http://android-developers.blogspot.com/2016/07/protecting-android-with-more-linux.html">Kernel
  hardening: Added additional memory protection for newer kernels by
  href="https://android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:arm64-ronx">marking
  portions of kernel memory as read-only, href="https://android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-4.1+topic:sw_PAN">restricting
  kernel access to userspace addresses, and further reducing the existing
  attack surface.
  
• href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog#apk_signature_v2">APK
  signature scheme v2: Introduced a whole-file signature scheme that
  improves href="https://source.android.com/security/apksigning/v2.html#verification">verification
  speed and strengthens integrity guarantees.

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 href="https://developer.android.com/guide/topics/providers/content-providers.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog">Content
  Provider, like href="https://developer.android.com/reference/android/support/v4/content/FileProvider.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog">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 href="http://android-developers.blogspot.com/2016/07/changes-to-trusted-certificate.html">no
  longer trusted by default for apps targeting API Level 24+. Additionally,
  all new Android devices must ship with the href="https://source.android.com/security/overview/app-security.html#certificate-authorities">same
  trusted CA store.
  
• With href="https://developer.android.com/preview/features/security-config.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/reference/android/app/admin/DeviceAdminReceiver.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog#onDisableRequested(android.content.Context,%20android.content.Intent)">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 href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android_discussion_security_090616&utm_source=anddev&utm_medium=blog#doze_on_the_go">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.

Posted by Dave Burke, VP of Engineering

Android 7.0 Nougat

Today, Android 7.0 Nougat will begin rolling out to users, starting with Nexus
devices. At the same time, we’re pushing the Android 7.0 source code to the
Android Open Source Project (AOSP), extending public availability of this new
version of Android to the broader ecosystem.

We’ve been working together with
you over the past several months to get your feedback on this release, and also
to make sure your apps are ready for the users who will run them on Nougat
devices.

What’s inside Nougat

Android Nougat reflects input from thousands of fans and developers like you,
all around the world. There are over 250 major features in Android Nougat,
including VR Mode in
Android. We’ve worked at all levels of the Android stack in
Nougat — from how the operating system reads sensor data to how it sends pixels to
the display — to make it especially built to provide high quality mobile VR
experiences.

Plus, Nougat brings a number of new features to help make Android
more powerful, more productive and more secure. It introduces a brand new
href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog#jit_aot?utm_source=anddev&utm_medium=blog">JIT/AOT
compiler to improve software performance, make app installs faster,
and take up less storage. It also adds platform support for href="https://developer.android.com/ndk/guides/graphics/index.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog">Vulkan,
a low-overhead, cross-platform API for high-performance, 3D graphics. href="http://developer.android.com/guide/topics/ui/multi-window.html?utm_source=anddev&utm_medium=blog">Multi-Window
support lets users run two apps at the same time, and href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html?utm_campaign=android_launch_android7.0nougat_082216&utm_source=anddev&utm_medium=blog#direct?utm_source=anddev&utm_medium=blog">Direct
Reply so users can reply directly to notifications without having
to open the app. As always, Android is built with powerful layers of security
and encryption to keep your private data private, so Nougat brings new features
like File-based encryption, seamless updates, and href="https://developer.android.com/training/articles/direct-boot.html?utm_source=anddev&utm_medium=blog">Direct
Boot.

You can find all of the href="https://developer.android.com/about/versions/nougat/index.html?utm_source=anddev&utm_medium=blog">Nougat
developer resources here, including details on behavior changes and new
features you can use in your apps. An overview of what's new for developers is
available href="https://developer.android.com/about/versions/nougat/android-7.0.html?utm_source=anddev&utm_medium=blog">here, and
you can explore all of the new user features in Nougat href="https://www.android.com/versions/nougat-7-0/">here.

Multi-window mode in Android Nougat

The next wave of users

Starting today and rolling out over the next several weeks, the Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, Nexus Player,
Pixel C, and General Mobile 4G (Android One) will get an over-the-air software
update to Android 7.0 Nougat. Devices enrolled in the href="https://www.google.com/android/beta">Android Beta Program will also
receive this final version.

And there are many tasty devices coming from our partners running Android Nougat, including the upcoming href="http://www.lgnewsroom.com/2016/08/new-lg-v20-to-be-worlds-first-phone-to-launch-with-android-7-0-nougat/">LG
V20, which will be the first new smartphone that ships with Android Nougat, right out of the box.

With all of these new devices beginning to run Nougat, now is the time to
publish your app updates to Google Play. We recommend compiling against, and
ideally targeting, API 24. If you’re still testing some last minute changes, a
great strategy to do this is using href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Google
Play’s beta testing feature to get early feedback from a small group of
users — including those using Android 7.0 Nougat — and then doing a staged
rollout as you release the updated app to all users.

What’s next for Nougat?

We’re moving Nougat into a new regular maintenance schedule over the coming
quarters. In fact, we’ve already started work on the first Nougat maintenance
release, that will bring continued refinements and polish, and we’re planning to
bring that to you this fall as a developer preview. Stay tuned!

We’ll be closing open bugs logged against Developer Preview builds soon, but
please keep the feedback coming! If you still see an issue that you filed in the
preview tracker, just href="https://source.android.com/source/report-bugs.html">file a new issue
against Android 7.0 in the AOSP issue tracker.

Thanks for being part of the preview, which we shared earlier this year with href="https://medium.com/google-developers/n-as-in-so-early-it-s-not-named-yet-f06bbde8c390#.uqdm4w8hi">an
eye towards giving everyone the opportunity to make the next release of
Android stronger. Your continued feedback has been extremely beneficial in
shaping this final release, not just for users, but for the entire Android
ecosystem.

Posted by Rich Hyndman, Android Developer Advocate

With the growth of the Internet of Things, connecting Android applications to
Wi-Fi enabled devices is becoming more and more common. Whether you’re building
an app for a remote viewfinder, to set up a connected light bulb, or to control
a quadcopter, if it’s Wi-Fi based you will need to connect to a hotspot that may
not have Internet connectivity.

From Lollipop onwards the OS became a little more intelligent, allowing multiple
network connections and not routing data to networks that don’t have Internet
connectivity. That’s very useful for users as they don’t lose connectivity when
they’re near Wi-Fis with captive portals. Data routing APIs were added for
developers, so you can ensure that only the appropriate app traffic is routed
over the Wi-Fi connection to the external device.

To make the APIs easier to understand, it is good to know that there are 3 sets
of networks available to developers:

• WiFiManager#startScan returns a list of available Wi-Fi networks. They are
  primarily identified by SSID.
  
• WiFiManager#getConfiguredNetworks returns a list of the Wi-Fi networks
  configured on the device, also indexed by SSID, but they are not necessarily
  currently available.
  
• ConnectivityManager#getAllNetworks returns a list of networks that are being
  interacted with by the phone. This is necessary as from Lollipop onwards a
  device may be connected to multiple networks at once, Wi-Fi, LTE, Bluetooth,
  etc… The current state of each is available by calling href="https://developer.android.com/reference/android/net/ConnectivityManager.html#getNetworkInfo(android.net.Network)">ConnectivityManager#getNetworkInfo
  and is identified by a network ID.

In all versions of Android you start by scanning for available Wi-Fi networks
with href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#startScan()">WiFiManager#startScan,
iterate through the href="https://developer.android.com/reference/android/net/wifi/ScanResult.html">ScanResults
looking for the SSID of your external Wi-Fi device. Once you’ve found it you can
check if it is already a configured network using href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#getConfiguredNetworks()">WifiManager#getConfiguredNetworks
and iterating through the href="https://developer.android.com/reference/android/net/wifi/WifiConfiguration.html">WifiConfigurations
returned, matching on SSID. It’s worth noting that the SSIDs of the configured
networks are enclosed in double quotes, whilst the SSIDs returned in href="https://developer.android.com/reference/android/net/wifi/ScanResult.html">ScanResults
are not.

If your network is configured you can obtain the network ID from the
WifiConfiguration object. Otherwise you can configure it using href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#addNetwork(android.net.wifi.WifiConfiguration)">WifiManager#addNetwork
and keep track of the network id that is returned.

To connect to the Wi-Fi network, register a BroadcastReceiver that listens for
href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#NETWORK_STATE_CHANGED_ACTION">WifiManager.NETWORK_STATE_CHANGED_ACTION
and then call href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#enableNetwork(int,%20boolean)">WifiManager.enableNetwork
(int netId, boolean disableOthers), passing in your network ID. The
enableNetwork call disables all the other Wi-Fi access points for the next scan,
locates the one you’ve requested and connects to it. When you receive the
network broadcasts you can check with href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#getConnectionInfo()">WifiManager#getConnectionInfo
that you’re successfully connected to the correct network. But, on Lollipop and
above, if that network doesn’t have internet connectivity network, requests will
not be routed to it.

Routing network requests

To direct all the network requests from your app to an external Wi-Fi device,
call href="https://developer.android.com/reference/android/net/ConnectivityManager.html#setProcessDefaultNetwork(android.net.Network)">ConnectivityManager#setProcessDefaultNetwork
on Lollipop devices, and on Marshmallow call href="https://developer.android.com/reference/android/net/ConnectivityManager.html#bindProcessToNetwork(android.net.Network)">ConnectivityManager#bindProcessToNetwork
instead, which is a direct API replacement. Note that these calls require
android.permission.INTERNET; otherwise they will just return false.

Alternatively, if you’d like to route some of your app traffic to the Wi-Fi
device and some to the Internet over the mobile network:

• For HTTP requests you can use href="https://developer.android.com/reference/android/net/Network.html#openConnection(java.net.URL)">Network#openConnection(java.net.URL),
  directly routing your request to this network.
  
• For low-level socket communication, open a socket and call href="https://developer.android.com/reference/android/net/Network.html#bindSocket(java.net.Socket)">Network#bindSocket(java.net.Socket),
  or alternatively use href="https://developer.android.com/reference/android/net/Network.html#getSocketFactory()">Network#getSocketFactory.

Now you can keep your users connected whilst they benefit from your innovative
Wi-Fi enabled products.

Posted by Sami Tolvanen, Software Engineer

Overview

Android uses multiple layers of protection to keep users safe. One of these
layers is verified
boot, which improves security by using cryptographic integrity checking to
detect changes to the operating system. Android has href="https://g.co/ABH">alerted about system integrity since Marshmallow,
but starting with devices first shipping with Android 7.0, we require verified
boot to be strictly enforcing. This means that a device with a corrupt boot
image or verified partition will not boot or will boot in a limited capacity
with user consent. Such strict checking, though, means that non-malicious data
corruption, which previously would be less visible, could now start affecting
process functionality more.

By default, Android verifies large partitions using the dm-verity kernel driver,
which divides the partition into 4 KiB blocks and verifies each block when read,
against a signed hash tree. A detected single byte corruption will therefore
result in an entire block becoming inaccessible when dm-verity is in enforcing
mode, leading to the kernel returning EIO errors to userspace on verified
partition data access.

This post describes our work in improving dm-verity robustness by introducing
forward error correction (FEC), and explains how this allowed us to make the
operating system more resistant to data corruption. These improvements are
available to any device running Android 7.0 and this post reflects the default
implementation in AOSP that we ship on our Nexus devices.

Error-correcting codes

Using forward error correction, we can detect and correct errors in source data
by shipping redundant encoding data generated using an error-correcting code.
The exact number of errors that can be corrected depends on the code used and
the amount of space allocated for the encoding data.

href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">Reed-Solomon
is one of the most commonly used error-correcting code families, and is readily
available in the Linux kernel, which makes it an obvious candidate for
dm-verity. These codes can correct up to ⌊t/2⌋ unknown errors and up to
t known errors, also called href="https://en.wikipedia.org/wiki/Erasure_code">erasures, when t
encoding symbols are added.

A typical RS(255, 223) code that generates 32 bytes of encoding data for every
223 bytes of source data can correct up to 16 unknown errors in each 255 byte
block. However, using this code results in ~15% space overhead, which is
unacceptable for mobile devices with limited storage. We can decrease the space
overhead by sacrificing error correction capabilities. An RS(255, 253) code can
correct only one unknown error, but also has an overhead of only 0.8%.

An additional complication is that block-based storage corruption often occurs
for an entire block and sometimes spans multiple consecutive blocks. Because
Reed-Solomon is only able to recover from a limited number of corrupted bytes
within relatively short encoded blocks, a naive implementation is not going to
be very effective without a huge space overhead.

Recovering from consecutive corrupted blocks

In the changes we made to href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a739ff3f543afbb4a041c16cd0182c8e8d366e70">dm-verity
for Android 7.0, we used a technique called interleaving to allow us to recover
not only from a loss of an entire 4 KiB source block, but several consecutive
blocks, while significantly reducing the space overhead required to achieve
usable error correction capabilities compared to the naive implementation.

Efficient interleaving means mapping each byte in a block to a separate
Reed-Solomon code, with each code covering N bytes across the corresponding N
source blocks. A trivial interleaving where each code covers a consecutive
sequence of N blocks already makes it possible for us to recover from the
corruption of up to (255 - N) / 2 blocks, which for RS(255, 223) would
mean 64 KiB, for example.

An even better solution is to maximize the distance between the bytes covered by
the same code by spreading each code over the entire partition, thereby
increasing the maximum number of consecutive corrupted blocks an RS(255, N) code
can handle on a partition consisting of T blocks to ⌈T/N⌉ × (255 -
N) / 2.

An additional benefit of interleaving, when combined with the integrity
verification already performed by dm-verity, is that we can tell exactly where
the errors are in each code. Because each byte of the code covers a different
source block—and we can verify the integrity of each block using the existing
dm-verity metadata—we know which of the bytes contain errors. Being able to
pinpoint erasure locations allows us to effectively double our error correction
performance to at most ⌈T/N⌉ × (255 - N) consecutive blocks.

For a ~2 GiB partition with 524256 4 KiB blocks and RS(255, 253), the maximum
distance between the bytes of a single code is 2073 blocks. Because each code
can recover from two erasures, using this method of interleaving allows us to
recover from up to 4146 consecutive corrupted blocks (~16 MiB). Of course, if
the encoding data itself gets corrupted or we lose more than two of the blocks
covered by any single code, we cannot recover anymore.

While making error correction feasible for block-based storage, interleaving
does have the side effect of making decoding slower, because instead of reading
a single block, we need to read multiple blocks spread across the partition to
recover from an error. Fortunately, this is not a huge issue when combined with
dm-verity and solid-state storage as we only need to resort to decoding if a
block is actually corrupted, which still is rather rare, and random access reads
are relatively fast even if we have to correct errors.

Conclusion

Strictly enforced verified boot improves security, but can also reduce
reliability by increasing the impact of disk corruption that may occur on
devices due to software bugs or hardware issues.

The new error correction feature we developed for dm-verity makes it possible
for devices to recover from the loss of up to 16-24 MiB of consecutive blocks
anywhere on a typical 2-3 GiB system partition with only 0.8% space overhead and
no performance impact unless corruption is detected. This improves the security
and reliability of devices running Android 7.0.

Posted by Dave Burke, VP of Engineering

As we close in on the public rollout of href="https://developer.android.com/preview/index.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">Android 7.0 Nougat
to devices later this summer, today we’re releasing Developer Preview
5, the last milestone of this preview series. href="http://android-developers.blogspot.com/2016/06/android-n-apis-are-now-final.html">Last
month’s Developer Preview included the final APIs for Nougat; this preview
gives developers the near-final system updates for all of the supported preview
devices, helping you get your app ready for consumers.

Here’s a quick rundown of what’s included in the final Developer Preview of
Nougat:

• System images for Nexus and other preview devices
  
• An emulator that you can use for doing the final testing of your apps to
  make sure they’re ready
  
• The final N APIs (API level 24) and latest system behaviors and UI
  
• The latest bug fixes and optimizations across the system and in preinstalled
  apps

Working with this latest Developer Preview, you should make sure your app
handles all of the href="https://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">system
behavior changes in Android N, like Doze on the Go, background
optimizations, screen zoom, permissions changes, and more. Plus, you can take
advantage of href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">new developer
features in Android N such as href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#multi-window_support">Multi-window
support, Direct Reply and other href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#notification_enhancements">notifications
enhancements, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#direct_boot">Direct
boot, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#emoji">new
emojis and more.

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

After testing your apps with Developer Preview 5 you should publish the updates
to Google Play soon. We recommend compiling against, and optionally targeting,
API 24 and then publishing to your alpha, beta, or production channels in the
Google Play Developer Console. A great strategy to do this is using href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Google
Play’s beta testing feature to get early feedback from a small group of
users -- including Developer Preview users — and then doing a staged rollout as
you release the updated app to all users.

How to get Developer Preview 5

If you are already enrolled in the Android
Beta program, your devices will get the Developer Preview 5 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 href="https://android.com/beta">android.com/beta and opt-in your eligible
Android phone or tablet -- you’ll soon receive this preview update over-the-air.
As always, you can also download and href="https://developer.android.com/preview/download.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog#flash">flash
this update manually. The Nougat 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.

Thanks so much for all of your feedback so far. Please continue to share
feedback or requests either in the href="https://code.google.com/p/android/issues/list?can=2&q=label%3ADevPreview-N">N
Developer Preview issue tracker, href="https://plus.google.com/communities/103655397235276743411">N Preview
Developer community, or href="https://plus.google.com/communities/106765800802768335079">Android Beta
community as we work towards the consumer release later this summer. Android
Nougat is almost here!

Also, the Android engineering team will host a Reddit AMA on r/androiddev to
answer all your technical questions about the platform tomorrow, July 19
from 12-2 PM (Pacific Time). We look forward to addressing your
questions!

Posted by Dimitry Ivanov & Elliott Hughes, Software Engineers

As documented in the href="https://developer.android.com/preview/behavior-changes.html#ndk">Android N
behavioral changes, to protect Android users and apps from unforeseen
crashes, Android N will restrict which libraries your C/C++ code can link
against at runtime. As a result, if your app uses any private symbols from
platform libraries, you will need to update it to either use the public NDK APIs
or to include its own copy of those libraries. Some libraries are public: the
NDK exposes libandroid, libc, libcamera2ndk, libdl,
libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES,
libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are
private, and Android N only allows access to them for platform HALs, system
daemons, and the like. If you aren’t sure whether your app uses private
libraries, you can immediately check it for warnings on the N Developer Preview.

We’re making this change because it’s painful for users when their apps stop
working after a platform update. Whether they blame the app developer or the
platform, everybody loses. Users should have a consistent app experience across
updates, and developers shouldn’t have to make emergency app updates to handle
platform changes. For that reason, we recommend against using private C/C++
symbols. Private symbols aren’t tested as part of the Compatibility Test Suite
(CTS) that all Android devices must pass. They may not exist, or they may behave
differently. This makes apps that use them more likely to fail on specific
devices, or on future releases — as many developers found when Android 6.0
Marshmallow switched from OpenSSL to BoringSSL.

You may be surprised that there’s no STL in the list of NDK libraries. The three
STL implementations included in the NDK — the LLVM libc++, the GNU STL, and
libstlport — are intended to be bundled with your app, either by statically
linking into your library, or by inclusion as a separate shared library. In the
past, some developers have assumed that they didn’t need to package the library
because the OS itself had a copy. This assumption is incorrect: a particular STL
implementation may disappear (as was the case with stlport, which was removed in
Marshmallow), may never have been available (as is the case with the GNU STL),
or it may change in ABI incompatible ways (as is the case with the LLVM libc++).

In order to reduce the user impact of this transition, we’ve identified a set of
libraries that see significant use from Google Play’s most-installed apps, and
that are feasible for us to support in the short term (including
libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so). For legacy
code in N, we will temporarily support these libraries in order to give you more
time to transition. Note that we don't intend to continue this support in any
future Android platform release, so if you see a warning that means your code
will not work in a future release — please fix it now!

Table 1. What to expect if your app is linking against private native libraries.

What behavior will I see?

Please test your app during the N Previews.

N Preview behavior

• All public NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
  libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
  libvulkan, and libz), plus libraries that are part of your app are accessible.
  
• For all other libraries you’ll see a warning in logcat and a toast on the
  display. This will happen only if your app’s targetSdkVersion is less than N. If
  you change your manifest to target N, loading will fail: Java’s
  System.loadLibrary will throw, and C/C++’s dlopen(3) will return NULL.

Test your apps on the Developer Preview — if you see a toast like this one, your app is accessing private native APIs. Please fix your code soon!

N Final Release behavior

• All NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
  libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
  libvulkan, and libz), plus libraries that are part of your app are accessible.
  
• For the temporarily accessible libraries (such as libandroid_runtime.so,
  libcutils.so, libcrypto.so, and libssl.so), you’ll see a warning in logcat for
  all API levels before N, but loading will fail if you update your app so that
  its targetSdkVersion is N or later.
  
• Attempts to load any other libraries will fail in the final release of
  Android N, even if your app is targeting a pre-N platform version.

Future platform behavior

• In O, all access to the temporarily accessible libraries will be removed.
  As a result, you should plan to update your app regardless of your
  targetSdkVersion prior to O. If you believe there is missing functionality from
  the NDK API that will make it impossible for you to transition off a temporarily
  accessible library, please file a bug here.

What do the errors look like?

Here’s some example logcat output from an app that hasn’t bumped its target SDK
version (and so the restriction isn’t fully enforced because this is only the
developer preview):

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

This is telling you that your library “libapplib.so” refers to the library
“libandroid_runtime.so”, which is a private library.

When Android N ships, or if you set your target SDK version to N now, you’ll see
something like this if you try to use System.loadLibrary from Java:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so"
is not accessible for the namespace "classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

If you’re using href="http://man7.org/linux/man-pages/man3/dlopen.3.html">dlopen(3) from
C/C++ you’ll get a NULL return and href="http://man7.org/linux/man-pages/man3/dlerror.3.html">dlerror(3) will
return the same “dlopen failed...” string as shown above.

For more information about how to check if your app is using private symbols,
see the FAQ on developer.android.com.

Posted by Dave Burke, VP of Engineering

As we put the finishing touches on the href="https://developer.android.com/preview/index.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">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 href="https://android.com/beta">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 href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">behavior
changes. For details on how to setup your app with the final SDK, see href="https://developer.android.com/preview/setup-sdk.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Set up the
Preview. For details on API level 24 check out the href="https://developer.android.com/sdk/api_diff/24/changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API diffs
and the updated href="https://developer.android.com/reference/packages.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API reference,
now hosted online.

Along with the Android N final SDK, we’ve also updated the href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/preview/download.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog#flash">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.

Thanks so much for all of your feedback so far. Please continue to share
feedback or requests either in the href="https://code.google.com/p/android/issues/list?can=2&q=label%3ADevPreview-N">N
Developer Preview issue tracker, href="https://plus.google.com/communities/103655397235276743411">N
Preview Developer community, or href="https://plus.google.com/communities/106765800802768335079">Android Beta
community as we work towards the consumer release later this summer. We’re
looking forward to seeing your apps on Android N!