Tag Archives: Android Developer

Introducing Android Instant Apps

Posted by Suresh Ganapathy, Product Manager

 Developers have built amazing Android apps. They use your mobile device to the fullest, including the camera, GPS, and sensors to connect to the real world. They’re beautiful and immersive, with Material Design and smooth animations running at 60 frames per second. They use access to identity and payments to create seamless experiences.

But developers tell us they wish they could bring users into their apps more quickly and easily. With the web, you can click on a link and land on a web page — it takes one click and just a few seconds. It should be easier for users to access a wider range of apps, and for developers to reach more people.

So, we asked ourselves: How do we make it possible for people to access a wider range of apps, seamlessly? How do we help developers reach more people? And how do we do that while giving developers access to the range of capabilities and experiences that Android apps provide?

Today we’re sharing a preview of a new project that we think will change how people experience Android apps. We call it Android Instant Apps, and it evolves Android apps to be able to run instantly, without requiring installation. With Instant Apps, a tap on a URL can open right in an Android app, even if the user doesn’t have that app installed.

As a developer, you won’t need to build a new, separate app. It’s the same Android APIs, the same project, the same source code. You’ll simply update your existing Android app to take advantage of Instant Apps functionality. In fact, it can take less than a day to get up and running for some developers, though the effort involved will vary depending on how your app is structured. You modularize your app, and Google Play downloads only the parts that are needed, on the fly. And when you do upgrade, your app will be available to more than a billion users on Android devices going back to Jelly Bean.

This is a big change, so it's going to take some time. We’ve been working with a small set of partners to help refine the experience, including developers like BuzzFeed, B&H Photo, Medium, Hotel Tonight, Zumper and Disney. We’ll be gradually expanding access for developers and bringing Instant Apps to users later this year.
B&H Photo
(via Google Search)
BuzzFeedVideo
(via a shared link)
Park and Pay (example)
(via NFC)

If you’re interested in learning more about Android Instant Apps, please check out the Android developers website, where you can sign up for updates as they become available. We can’t wait to see what you build when your app is just a tap away.

Designing for Multi-Window

Posted by Ian Lake, Developer Advocate

As a developer, there’s a wide range of features added in Android N to take advantage of, but when it comes to designing and building your UI, having strong multi-window support should be at the forefront.

The primary mode that users will be interacting with multi-window is through split-screen mode, which is available on both handheld devices and larger tablets. In this mode, two apps split the available screen space and the user can drag the divider between the two split screens to resize the apps. As you might imagine, this mode offers some unique design challenges beyond what was needed previously.

An even more responsive UI

The lessons learned from previous versions of Android, the mobile web, and desktop environments still apply to Android N. Designing a responsive UI is still an important first step towards an amazing multi-window experience.

A responsive UI is one that adapts to the size provided, picking the best representation of the content and the appropriate navigation patterns to make a great user experience on any device. Check out the Building a Responsive UI blog post for details on how to design and build an effective responsive UI.

Adapting your layout

As you’re designing layouts for the largest and smallest screens and everything in between, it is important to make resizing a smooth and seamless transition as mentioned in the split screen layout guidelines. If you already have a similar layout between mobile and tablet, you’ll find much of your work taken care of for you.

However, if your mobile and tablet layouts are vastly different and there’s no way to smoothly transition between the two, you should not transition between them when resizing. Instead, focus on making your tablet UI scale down using the same responsive UI patterns. This ensures that users do not have to relearn their UI when resizing your app.

Note that the minimalHeight and minimalWidth layout attributes allow you to set a minimum size you want reported to your Activity, but they do not mean the user cannot resize your activity smaller - it actually means that your activity will be cropped to the size the user requests, potentially forcing elements of your UI off the screen. Strive to support down to the minimum size of 220x220dp.

Design configurations to consider

While many of the sizes and aspect ratios possible in multi-window are similar to existing devices (1/3rd of a landscape tablet is similar to existing mobile devices in screen size), there are a few configurations that are much more common when considering multi-window.

The first is a 16x9 layout on mobile devices in portrait. In this case, the vertical space is extremely limited. If you have a number of fixed elements stacked on top of one another (a toolbar, scrolling content, and a bottom navigation bar), you might find there’s not actually any room for the scrolling content - the most important part!

The second case to consider is the 34.15% layout on tablets. The very wide aspect ratio in device portrait or very tall aspect ratio in device landscape orientation are more extreme than what is found on existing devices. Consider using your mobile layouts as a starting point for this configuration.

