Test on Android 7.1 Developer Preview in Firebase Test Lab

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.

Prepare your app for API level 25, then go to the Firebase Test Lab console to run your first test.

Happy testing.

CMake and ndk-build support in Android Studio 2.2

In addition to supporting the experimental Gradle plugin, Android Studio 2.2 enables you to build C/C++ components of Android projects using CMake and ndk-build.

The Android Studio team plans to continue to support the experimental Gradle plugin. This will eventually replace the current Gradle plugin, providing additional tightly-integrated benefits to C/C++ developers such as smarter dependency management. So if you're interested in someday having the smartest possible interface between your IDE and your build system, you shouldn't ignore the experimental plugin.

CMake and ndk-build are useful alternatives to Gradle in several cases:

• Projects that are already using CMake or ndk-build, such as legacy Eclipse ndk projects
• Projects that are unable to assume the risk of using an experimental plugin for their C/C++ builds
• Projects that will share a C/C++ build system across multiple platforms
• C/C++ projects that need to use advanced features currently unavailable in experimental Gradle such as NEON support

For new projects, we recommend using CMake or experimental Gradle. For new Android projects with limited C++, we recommend trying the experimental Gradle plugin. For projects with substantial amounts of C++, or where you want the maximally stable build configuration, we recommend using a CMake build. Android Studio intends CMake to be a permanently supported solution.

While we think that there are substantial advantages to having a single build system able to handle all parts of an Android application, stabilizing the experimental plugin is not an option for us because it relies on Gradle APIs that are still a work in progress. Until the Gradle APIs are stabilized, the experimental plugin will keep changing, particularly in its Domain Specific Language, and will be strictly tied to a very specific version of Gradle itself.

Note that the the old, undocumented ndkCompile integration is deprecated. If you are using it, you need to move away from it as we'll remove it completely in the near future. We recommend migrating to gradle+cmake via our migration guide.

Migrating from Eclipse to Android Studio

We no longer support the Eclipse ADT. To get started migrating, download and install Android Studio. For most projects, migration is as simple as importing your existing Eclipse ADT projects in Android Studio with the File → New→ Import Project menu option. For more details on the migration process, check out the migration guide.

Understanding APK packaging in Android Studio 2.2

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.

Readfeed graduates from Google Play’s Early Access beta program & offers some learnings

Readfeed was created to help book lovers around the world share and discuss their favorite reads with each other more easily. Today, we are excited to officially launch the Readfeed app on Google Play. As one of the first online book clubs available only on Android devices, Readfeed lets you create your virtual bookshelf by adding books to custom lists, track and share your reading progress with community members, and see what books others are reading and talking about.

Readfeed has come a long way since we first released the app as beta in Google Play's Early Access program. As one of the first graduates of the beta program, we were able to solicit feature requests, identify bugs, locate new and optimize existing target markets, as well as build a sizable reader community. This allowed Readfeed to deliver the best possible experience right out of the gate.

As a guest on this blog, we thought it would be helpful to share some important best practices that we learned from the Early Access program to improve your products and scale your user base.

Harnessing Feedback Loops

One of the core principles underlying the construction of any successful product is setting up an effective feedback loop between users and product creators. Google Play Early access does this automatically. Users show up (sometimes seemingly out of nowhere), install the app, and leave feedback in the Beta Feedback section of the developer console. We can then reply in that section or take the conversation into an email, address the issue, and email users when it's addressed. Many improvements to Readfeed have been made as a direct result of this process.

Identifying New Target Markets

One major benefit of Early Access was that it gave us immediate access to a worldwide audience of readers. We were able to quickly assess the different book-related markets that existed based on user feedback and interviews done through email. Since launched in beta, over 1000 people have asked to read free books. Apparently this need exists in third-world countries and we plan to add this functionality in a future release.

Identifying Bugs

Bugs plague any app in its early stages. Because of the variety of devices that Early Access users have, ranging from Android 4.2 rooted devices to the latest Nexus phones, we were able to identify bugs very quickly. For instance, on Android 4.2 there was a recurrent crash which was tough for me to identify with my own devices. After one user emailed me about it, I was able to gather enough information to resolve the issue and put out an update immediately.

Identifying New Features

Google Play Early Access made it a lot easier to determine what to do next. When about 10 people request a feature, we know it's immediately important and put it in the app. One feature that came directly from Early Access feedback was the ability to rate books without leaving a review.