Patterns to avoid

When it comes to multi-window, there are a few patterns you want to avoid entirely.

The first is UI interactions that rely on swiping from the edge of the screen. This has already been somewhat of an issue when it comes to the on screen navigation bar prominent on many devices (such as Nexus devices), but is even more so in split-screen mode. Since there is (purposefully) no way to determine if your activity is on the top or bottom or the left or the right, don’t make edge swipes the only way to access functionality in your app. That doesn’t mean you have to avoid them entirely - just make sure there is an alternative. A good example of this is the temporary navigation drawer - an edge swipe opens the drawer, but it is also accessible by pressing the hamburger icon in the toolbar.

The second is disabling multi-window entirely. While there are certainly cases where this makes sense (i.e., it is fundamentally an immersive experience such as a game), there are also cases where your activity and any Activities launched from that Activity are forced to support multi-window. As mentioned in the Preparing for Multi-Window blog post, when you support external apps launching your activity, your activity inherits the multi-window properties of the calling Activity.

Designing for Multi-Window is designing for every device

Building a responsive UI that reacts to the space available is critical to a great multi-window experience, but it is an exercise that can benefit all of your users across the wide variety of Android devices.

So use this as an opportunity to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Introducing the second class of Launchpad Accelerator

Originally posted on Google Developers blog

Roy Glasberg, Global Lead, Launchpad Program & Accelerator

This week Launchpad Accelerator announces its second class, which includes 24 promising startups from around the world. While the number of accelerators is at an all-time high, we take a different approach with Launchpad Accelerator, a program that exclusively works with late-stage tech startups in emerging markets -- Brazil, Indonesia, India and Mexico.

See what it’s like to participate in the Accelerator.


“We provide comprehensive mentorship that delivers results,” says Jacob Greenshpan, one of Launchpad’s lead mentors. “We start by running a ‘patient diagnostic’ to determine each startup’s critical challenges, and then deploy precise mentorship, actionable solutions, and Google resources that enables the app to scale.”

Class 2 kicks off June 13. The startups will descend on Google HQ for an intensive 2 week bootcamp. Under the tutelage of Google product teams and mentors from the global Launchpad network, they will receive intensive, targeted mentoring, equity-free funding, and more benefits during the 6-month program.

Here’s the full list of startups (by country):

Brazil

BankFacil Emprego Ligado AppProva GetNinjas Edools Love Mondays

Indonesia

HijUp Talenta Jarvis Store Ruangguru IDNtimes Codapay

India

Taskbob Programming Hub ShareChat RedCarpet PlaySimple Games MagicPin

Mexico

Aliada SaferTaxi Conekta Konfio Kichink Miroculus

Google’s “Scalerator” Drives Results for Alumni

What advice do Class 1 alumni give to the new intake? “Come to the accelerator with an open mind. You will be shocked to find how many things are going wrong in your app. Thankfully the mentors will help you implement better solutions,” says Vinicius Heimbeck, Founder of Brazilian mobile game developer UpBeat Games.

UpBeat Games had more than 1,000% increase in daily app installations in Asia during the period of a feature, as well as a 200% overall increase in active users after following a long list of improvements Accelerator mentors suggested. “We made optimizations that led us to be featured in Google Play, which changed everything for us.”

See Upbeat Games at the Accelerator in this video.

“Believe you can build a world class product. The mentors will push you to bet on yourself,” says Amarendra Sahu, Nestaway Co-founder and Class 1 alumni. NestAway just closed a $30M Series C, one of the largest investment rounds in India this year.

“Your biggest enemy is not failure; it is the temptation to be ordinary. But the mentors will push you to build an extraordinary product and scale an extraordinary startup," says eFishery Co-founder and CEO Gibran Chuzaefah Amsi El Farizy, who was announced as one of the top 27 leaders in Indonesia’s startup ecosystem, after participating in the Accelerator program.

Get the guide to News app success on Google Play and see how Nabd engages readers with Material Design

Posted by Tamzin Taylor - Strategic Partner Lead, Google Play

Today we’re releasing The News Publisher Playbook, where you will learn best practices for developing a successful news mobile strategy on Android. This is a new companion guide to our business playbook for developers, The Secrets to App Success on Google Play, focused on the news apps segment.

The guide includes tips and useful resources to help you optimize your news content on mobile, identifying the best distribution channels to reach the right audience, build your brand and maximize your revenue.

You will find tips on mobile website optimization, how to create a Google Play Newsstand edition, and how to improve your native app. You will also get an overview of ways to acquire and engage your readers as well as how to monetize and grow your revenue.