Community Building

Early Access has allowed us to start building a community. For instance, a Software tester from the UK who likes books sent me a detailed analysis of all of Readfeed's bugs. Also, we've witnessed many people take the initiative and answer others' questions about the app. Because of the critical mass that Google Play Early Access helps you build, it's easy for communities to form and start sharing information with each other.

Android Developer Stories: drupe and Noom expand globally by localising their apps on Google Play

Interested in growing your app on a global scale? See how two app developers localized their apps in unique ways to drive revenue and user engagement.

drupe

drupe is a communications app that utilizes the openness of android to build a truly native experience delivering highly contextual recommendations to their users across the world.

Key to achieving international growth, drupe has translated their app in 17 languages, and their store listing page in 28 languages. This led to an increase in conversion and retention rates. Additionally, when entering India, the team noticed several user reviews requesting integration with a specific messaging app widely used in the Indian market. Through a combination of this integration, adding Hindi language translation, and other new features, drupe saw improved performance. In six months, daily active users increased 300%, and actions per average daily user increased 25% in the Indian market.

Noom

Noom is a health & fitness app that has achieved an 80% increase in international revenue growth on Android over the past three years by localizing their app with unique cultural behaviors, cuisines, and local-market coaches.

In addition to translating their app and store listing page, Noom conducted extensive analysis to determine the right financial model tailored to each international market. This included evaluation of their competitive landscape and local health and wellness spending behavior, in addition to running pricing experiments to determine the optimal offering between subscriptions, IAPs, or a premium app.

Use the Localization Checklist to learn more about tailoring your app for different markets to drive installs and revenue, and to create a better overall user experience. 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.

Coming soon: Android 7.1 Developer Preview

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.

Tips to help you stay on the right side of Google Play policy

Today we have released a new video ‘10 tips to stay on the right side of Google Play policy’. The video provides 10 best practices to help you develop and launch apps and games which follow Google Play’s Developer Program Policies.

It accompanies the recently published News video series and is part of our 10 tips for success on Google Play video series.

Watch the video to learn how to review your app, to ensure you have appropriate content and the rights to use it, how to handle user data, and more. Also, find out how to stay up to date with policy updates and get support from our policy team.

Keeping the Play Store trusted: fighting fraud and spam installs

We strive to continuously make Google Play the best platform for enjoying and discovering the most innovative and trusted apps. Today we are announcing additional enhancements to protect the integrity of the store.

Our teams work every day to improve the quality of our discovery systems. These content discovery systems ensure that users can find and download apps they will love. From time to time, we observe instances of developers attempting to manipulate the placement of their apps through illegitimate means like fraudulent installs, fake reviews, and incentivized ratings. These attempts not only violate the Google Play Developer Policy, but also harm our community of developers by hindering their chances of being discovered or recommended through our systems. Ultimately, they put the end users at risk of making wrong decisions based on inaccurate, unauthentic information.

Today we are rolling out improved detection and filtering systems to combat such manipulation attempts. If an install is conducted with the intention to manipulate an app's placement on Google Play, our systems will detect and filter it. Furthermore, developers who continue to exhibit such behaviors could have their apps taken down from Google Play.

In the vast majority of cases, no action will be needed. If you are asking someone else to promote your app (e.g., third-party marketing agency), we advise you to make sure that the promotion is based on legitimate practices. In case of questions, please check out the Developer Support Resources.

These important changes will help protect the integrity of Google Play, our developer community, and ultimately our end user. Thank you for your support in building the world's most trusted store for apps and games!

Android Wear 2.0 Developer Preview 3: Play Store and More

Today we’re launching the third developer preview of Android Wear 2.0 with a big new addition: Google Play on Android Wear. The Play Store app makes it easy for users to find and install apps directly on the watch, helping developers like you reach more users.

Play Store features

With Play Store for Android Wear, users can browse recommended apps in the home view and search for apps using voice, keyboard, handwriting, and recommended queries, so they can find apps more easily. Users can switch between multiple accounts, be part of alpha and beta tests, and update or uninstall apps in the “My apps” view on their watch, so they can manage apps more easily. Perhaps the coolest feature: If users want an app on their watch but not on their phone, they can install only the watch app. In fact, in Android Wear 2.0, phone apps are no longer necessary. You can now build and publish watch-only apps for users to discover on Google Play.