Once you’ve checked out the guide, we’d love to hear your feedback, so we can continue to improve our developer resources. Please let us know what you think.

Android Developer Story: Nabd improves reader engagement with Material Design

Founded in 2012, Nabd is a personalised Arabic news aggregator app based in Kuwait, reaching over 10 million people, of which, 60% use Android devices. Watch this Android Developer Story to hear Abdur-Rahman El-Sayed, Co-founder and CEO, and Abdullah El-Sayed, Co-founder and VP of Engineering, explain how adopting Material Design increased user engagement and improved ratings.


Get the News Publisher Playbook to help you find success on Google Play.


Enhancing App Security on Google Play

Posted by Eric Davis, Android Security Team

We’re constantly investing in new tools and services to help developers build secure Android applications. This includes the application sandbox and Security APIs in the platform, Security APIs in Google Play Services, and even open source testing tools. Last year, Google Play also helped developers enhance the security of their applications by looking directly at the code they’ve written and offering suggestions for improvements.

The Google Play App Security Improvement Program is the first of its kind. It has two core components: We provide developers with security tips to help them build more secure apps, and we help developers identify potential security enhancements when uploaded to Google Play. This week, to help educate developers, Kristian Monsen, one of our engineers, gave a presentation about security best practices at the Samsung Developer Conference. And in 2015, we worked with developers to improve the security of over 100,000 apps through the program.

How it works

Before any app is accepted into Google Play, it is scanned for safety and security, including potential security issues. We also continuously re-scan the over one million apps in Google Play for additional threats.

If your app is flagged for a potential security issue, you will be notified immediately to help you quickly address the issue and help keep your users safe. We’ll deliver alerts to you using both email and the Google Play Developer Console, with links to a support page with details about how to improve the app.


Typically, these notifications will include a timeline for delivering the improvement to users as quickly as possible. Applications may be required to make security improvements before any other app updates can be be published.

You can confirm that you’ve fully addressed the issue by uploading the new version of your app to the Google Play Developer Console. Be sure to increment the version number of the fixed app. After a few hours, check the Developer Console for the security alert; if it’s no longer there, you’re all set!

The success of this program rests on our partnership with you—the developers of apps on Google Play—and the security community. We’re all responsible for providing safe, secure apps to our users. For feedback or questions, please reach out to us through the Google Play Developer Help Center. To report potential security issues in apps, please reach out to us at [email protected].

Developing for Direct Boot

Posted by Wojtek Kaliciński, Developer Advocate

Starting with Android N, a device that has been powered on can boot into a new mode called Direct Boot before the user has a chance to unlock it for the first time. In this mode, the operating system is fully operational, but access to private app data is limited and only apps that have been updated to be Direct Boot aware can run.

Is Direct Boot right for my app?

Not every app should run in Direct Boot mode, so before you start coding check if your app fits these common use cases:

  • Apps that schedule alarms, such as alarm clocks.
  • Apps that provide important and timely notifications, like messaging apps.
  • Apps that provide services to other apps or the system, such as Accessibility Services.

Please note that this is not an exhaustive list and we look forward to seeing what other kinds of apps can benefit from Direct Boot.

Making your app Direct Boot aware

In order to let your app run before the user unlocks the device, you have to explicitly mark components as being Direct Boot aware in the manifest:

 <activity|provider|receiver|service ...  
     android:directBootAware=”true”>

You can pick the subset of your app components that need to be Direct Boot aware, but if you are using a custom Application class, it is assumed to be Direct Boot aware if any component inside your app is marked as Direct Boot aware.

For apps that need to run as soon as the system starts in Direct Boot mode, there is a new Intent.ACTION_LOCKED_BOOT_COMPLETED broadcast. All apps will still receive Intent.ACTION_BOOT_COMPLETED after the user unlocks the device.

Using the device protected storage area

To support running apps before the user provides the credentials needed to unlock private app data, all Android N devices now provide two storage locations for data:

  • Credential protected storage, which is the default storage location for all apps, available only after the user has unlocked the device
  • Device protected storage, which is a new storage location that can be accessed at all times when the device is booted, including during Direct Boot

Components of your app that are marked as Direct Boot aware must rely on device protected storage for any data required for their operation during Direct Boot mode. They may still access credential protected storage after the user has unlocked the device.

To access device protected storage you need to create and use a secondary Context object for all file-related APIs:

 Context deviceProtectedContext = context.createDeviceProtectedStorageContext();  
 deviceProtectedContext.openFileInput( ... )

When your app gets updated to a Direct Boot aware version, you might have previously saved Shared Preferences or databases that need to be migrated to device protected storage. You should use Context.moveSharedPreferencesFrom() and Context.moveDatabaseFrom() before accessing them to make sure the app continues to work properly even when data is backed up and restored from older versions or other devices.

Things to watch out for

You should think carefully about what you put in the device protected storage. This should be a minimum set of data that will let your app work during Direct Boot. For example, in a messaging app you could store an access token with a narrow scope that only has access to the number of new messages on your server. All sensitive, private information, like the full message history and a read/write access token, should still be saved in credential protected storage.

Another thing to remember is that during Direct Boot apps can only access other Direct Boot aware apps and components. If your app depends on external Services and Activities, make sure you gracefully handle the situation when they’re not available. Intent filters will by default match only components available in the current user state (locked / unlocked). There are two new flags for explicitly telling the Package Manager which components to enumerate: PackageManager.MATCH_DIRECT_BOOT_AWARE and PackageManager.MATCH_DIRECT_BOOT_UNAWARE.

What’s next?

Until devices with Android N that support Direct Boot out of the box are released, you can test your apps using Android N Developer Preview builds. On Nexus 5X and Nexus 6P, you can wipe all user data and enable full Direct Boot mode by using Settings > Developer options > Convert to file encryption. Alternatively, you can reboot into bootloader and issue the appropriate fastboot command:

 $ adb reboot-bootloader  
 $ fastboot --wipe-and-use-fbe

Warning: Both methods will perform a factory reset and delete all user data on your device.

Alternatively, you can use an emulated Direct Boot mode. To enable it, set a lock pattern on the device, choose "No thanks" if prompted for a secure start-up screen when setting a lock pattern, and then use the following adb shell commands to enable and disable emulation:

 $ adb shell sm set-emulate-fbe true  
 $ adb shell sm set-emulate-fbe false

Please note that using these commands will cause your device to reboot. You should only be using emulated Direct Boot mode on test devices, as it may cause data loss.

#BuildBetterApps

Follow the Android Development Patterns Collection for more!

Android Studio 2.1 supports Android N Developer Preview

Posted by Jamal Eason, Product Manager, Android

With the launch Android N Developer Preview, we wanted to give you an easy and comprehensive way to build, test and validate your apps on the latest release with Android Studio. Built on the speed and feature enhancements of Android Studio 2.0, the stable release of Android Studio 2.1 includes updates to the IDE wizards, build system and Android Emulator so that you can try out new features and APIs of the developer preview including the new Jack compiler and Java 8 language support. In addition to support for the N Developer Preview, Android Studio 2.1 also includes performance improvements to Instant Run which leads to faster edit and deploy build speeds. If you are developing and validating your app with the N Developer Preview or want faster Instant Run speeds, you should download or update on the stable release channel to Android Studio 2.1.

Android Studio 2.1 includes the following new features:

  • N Developer Preview Support: Android Studio 2.1 is the best IDE to test and validate your app with the N Developer Preview. Get the latest versions of the preview SDK, experiment with the new Java 8 support, and gain access to the only official Android Emulator able to run N Developer Preview Emulator System Images to help in your testing.
  • Instant Run: For those of you who enjoyed the fast edit, build and deploy cycle with Android Studio 2.0, Instant Run now can now update incremental changes to your app code significantly faster.

Deeper Dive into the New Features

N Developer Preview

On top of new features and APIs of the N Developer Preview, Android Studio 2.1 release includes support for the new Jack compiler and support for Java 8. With the Jack compiler, lambdas, method references, compile-time type annotations, intersection types and type inference are available on all versions of the Android platform. Default and static methods and repeatable annotations are available on Android N and higher. To use Java 8 language features when developing with the N Developer Preview, you need to use the Jack compiler. The New Project Wizard [File→ New→ Project] generates the correct configurations for projects targeting the N.

Getting started with development is as easy generating a new project or updating a few settings in your existing project. Once you are ready to test, you can create a fresh Android Virtual Device (AVD) and run your app on the N Developer Preview using the new Android Emulator.


N Developer Preview on the new Android Emulator

Instant Run & General Build Performance Improvements

Instant Run and general build speed are now faster with two new features: incremental Java compilation and in-process dex.

In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled. Now in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed.

We are also speeding up build times by using in-process dex, which converts class files to dex files within the Gradle daemon process. This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). This feature will help speed up both incremental and full builds.