Why an on-watch store?

We asked developers like you what you wanted most out of Android Wear, and you told us you wanted to make it easier for users to discover apps. So we ran studies with users to find out where they expected and wanted to discover apps––and they repeatedly looked for and asked for a way to discover apps right on the watch itself. Along with improvements to app discovery on the phone and web, the Play Store on the watch helps users find apps right where they need them.

Publish your apps

To make your apps available on Play Store for Android Wear, just follow these steps. You’ll need to make sure your Android Wear 2.0 apps set minSdkVersion to 24 or higher, use the runtime permissions model, and are uploaded via multi-APK using the Play Developer Console. If your app supports Android Wear 1.0, the developer guide also covers the use of product flavors in Gradle.

Download the New Android Wear companion app

To set up Developer Preview 3, you’ll need to install a beta version of the Android Wear app on your phone, flash your watch to the latest preview release, and use the phone app to add a Google Account to your watch. These steps are detailed in Download and Test with a Device. If you don’t have a watch to test on, you can use the emulator as well.

Other additions in Developer Preview 3

Developer Preview 3 also includes:

• Complications improvements: Starting with Developer Preview 3, watch face developers will need to request RECEIVE_COMPLICATION_DATA permission before the watch face can receive complication data. We have added ComplicationHelperActivity to make this easier. In addition, watch face developers can now set default complications, including a selection of system data complications which do not require special permission (e.g. battery level and step count), as well as data providers that have whitelisted the watch face. Lastly, there are behavior changes related to ComplicationData to 1) help better differentiate various scenarios leading to “empty data” and 2) ease development by returning a default value for fields not supported by a complication type instead of throwing a runtime exception.
• New WearableRecyclerView: This new UI component helps developers display and manipulate vertical lists of items while optimizing for round displays.
• Inline Action for Notifications: A new API makes it easy to take action on a notification right from the stream. Developers can specify which action is displayed inline at the bottom of the notification by calling setHintDisplayActionInline:

  NotificationCompat.Action replyAction =
      new NotificationCompat.Action.Builder(R.drawable.ic_message_white_24dp,
              "Reply", replyPendingIntent)
              .addRemoteInput(remoteInput)
              .extend(new NotificationCompat.Action.WearableExtender()
                      .setHintDisplayActionInline(true))
              .build(); 

• Smart Reply: Android Wear now generates Smart Reply responses for MessagingStyle notifications. Smart Reply responses are generated by an entirely on-watch machine learning model using the context provided by theMessagingStyle notification, and no data is uploaded to the cloud to generate the responses.
• And much more: Read about the complete list of changes in the Android Wear developer preview release notes.
  
  TimelineWe’ve gotten tons of great feedback from the developer community about Android Wear 2.0––thank you! We’ve decided to continue the preview program into early 2017, at which point the first watches will receive Android Wear 2.0. Please keep the feedback coming by filing bugs or posting in our Android Wear Developers community, and stay tuned for Android Wear Developer Preview 4.

Extending Web Technology with Android

Paper Planes started as a simple thought - “What if you could throw a paper plane from one screen to another?”

The heart of our concept was to bring people together from all over the world, using the power of the web - an instant connection to one another. Modern web technology, specifically JavaScript and WebGL, powered the experience on every screen.

Paper Planes was initially featured at Google I/O 2016, connecting attendees and outside viewers for 30 minutes preceding the keynote. For the public launch on International Peace Day 2016, we created an Android Experiment, which is also featured on Google Play, to augment the existing web technology with native Android Nougat features such as rich notifications when a plane is caught elsewhere in the world.

Introduction

Users create and fold their own plane while adding a stamp that is pre-filled with their location. A simple throwing gesture launches the plane into the virtual world. Users visiting the desktop website would see their planes flying into the screen.

Later, users can check back and see where their planes have been caught around the world. Each stamp on the plane reads like a passport, and a 3D Earth highlights flightpath and distance travelled.

In addition to making their own planes, users can gesture their phone like a net to catch a plane that has been thrown from elsewhere and pinch to open it, revealing where it has visited. Then they can add their own stamp, and throw it back into the flock.

WebView

We developed Paper Planes to work across devices ranging from the 50-foot screen on stage at Google I/O to desktop and mobile using the latest in web technology.

WebGL

From the stylized low-poly Earth to the flocking planes, WebGL is used to render the 3D elements that power the experience. We wrote custom GLSL shaders to light the Earth and morph targets to animate the paper as the user pinches to open or close.

WebSockets

When a user “throws” a plane a message is sent over websockets to the back-end servers where it is relayed to all desktop computers to visualize the plane taking off.

WebWorkers

The plane flocking simulation is calculated across multiple threads using WebWorkers that calculate the position of each plane and relay that information back to the main thread to be rendered by WebGL.

To create an experience that works great across platforms, we extended the web with native Android code. This enabled us to utilize the deep integration of Chromium within Android to make the view layer of the application with the web code that already existed, while adding deeper integration with the OS such as rich notifications and background services.

If you’re interested in learning more about how to bridge WebView and Java code, check out this GitHub repo for a tutorial.

Notifications

Firebase Cloud Messaging (FCM) was used to send push notifications to the Android app. When a user’s plane has been caught and thrown by someone else, a notification showing how many cities and miles it has travelled is sent to the device of the plane’s creator via FCM. Outgoing notifications are managed to ensure they are not sent too frequently to a device.

Background Service

We implemented a background service to run once a day which checks against local storage to determine when a user last visited the app. If the user hasn’t visited in over two weeks, the app sends a notification to invite the user back into the app to create a new plane.

The Communication Network

Our application runs on a network of servers on Google Cloud Platform. We used built-in geocoding headers to get approximate geographic locations for stamps and Socket.IO to connect all devices over WebSockets.

Users connect to the server nearest them, which relays messages to a single main server as well as to any desktop computers viewing the experience in that region.

Moving forward

This approach worked extremely well for us, enabling an experience that was smooth and captivating across platforms and form factors, connecting people from all over the world. Extending the web with native capabilities has proven to be a valuable avenue to deliver high quality experiences going forward. You can learn even more on the Android Experimentswebsite.

Android Studio 2.2

Android Studio 2.2 is available to 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 code completion to help you add Android platform features like Multi-Window support, Quick Settings API, or the redesigned Notifications, and of course, the built-in 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 ConstraintLayoutintegrates 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. Learn more.

Layout Editor

• 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. Learn more.

ConstraintLayout

Develop

• Improved C++ Support: You can now use 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. Learn more.

C++ Code Editing & CMake Support

• Samples Browser: Referencing 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.

Sample Code Menu

Build

• Instant Run Improvements: Introduced in Android Studio 2.0, 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 Android Studio 2.2 release notes.

Enable Instant Run

• APK Analyzer: Easily inspect the contents of your APKs to understand the size contribution of each component. This feature can be helpful when debugging multi-dex issues. Plus, with the APK Analyzer you can compare two versions of an APK. Learn more.

APK Analyzer

• 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. Learn more.

Build Cache Setting

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 Android Sensors such as Accelerometer, Ambient Temperature, Magnetometer and more. Learn more.

Android Emulator Virtual Sensors

• Espresso Test Recorder (Beta): The Espresso Test Recorder lets you easily create UI tests by recording interactions with your app; it then outputs the 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 Firebase Test Lab for Android. Learn more.

Espresso Test Recorder

• 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.Lean more.

GPU Debugger

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

Design Layout Editor Constraint Layout Layout Inspector (Experimental) PSD File Support in Vector Asset Studio Develop Firebase Plugin Updated Code Analysis & Lint checks Enhanced accessibility support Improved C++ Support Edit & Debugging IntelliJ 2016.1.3 platform update Samples Browser Improved Font Rendering

Build Jack Compiler Improvements Java 8 Language Support C++ ndk-build or CMake Merged Manifest Viewer Build cache (Experimental) OpenJDK Support Instant Run Improvements Test Espresso Test Recorder (Beta) APK Analyzer GPU Debugger (Beta) Virtual Sensors in the Android Emulator

Learn more about Android Studio 2.2 by reviewing the release notes and the 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 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

Taking the final wrapper off of 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 JIT/AOT compiler to improve software performance, make app installs faster, and take up less storage. It also adds platform support for Vulkan, a low-overhead, cross-platform API for high-performance, 3D graphics. Multi-Window support lets users run two apps at the same time, and 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 Direct Boot.

You can find all of the 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 here, and you can explore all of the new user features in Nougat 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 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 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 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 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 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.