We’d appreciate your feedback as we continue to improve Instant Run and general build performance. We are going to keep working on making build times even faster in coming releases. Click here to learn even more about the build changes.

What's Next

Update

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]). If you need a new copy of Android Studio, you can download it here.

Test and Validate Apps with N Developer Preview

After you update to or download Android Studio 2.1 and you want to test and develop your apps with the N Developer Preview, create a fresh Android Virtual Device (AVD) for the new Android emulator, and check out these additional setup instructions.

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 Google+ page or on Twitter.

An Outsourcing Playbook for Android development

Posted by Rupert Whitehead, Developer Relations

We recently updated The Secrets to App Success on Google Play with tools and tips to help app and game developers grow successful businesses on Google Play. However, many great apps are created by agencies and freelancers on behalf of companies. Today, we’re releasing a new playbook to help companies of any size who are considering outsourcing their Android app development.

How do you choose an agency? What are the pitfalls you should avoid? What can you do to make your app successful? These are some of the questions tackled by the new Outsourcing Playbook that you can read on Google Play.

Let us know your feedback

Once you’ve checked out the guide, we’d love to hear your feedback so we can continue to improve our developer resources and support. Let us know what you think.

Optimize, Develop, and Debug with Vulkan Developer Tools

Posted by Shannon Woods, Technical Program Manager

Today we're pleased to bring you a preview of Android development tools for Vulkan™. Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications.

Vulkan support is available now via the Android N Preview on devices which support it, including Nexus 5X and Nexus 6P. (Of course, you will still be able to use OpenGL ES as well!)

To help developers start coding quickly, we’ve put together a set of samples and guides that illustrate how to use Vulkan effectively.

You can see Vulkan in action running on an Android device with Robert Hodgin’s Fish Tornado demo, ported by Google’s Art, Copy, and Code team:


Optimization: The Vulkan API

There are many similarities between OpenGL ES and Vulkan, but Vulkan offers new features for developers who need to make every millisecond count.


  • Application control of memory allocation. Vulkan provides mechanisms for fine-grained control of how and when memory is allocated on the GPU. This allows developers to use their own allocation and recycling policies to fit their application, ultimately reducing execution and memory overhead and allowing applications to control when expensive allocations occur.
  • Asynchronous command generation. In OpenGL ES, draw calls are issued to the GPU as soon as the application calls them. In Vulkan, the application instead submits draw calls to command buffers, which allows the work of forming and recording the draw call to be separated from the act of issuing it to the GPU. By spreading command generation across several threads, applications can more effectively make use of multiple CPU cores. These command buffers can also be reused, reducing the overhead involved in command creation and issuance.
  • No hidden work. One OpenGL ES pitfall is that some commands may trigger work at points which are not explicitly spelled out in the API specification or made obvious to the developer. Vulkan makes performance more predictable and consistent by specifying which commands will explicitly trigger work and which will not.
  • Multithreaded design, from the ground up. All OpenGL ES applications must issue commands for a context only from a single thread in order to render predictably and correctly. By contrast, Vulkan doesn’t have this requirement, allowing applications to do work like command buffer generation in parallel— but at the same time, it doesn’t make implicit guarantees about the safety of modifying and reading data from multiple threads at the same time. The power and responsibility of managing thread synchronization is in the hands of the application.
  • Mobile-friendly features. Vulkan includes features particularly helpful for achieving high performance on tiling GPUs, used by many mobile devices. Applications can provide information about the interaction between separate rendering passes, allowing tiling GPUs to make effective use of limited memory bandwidth, and avoid performing off-chip reads.
  • Offline shader compilation. Vulkan mandates support for SPIR-V, an intermediate language for shaders. This allows developers to compile shaders ahead of time, and ship SPIR-V binaries with their applications. These binaries are simpler to parse than high-level languages like GLSL, which means less variance in how drivers perform this parsing. SPIR-V also opens the door for third parties to provide compilers for specialized or cross-platform shading languages.
  • Optional validation. OpenGL ES validates every command you call, checking that arguments are within expected ranges, and objects are in the correct state to be operated upon. Vulkan doesn’t perform any of this validation itself. Instead, developers can use optional debug tools to ensure their calls are correct, incurring no run-time overhead in the final product.

Debugging: Validation Layers


As noted above, Vulkan’s lack of implicit validation requires developers to make use of tools outside the API in order to validate their code. Vulkan’s layer mechanism allows validation code and other developer tools to inspect every API call during development, without incurring any overhead in the shipping version. Our guides show you how to build the validation layers for use with the Android NDK, giving you the tools necessary to build bug-free Vulkan code from start to finish.

Develop: Shader toolchain


The Shaderc collection of tools provides developers with build-time and run-time tools for compiling GLSL into SPIR-V. Shaders can be compiled at build time using glslc, a command-line compiler, for easy integration into existing build systems. Or, for shaders which are generated or edited during execution, developers can use the Shaderc library to compile GLSL shaders to SPIR-V via a C interface. Both tools are built on top of Khronos’s reference compiler.

Additional Resources


The Vulkan ecosystem is a broad one, and the resources to get you started don’t end here. There is a wealth of material to explore, including:

Android N Developer Preview 2, out today!

Posted by Dave Burke, VP of Engineering

Last month, we released the first Developer Preview of Android N, to give you a sneak peek at our next platform. The feedback you’ve shared to-date has helped us catch bugs and improve features. Today, the second release in our series of Developer Previews is ready for you to continue testing against your apps.

This latest preview of Android N fixes a few bugs you helped us identify, such as not being able to connect to hidden Wi-Fi networks (AOSP 203116), Multiwindow pauses (AOSP 203424), and Direct Reply closing an open activity (AOSP 204411), to name just a few. We’re still on the hunt for more; please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community.

What’s new:

Last month’s Developer Preview introduced a host of new features, like Multi-window, bundled notifications and more. This preview builds on those and includes a few new ones:

  • Vulkan: Vulkan is a new 3D rendering API which we’ve helped to develop as a member of Khronos, geared at providing explicit, low-overhead GPU (Graphics Processor Unit) control to developers and offers a significant boost in performance for draw-call heavy applications. Vulkan’s reduction of CPU overhead allows some synthetic benchmarks to see as much as 10 times the draw-call throughput on a single core as compared to OpenGL ES. Combined with a threading-friendly API design which allows multiple cores to be used in parallel with high efficiency, this offers a significant boost in performance for draw-call heavy applications. With Android N, we’ve made Vulkan a part of the platform; you can try it out on supported devices running Developer Preview 2. Read more here. Vulkan Developer Tools blog here.

  • Launcher shortcuts: Now, apps can define shortcuts which users can expose in the launcher to help them perform actions quicker. These shortcuts contain an Intent into specific points within your app (like sending a message to your best friend, navigating home in a mapping app, or playing the next episode of a TV show in a media app).

    An application can publish shortcuts with ShortcutManager.setDynamicShortcuts(List) and ShortcutManager.addDynamicShortcut(ShortcutInfo), and launchers can be expected to show 3-5 shortcuts for a given app.


  • Emoji Unicode 9 support: We are introducing a new emoji design for people emoji that moves away from our generic look in favor of a more human-looking design. If you’re a keyboard or messaging app developer, you should start incorporating these emoji into your apps. The update also introduces support for skin tone variations and Unicode 9 glyphs, like the bacon, selfie and face palm. You can dynamically check for the new emoji characters using Paint.hasGlyph().

New human emoji

New activity emoji
  • API changes: This update includes API changes as we continue to refine features such as multi-window support (you can now specify a separate minimum height and minimum width for an activity), notifications, and others. For details, take a look at the diff reports available in the downloadable API reference package.

  • Bug fixes: We’ve resolved a number of issues throughout the system, including these fixes for issues that you’ve reported through the public issue tracker. Please continue to let us know what you find and follow along with the known issues here.

How to get the update:

The easiest way to get this and later preview updates is by enrolling your devices in the Android Beta Program. Just visit g.co/androidbeta and opt-in your eligible Android phone or tablet -- you’ll soon receive this (and later) preview updates over-the-air. If you’ve already enrolled your device, you’ll receive the update shortly, no action is needed on your part. You can also download and flash this update manually. Developer Preview 2 is intended for developers and not as a daily driver; this build is not yet optimized for performance and battery life.

The N Developer Preview is currently available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices. For Nexus Player, the update to Developer Preview 2 will follow the other devices by several days.

To build and test apps with Developer Preview 2, you need to use Android Studio 2.1 -- the same version that was required for Developer Preview 1. You’ll need to check for SDK components updates (including build tools and emulator system images) for Developer Preview 2 -- see here for details.

Thanks so much for all of your feedback so far. Please continue to share feedback, either in the N Developer Preview issue tracker or in the N preview community. The sooner we’re able to get your feedback, the more of of it we will be able to incorporate in the next release of Android.