• We paid over $550,000 to 82 individuals. That’s an average of $2,200 per reward and $6,700 per researcher.
• We paid our top researcher, @heisecode, $75,750 for 26 vulnerability reports.
• We paid 15 researchers $10,000 or more.
• There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise.

Sendy is a door to door on-demand couriering platform founded in Nairobi, Kenya. It connects customers and logistics providers, providing two unique apps, one for the driver and one for the customer. Watch CEO & Co-founder, Meshack Alloys, and Android Developer, Jason Rogena, explain how they use Developer Console features, such as alpha and beta testing, as well as other tips and best practices, to build for the next billion users.

Learn more about building for billions and get more tips to grow your games business by opting-in to the Playbook app beta and download the Playbook app in the Google Play Store.

Posted by Sergio Giro, software engineer

If your Android app derives keys using the SHA1PRNG algorithm from the Crypto provider, you must start using a real key derivation function and possibly re-encrypt your data.

The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:

Or simply:

For instance,

On Android, we don’t recommend specifying the provider. In general, any call to the Java Cryptography Extension (JCE) APIs specifying a provider should only be done if the provider is included in the application or if the application is able to deal with a possible ProviderNotFoundException.

Unfortunately, many apps depend on the now removed “Crypto” provider for an anti-pattern of key derivation.

This provider only provided an implementation of the algorithm “SHA1PRNG” for instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not cryptographically strong. For readers interested in the details, On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL,Section 8.1, by Yongge Want and Tony Nicol, states that the “random” sequence, considered in binary form, is biased towards returning 0s, and that the bias worsens depending on the seed.

As a result, in Android N we are deprecating the implementation of the SHA1PRNG algorithm and the Crypto provider altogether. We’d previously covered the issues with using SecureRandom for key derivation a few years ago in Using Cryptography to Store Credentials Safely. However, given its continued use, we will revisit it here.

A common but incorrect usage of this provider was to derive keys for encryption by using a password as a seed. The implementation of SHA1PRNG had a bug that made it deterministic if setSeed() was called before obtaining output. This bug was used to derive a key by supplying a password as a seed, and then using the "random" output bytes for the key (where “random” in this sentence means “predictable and cryptographically weak”). Such a key could then be used to encrypt and decrypt data.

In the following, we explain how to derive keys correctly, and how to decrypt data that has been encrypted using an insecure key. There’s also a full example, including a helper class to use the deprecated SHA1PRNG functionality, with the sole purpose of decrypting data that would be otherwise unavailable.

Keys can be derived in the following way:

• If you're reading an AES key from disk, just store the actual key and don't go through this weird dance. You can get a SecretKey for AES usage from the bytes by doing:

  SecretKey key = new SecretKeySpec(keyBytes, "AES");

• If you're using a password to derive a key, follow Nikolay Elenkov's excellent tutorial with the caveat that a good rule of thumb is the salt size should be the same size as the key output. It looks like this:

   /* User types in their password: */  
   String password = "password";  

   /* Store these things on disk used to derive key later: */  
   int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size
              as the output (256 / 8 = 32)  
   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
   byte[] salt; // Should be of saltLength  

   /* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   byte[] salt = new byte[saltLength];  
   random.nextBytes(salt);  

   /* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
              iterationCount, keyLength);  
   SecretKeyFactory keyFactory = SecretKeyFactory  
              .getInstance("PBKDF2WithHmacSHA1");  
   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  
   SecretKey key = new SecretKeySpec(keyBytes, "AES");  

That's it. You should not need anything else.

To make transitioning data easier, we covered the case of developers that have data encrypted with an insecure key, which is derived from a password every time. You can use the helper class InsecureSHA1PRNGKeyDerivator in the example app to derive the key.

 private static SecretKey deriveKeyInsecurely(String password, int
 keySizeInBytes) {  
    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
    return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  
                     passwordBytes, keySizeInBytes),  
            "AES");  
 }  

You can then re-encrypt your data with a securely derived key as explained above, and live a happy life ever after.

Note 1: as a temporary measure to keep apps working, we decided to still create the instance for apps targeting SDK version 23, the SDK version for Marshmallow, or less. Please don't rely on the presence of the Crypto provider in the Android SDK, our plan is to delete it completely in the future.

Note 2: Because many parts of the system assume the existence of a SHA1PRNG algorithm, when an instance of SHA1PRNG is requested and the provider is not specified we return an instance of OpenSSLRandom, which is a strong source of random numbers derived from OpenSSL.

Posted by Ian Lake, Developer Advocate

Android notifications are often a make-or-break interaction between your Android app and users. To provide a better user experience, notifications on Android N have received a visual refresh, improved support for custom views, and expanded functionality in the forms of Direct Reply, a new MessagingStyle, and bundled notifications.

Same notification, new look

The first and most obvious change is that the default look and feel of notifications has significantly changed. Many of the fields that were spread around the notifications have been collapsed into a new header row with your app’s icon and name anchoring the notification. This change ensured that the title, text, and large icon are given the most amount of space possible and, as a result, notifications are generally slightly larger now and easier to read.

Given the single header row, it is more important than ever that the information there is useful. When you target Android N, by default the time will be hidden - if you have a time critical notification such as a messaging app, you can re-enable it with setShowWhen(true). In addition, the subtext now supersedes the role of content info and number: number is never shown on Android N devices and only if you target a previous version of Android and don’t include a subtext will content info appear. In all cases, ensure that the subtext is relevant and useful - don’t add an account email address as your subtext if the user only has one account, for example.

Notification actions have also received a redesign and are now in a visually separate bar below the notification.

You’ll note that the icons are not present in the new notifications; instead more room is provided for the labels themselves in the constrained space of the notification shade. However, the notification action icons are still required and continue to be used on older versions of Android and on devices such as Android Wear.

If you’ve been building your notification with NotificationCompat.Builder and the standard styles available to you there, you’ll get the new look and feel by default with no code changes required.

Better Support for Custom Views

If you’re instead building your notification from custom RemoteViews, adapting to any new style has been challenging. With the new header, expanding behavior, actions, and large icon positioning as separate elements from the main text+title of the notification, we’ve introduced a new DecoratedCustomViewStyle and DecoratedMediaCustomViewStyle to provide all of these elements, allowing you to focus only on the content portion with the new setCustomContentView() method.

This also ensures that future look and feel changes should be significantly easier to adapt to as these styles will be updated alongside the platform with no code changes needed on the app side.

Direct Reply

While notification actions have already been able to launch an Activity or do background work with a Service or BroadcastReceiver, Direct Reply allows you to build an action that directly receives text input inline with the notification actions.

Direct Reply uses the same RemoteInput API - originally introduced for Android Wear - to mark an Action as being able to directly receive input from the user.

The RemoteInput itself contains information like the key which will be used to later retrieve the input and the hint text which is displayed before the user starts typing.

// Where should direct replies be put in the intent bundle (can be any string)
private static final String KEY_TEXT_REPLY = "key_text_reply";

// Create the RemoteInput specifying this key
String replyLabel = getString(R.string.reply_label);
RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY)
        .setLabel(replyLabel)
        .build();

Once you’ve constructed the RemoteInput, it can be attached to your Action via the aptly named addRemoteInput() method. You might consider also calling setAllowGeneratedReplies(true) to enable Android Wear 2.0 to generate Smart Reply choices when available and make it easier for users to quickly respond.

// Add to your action, enabling Direct Reply for it
NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.reply, replyLabel, pendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true)
        .build();

Keep in mind that the pendingIntent being passed into your Action should be an Activity on Marshmallow and lower devices that don’t support Direct Reply (as you’ll want to dismiss the lock screen, start an Activity, and focus the input field to have the user type their reply) and should be a Service (if you need to do work on a separate thread) or BroadcastReceiver (which runs on the UI thread) on Android N devices so as the process the text input in the background even from the lock screen. (There is a separate user control to enable/disable Direct Reply from a locked device in the system settings.)

Extracting the text input in your Service/BroadcastReceiver is then possible with the help of the RemoteInput.getResultsFromIntent() method:

private CharSequence getMessageText(Intent intent) {
    Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);
    if (remoteInput != null) {
        return remoteInput.getCharSequence(KEY_TEXT_REPLY);
    }
    return null;
 }

After you’ve processed the text, you must update the notification. This is the trigger which hides the Direct Reply UI and should be used as a technique to confirm to the user that their reply was received and processed correctly.

For most templates, this should involve using the new setRemoteInputHistory() method which appends the reply to the bottom of the notification. Additional replies should be appended to the history until the main content is updated (such as the other person replying).

However, if you’re building a messaging app and expect back and forth conversations, you should use MessagingStyle and append the additional message to it.

MessagingStyle

We’ve optimized the experience for displaying an ongoing conversation and using Direct Reply with the new MessagingStyle.

This style provides built-in formatting for multiple messages added via the addMessage() method. Each message supports passing in the text itself, a timestamp, and the sender of the message (making it easy to support group conversations).

builder.setStyle(new NotificationCompat.MessagingStyle("Me")
    .setConversationTitle("Team lunch")
    .addMessage("Hi", timestampMillis1, null) // Pass in null for user.
    .addMessage("What's up?", timestampMillis2, "Coworker")
    .addMessage("Not much", timestampMillis3, null)
    .addMessage("How about lunch?", timestampMillis4, "Coworker"));

You’ll note that this style has first-class support for specifically denoting messages from the user and filling in their name (in this case with “Me”) and setting an optional conversation title. While this can be done manually with a BigTextStyle, by using this style Android Wear 2.0 users will get immediate inline responses without kicking them out of the expanded notification view, making for a seamless experience without needing to build a full Wear app.

Bundled Notifications

Once you’ve built a great notification by using the new visual designs, Direct Reply, MessagingStyle, and all of our previous best practices, it is important to think about the overall notification experience, particularly if you post multiple notifications (say, one per ongoing conversation or per new email thread).

If you’ve built stacking notifications for Android Wear, the API used here is exactly the same. Simply add setGroup() to each individual notification to bundle those notifications together. You’re not limited to one group, so bundle notifications appropriately. For an email app, you might consider one bundle per account for instance.

It is important to also create a summary notification. This summary notification, denoted by setGroupSummary(true), is the only notification that appears on Marshmallow and lower devices and should (you guessed it) summarize all of the individual notifications. This is an opportune time to use the InboxStyle, although using it is not a requirement. On Android N and higher devices, some information (such as the subtext, content intent, and delete intent) is extracted from the summary notification to produce the collapsed notification for the bundled notifications so you should continue to generate a summary notification on all API levels.

To improve the overall user experience on Android N devices, posting 4 or more notifications without a group will cause those notifications to be automatically bundled.

N is for Notifications

Notifications on Android have been a constant area of progressive enhancement. From the single tap targets of the Gingerbread era to expandable notifications, actions, MediaStyle, and now features such as Direct Reply and bundled notifications, notifications play an important part of the overall user experience on Android.

With many new tools to use (and NotificationCompat to help with backward compatibility), I’m excited to see how you use them to #BuildBetterApps

Follow the Android Development Patterns Collection for more!

Posted by Lily Sheringham, Google Play team

Based in Ho Chi Minh City in Vietnam, games developer Divmob has grown quickly from an original team of five people to 40 employees since it was founded three years ago. Divmob now has over 40 million downloads across its various titles, including the popular game, Epic Heroes War.

Watch Ngo Van Luyen, CEO & Founder at Divmob, and his team explain how introducing sub-dollar pricing in various markets resulted in a 300% increase in daily transactions, and increased the number of paying users threefold.

Find out more about local pricing models on Google Play

We recently introduced new features in the Google Play Developer Console to help you meet local expectations when setting prices, to make purchases more attractive to your users. The Developer Console will now automatically round pricing to local conventions in each market, and you can also set up pricing templates to manage pricing across multiple currencies more efficiently, and easily make bulk changes to the prices of multiple apps and in-app products in a single click. Learn more about the improved local pricing tools.

Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

During a special ceremony last tonight at Google I/O, we honored ten apps and games for their outstanding achievements as part of the inaugural Google Play Awards.

As we shared onstage, when you look at how Google Play has evolved over the years, it’s pretty amazing. We’re now reaching over 1 billion users every month and there’s literally something for everyone. From real-time multiplayer to beautiful Indie games, industry changing startups to innovative uses of mobile technology, developers like you continue to push the boundaries of what apps can do.

Congrats to the following developers in each category!

• Layout Editor: A new user interface designer that helps you visually design the layouts in your app. Features like blueprint mode and the new properties panel allow you to quickly edit layouts and widgets faster.
• Constraint Layout: A new powerful and flexible Android layout that allows you to express complex UIs without nesting multiple layouts. 
• Layout Inspector: Debug a snapshot of your app layout running on the Android Emulator or device. Inspect the view hierarchy and corresponding attributes.

• Firebase Plugin: Explore and integrate the suite of services offered by Firebase inside of Android Studio. Adding services like Analytics, Authentication, Notifications, and AdMob are just a few clicks away.
• Enhanced Code Analysis: Android Studio checks the quality of your Android app code. In addition to 260 Android lint and code inspections, this release includes new code quality checks for Java 8 language usage and a new inspection infrastructure for more cross-file analysis.
• Samples Browser: Referencing Android sample code is now even easier. Within the code editor window, find occurrences of your app code snippets in Google Android sample code to help jump start your app development.
• Improved C++ Support: Android Studio 2.2 improves C++ development with the ability to edit, build, and debug pre-existing Android projects that use ndk-build or CMake rather than Gradle. Additionally, the existing lldb C++ debugger is now even better with project type auto-detection and a Java language aware C++ mode that lets you use a single debugger process to inspect both Java language and C++ runtimes.
• IntelliJ 2016.1: Android Studio 2.2 includes all the latest updates from the underlying JetBrains product platforms IntelliJ.

• Jack Compiler Improvements: For those using the new Jack compiler, Android Studio 2.2 adds support for annotation processing, as well as incremental builds for reduced build times.
• Merged Manifest Viewer: Diagnose how your AndroidManifest.xml merges with your app dependences across your project build variants. 

• Espresso Test Recorder: Record Espresso UI tests simply by using your app as a normal user. As you click through your app UI, reusable and editable test code is then generated for you. You can run the generated tests locally, in your Continuous Integration environment, or in Firebase Test lab. 
• APK Analyzer: Drill into your APK to help you reduce your APK size, debug 64K method limit issues, view contents of Dex files and more.

Deeper Dive into the New Features 

• Layout Editor: Android Studio 2.2 features a new user interface designer. There are many enhancements but some of the highlights include: 
• Drag-and-drop widgets from the palette to the design surface or the component tree view of your app.
• Design surface has a blueprint mode to inspect the spacing and arrangement of your layout. 
• Properties panel now shows a curated set of properties for quick widget edits with a full sheet of advanced properties one click away.
• UI builder can edit menu and system preference files. 

The new Layout Editor in Android Studio 2.2 Preview

Edit Menus in the new 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 distributed as a support library that is tightly coupled with Android Studio and backwards compatible to API Level 9. 

Constraint Layout

Start Layout Inspector

• Layout Inspector: For new and existing layouts, many times you may want to debug your app UI to determine if your layout is rendering as expected. With the new Layout Inspector, you can drill into the view hierarchy of your app and analyze the attributes of each component of UI on the screen. 

To use the tool, just click on Layout Inspector Icon in the Android Monitor Window, and then Android Studio creates a snapshot of the current view hierarchy of your app for you to inspect.

Layout Inspector

Develop

• Firebase Plugin: Firebase is the new suite of developers services that can help you develop high-quality apps, grow your user base, and earn more money. Inside of Android Studio, you can add Firebase to a new or existing Android app with the new Assistant window. To access the Firebase features click on the Tools menu and then select Firebase. You will want to first setup the brand new Firebase Analytics as the foundation as you explore other Firebase services like Firebase Cloud Messaging or Firease Crash Reporting to add your application. Learn more about the Firebase integration inside Android Studio here.

Firebase Plugin for Android Studio

• Code Sample Browser: In addition to importing Android Samples, the Code Sample Browser is a menu option inside Android Studio 2.2 Preview that allows you to find high-quality, Google-provided Android code samples based on the currently highlighted symbol in your project. To use the feature, highlight a Variables, Types and Methods in your code then Right Click to show a context menu for Find Sample Code. The results are displayed in a bottom output box.   

Code Sample Browser

Build

• CMake and NDK-Build: For those of you using the Android NDK, Android Studio now supports building CMake and NDK-Build Android app projects by pointing Gradle at your existing build files. Once you’ve added your cmake or ndk-build project to Gradle, Android Studio will automatically open your relevant Android code files for editing and debugging in Studio.

For CMake users, just add the path to your CMList.txt file in the externalNativeBuild section of your Gradle file:

CMake Build in Android Studio

For NDK-Build Users, just add the path to your *.mk file in the section of your Gradle file:

NDK-Build in Android Studio

To use incremental build with Jack add the following to your build.gradle file:

Enable Jack Incremental Compile Option

Jack will automatically apply annotations processors in your classpath. To use an annotation processor at compile-time without bundling it in your apk, use the new annotationProcessor dependency scope:

Enable Jack Annotation Processing

• Merged Manifest Viewer: Figuring out how your AndroidManifest merges with your project dependencies based on build types, flavors and variants is now easier with Android Studio. Navigate to your AndroidManifest.xml and click on the new Merged Manifest bottom tab. Explore how each node of your AndroidManifest resolves with various project dependencies.  

Merged Manifest Viewer

Test

• Espresso Test Recorder: Sometimes writing UI tests can be tedious. With the Record Espresso UI tests feature, creating tests is now as easy as just using your app. Android Studio will capture all your UI interactions  and convert them into a fully reusable Espresso Test that you can run locally or even on Firebase Test lab. To use the recorder, go to the Run menu and select Record Espresso Test.

Espresso Test Recorder

• APK Analyzer: The new APK Analyzer helps you understand the contents and the sizes of different components in your APK. You can also use it to avoid 64K referenced method limit issues with your Dex files, diagnose ProGuard configuration issues, view merged AndroidManifest.xml file, and inspect the compiled resources file (resources.arsc). This can help you reduce your APK size and ensure your APK contains exactly the things you expect.

The APK Analyzer shows you both the raw file size as well as the download size of various components in your APK. The download size is the estimated size users need to download when the APK is served from Google Play. This information should help you prioritize where to focus in your size reduction efforts.

To use this new feature, click on the Build menu and select Analyze APK… Then, select any APK that you want to analyze.

APK Analyzer

• Java-aware C++ Debugger:  When debugging C++ code on targets running N and above, you can now use a single, Java language aware lldb instance. This debugger continues to support great lldb features like fast steps and memory watchpoints while also allowing you to stop on Java language breakpoints and view your Java language memory contents.

• Auto Debugger Selection: Android Studio apps can now use debugger type “Auto.” This will automatically enable the appropriate debugger -- the Java language aware C++ debugger if enabled and otherwise the hybrid debugger for C++ projects.  Projects exclusively using the Java language will continue to use the Java language debugger.

Enable Auto Debugger for C++

What's Next 

Download

If you are using a previous version of Android Studio, you can check for updates on the Canary channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). This update will download a new version, and not patch your existing copy of Android Studio. You can also download Android Studio 2.2 Preview from canary release site.

For the Android Studio 2.2 Preview, we recommend you run a stable version alongside the new canary. Check out the tools site on how to run two versions at the same time.

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. 

Today we announced that we’re adding Android apps to Chromebooks, which means users will be able to install the apps they know and love. Later this year you can expand your app’s reach to a new hardware platform and wider audience while maximizing the Google Play ecosystem. With expanded app availability, new use cases and improved workflows can be achieved for all Chromebook users, whether for personal use, for work or for education.  As a developer we encourage you to test your app as described here.

• Android Apps can be shown in 3 different window sizes to allow the best experience
• Users can multi-task with multiple Android apps in moveable windows along with a full desktop browser, all within the familiar Chrome OS interface.
• Keyboard, mouse, and touch input will seamlessly work together
• Users will get Android notifications on their Chromebooks
• Android apps benefit from the Wifi or Bluetooth connectivity setup by the user or the administrator
• File sharing is seamless between Chrome and Android apps through the Files app
• Performance of demanding apps such as games or design apps is excellent

Today, we’re enhancing our APIs, making it easier than ever for the developer community to integrate with Android Pay. With just a few lines of code, you can enable quick and seamless checkout to help increase purchase conversions and ongoing engagement.

• Earlier today, we announced Android Instant Apps, which gives users the ability to pay using Android Pay with a single tap, without the friction of getting a user to install the app to complete their transaction. 

Example of Android Pay in Android Instant Apps

• We’re opening the Android Pay API to all developers selling physical goods and services in markets where Android Pay is available—just sign up at developers.google.com/android-pay/
• We’ve teamed up with payment processors globally so developers can integrate Android Pay with their Android apps in just a few hours.

Example of Android Pay in PaymentRequest

• Enable users to add offers, loyalty cards and gift cards in the Android Pay app with the tap of a button. Simply add a deep link to an email, SMS message, push notification or within an app and you’re all set.
• Enroll new customers into a loyalty program in a variety of ways with the new simplified sign-up feature. Customers can sign-up either in store via a NFC tap or through a sign-up page linked from an Android Pay transaction notification.

Example sign-up feature for Walgreens Balance Reward®   via Save to Android Pay from transaction notification

Google Play reaches over 1 billion monthly active users giving developers the world’s largest app distribution platform. Last year, Play users installed apps 65 billion times. To keep that great momentum going, we’re continuing to listen to your feedback and invest in more ways to help you grow your app or game business. Today, we’re sharing new features that benefit developers of all sizes.

Users can now opt-in to beta tests from the Play Store

An example of a new collection for apps relating to buying a house

The pre-launch report in the Developer Console

Review benchmarks in the Developer Console

Developers can now reply to reviews on Google Play from platorms such as Zendesk and Conversocial

User acquisition country data in the Developer Console

The Play Console app	Playbook by Google Play

Android N Developer Preview is available to try on a range of devices

Multi-Window mode on Android N

• Speed: New layout designer and constraint layout, Espresso test recording and even faster builds
• Smarts: APK analyzer, Layout inspector, expanded Android code analysis and IntelliJ 2016.1
• Platform Support: Enhanced Jack compiler / Java 8 support, Expanded C++ support with CMake and NDK-Build, Firebase support and enhanced accessibility

New Layout Editor and Constraint Layout in Android Studio 2.2 Preview

Develop, Grow & Earn with Firebase

Develop

• Android N Developer Preview 3 — Get a look at the next release of Android N focused on performance, productivity and security. Even better, Android N is now ready to test on primary phones or tablets.
• Android VR — A rework of the entire Android stack in N to tailor it to provide high quality mobile VR experiences.
• Android Studio 2.2 Preview — Our new preview focuses on speed, smarts, and Android platform support. This major update includes a completely rewritten, feature-rich Layout Designer.
• Android Wear 2.0: A developer preview of the biggest platform update since we launched Android Wear two years ago. It includes updated design guidelines and APIs that make the watch even more useful for watch faces, messaging, and fitness. Apps on the watch can now be standalone, with direct network access to the cloud.
• Recording APIs: enables Android TV app developers and content providers to bring recording functionality to live channels.
• Google Play services 9.0 — In addition to Firebase, the next release includes new API updates for Ads, Nearby and Play Games services.
• Android Pay APIs — A new set of tools that includes support for mobile web, Instant Apps, Save to Android Pay and an API for issuers. We’ll have more to share during the session “Android Pay everywhere: New developments” later today at 2:00 PM PT Stage 1 Hercules.
• Progressive Web Apps — A new set of capabilities to build app-like mobile websites that work reliably on the worst network connections and can send notifications to re-engage users.
• Credentials API — The latest version of Chrome now supports the Credential Management API, allowing sites to interact with the browser’s credential manager to improve the sign in experience for users. The API enables users to sign in with one tap and lets them automatically sign back in when returning to the site.
• Accelerated Mobile Pages — Check out the AMP project, an open source initiative that is helping publishers create mobile-optimized content once and have it load instantly everywhere.

Grow & Earn

• Reach a global audience on Google Play — New and powerful tools to help you grow your business: discover and join beta tests from the Play Store (including a new Early Access section), discover collections of complementary apps to help users solve complex tasks, see how your app runs on real devices with a new pre-launch report, get insights and benchmarks for reviews and user acquisition, monitor your app stats and get notifications when your updates are live with the new Play Console app, and more.
• Android Instant Apps — With Android Instant Apps, users can open your app simply by tapping on a link, even if they don’t have the app installed. Instant Apps is compatible with Android Jelly Bean and later, reaching over a billion users. We’re working with a small set of developers now, and we’ll be gradually expanding access.
• Building for billions — New resources to help you optimize your app and get your business ready to serve over a billion Android users around the world.
• Universal App Campaigns — Last year, we introduced Universal App Campaigns as a simple and powerful way to surface apps to the billions of users across Google Play, Search, YouTube, and the Google Display Network. We’re building on this success by expanding onto iOS and by helping developers use insights to optimize for lifetime value. See our new apps best practices.

What’s Next

• Awareness API: We'll be previewing a new, unified sensing platform that enables apps to be aware of all aspects of a user's context, while managing system health for you. Learn more at the "Introducing Awareness API: an easy way to make your apps context aware" session later today at 3:00 PM PT in Stage 5 Libra.
• Daydream — We’ll have more to share on how developers can start building Daydream apps during the “VR at Google” session tomorrow (May 19) at 9:00 AM PT in the Amphitheatre and livestreamed.
• Chromebooks — Hear from the team firsthand what’s new with Chromebooks tomorrow (May 19) at 11:00 AM PT in Stage 8 Crater.
• The Mobile Web — We’ll share what we’re doing to improve the mobile web experience for developers and users tomorrow (May 19) at 2:00 PM PT in the Amphitheatre.

Today at Google I/O, we announced the most significant Android Wear update since its launch two years ago: Android Wear 2.0. Based on what we’ve learned from users and developers, we're evolving the platform to improve key experiences on the watch, including watch faces, messaging, and fitness.

Android Wear 2.0 will be available to users this fall. We’re making a Developer Preview available today and plan to release additional updates throughout the summer, so please send us your feedback early and often. Also, please keep in mind that this preview is a work in progress, and is not yet intended for daily use.

What’s new?

• Standalone apps: Your Android Wear app can now access the internet directly over Bluetooth, Wi-Fi, or cellular, without relying on the Data Layer APIs. This means your app can continue to offer full functionality even if the paired phone is far away or turned off. Removing the requirement to use the Data Layer APIs also enables your app to offer the same functionality regardless of whether the watch is paired with an Android or iPhone. In addition, your app can receive push messages via Google Cloud Messaging and access AccountManager directly on the watch.
• New system UI: We’ve made a number of UI changes that will help users interact with your app more easily. A new notification design and app launcher make it easier to take action on notifications and launch your app, and a new watch face picker makes switching watch faces fast and fun. The system UI also adopts a dark color palette and makes better use of round displays. We recommend you test your existing Android Wear app and notifications with the new UI.
• Material design for wearables: The new Material Design for Wearables guide will help you make your app’s interface more consistent, intuitive, and beautiful. The new navigation drawer and action drawer components in the Wearable support library make it easy to align your app with the system UI’s new vertical layout. We’ve also provided guidance on how to adopt the dark color palette.
• Complications API: Complications are bite-sized pieces of information displayed to users directly on the watch face. Android Wear now has a system-wide framework to enable any app to show data on any watch face that implements the API. As an app developer, you can choose to publish your data to a wide variety of watch faces and make it easier for users to launch your app from the watch face. As a watch face developer, you can rely on data from a rich ecosystem of Wear apps without having to worry about sourcing it yourself.
• Input methods: Keyboard and handwriting input methods open up new ways to accept text from users on the watch. You can now use these new input methods in your app via RemoteInput and EditText, and notifications that already use RemoteInput for voice replies will automatically support the new input methods. We’ve ported over the full Android input method framework to the watch, so you can even create your own custom input methods if you wish.
• New MessagingStyle notification: Android Wear 2.0 includes a new notification template with a layout optimized for quick and responsive messaging. This template is also available on phones and tablets using Android N, so creating a great cross-device messaging experience is a breeze.
• Google Fit platform: Improvements to the Google Fit platform make it easier for your app to use fitness data and detect activity. You can register a PendingIntent to be notified of changes in the fitness data store, so you don’t have to keep querying for changes to weight, nutrition, and other data types. It’s also easier for your app to get a consistent daily step count on Android Wear -- with HistoryApi.readDailyTotal(), a step recording subscription is no longer required. Finally, apps will soon be able to detect (with consent) when the user starts walking, running, or biking.
• Support for Android N: Your Android Wear app can now take advantage of the latest Android N features such as Data Saver and Java 8 Lambda support. Also, let’s not forget the new emojis!

Get started and give us feedback!

1. Take a video tour of the Android Wear 2.0 developer preview
2. Update to Android Studio v2.1.1 or later
3. Visit the Android Wear 2.0 Developer Preview site for downloads and documentation
4. Get the emulator system images through the SDK Manager or download the device system images
5. Test your app with your supported device or emulator
6. Give us feedback

Ensuring your apps are secure

• Email or user ID substitution attack After signing in with Google on Android, some apps directly send email or user ID in plain text to their backend server as the identity credential. These server endpoints enable a malicious attacker to easily forge a request and gain access to any user’s account by guessing their email / user ID.
  
  Figure 1. Email / User ID Substitution Attack
  We see a number of developers implement this anti-pattern by using getAccountName or getId from the Plus.API and sending it to their backend.
  
  Problematic implementations, DO NOT COPY
  

• Access token substitution attack After signing in with Google on Android, many apps send an access token obtained via GoogleAuthUtil.getToken to their backend server as the identity assertion. Access tokens are bearer tokens and backend servers cannot easily check if the token is issued to them. A malicious attacker can phish the user to sign-in on another application and use that different access token to forge a request to your backend.
  
  Figure 2. Access Token Substitution Attack
  Many developers implement this anti-pattern by using GoogleAuthUtil to retrieve an access token and sending it to their server to authenticate like in the following example:
  
  Problematic implementation, DO NOT COPY

1. Many developers who have built the above anti-patterns into their apps simply call our tokenInfo (www.googleapis.com/oauth2/v3/tokeninfo) which is debug-only or unnecessarily call the G+ (www.googleapis.com/plus/v1/people/me) endpoint for user’s profile information. These apps should instead implement our recommended ID token flow explained in this blog post. Check out migration guide to move to a both secure and efficient pattern.
2. If your server needs access to other Google services, e.g. Drive, you should use server auth code flow. You can also check out this blogpost. Worth mentioning, you can also get an ID token using server auth code flow, from which you can retrieve user id / email / name / profile url without additional network call. Check out the migration guide.

Improving the user experience and performance of your apps

Requesting unnecessary permissions and displaying redundant user experience

Getting ID Token from GoogleAuthUtil for your backend

Getting auth code from GoogleAuthUtil for your backend

Should I ever use GoogleAuthUtil.getToken?

Posted by Matt Goodridge - Google Play for Work Product Manager

Last year, we introduced Android for Work, a program designed to pair the strength of the Android platform with support from the rich ecosystem of OEMs (device manufacturers like Samsung), EMMs (Enterprise Mobility Managers) and carriers with the goal of transforming the workplace. This means that developers get the support they need to develop apps that configure to meet business needs without customization.

With Android for Work, developers have been able to build apps for business and make them available via Google Play for Work to all types of industries. No matter the place or use case, Android for Work has helped lead businesses to foster employee productivity and creativity through increased mobility.

Today we are announcing the Android for Work DevHub, a place for developers to keep up with Android in the workplace and engage fellow business app developers in an open forum. Android for Work DevHub members will receive access to Google Play for Work and Android for Work product betas and developer events and will have the opportunity to learn from Google experts on topics like how to:

• leverage tools and resources provided by the AppConfig Community, which established a standard that provides Android developers a simple way set up app configurations,
• improve app security by integrating with Android for Work APIs,
• get an app featured on Google Play for Work,
• and more…

Among the early members of the Android for Work DevHub is Keeper, a mobile-first company committed to securing corporate credentials and sensitive information. Darren Guccione, Keeper’s CEO and co-founder, said: “Having our team be able to talk with Google experts as a part of the Android for Work DevHub has been very helpful in optimizing Keeper, as an essential product, for the workplace.” In addition to Keeper, select developers across an array of industries are already represented in the Android for Work DevHub, and—starting today—any business developer can apply to become a member, too.

To learn more about Android for Work, join us at Google I/O Thursday, May 19th at 2pm on Stage 10 Cassiopeia. I’ll be joined live on stage with James Kelly, product manager in Android for Work and Rich Hyndman, and Android developer advocate, to walk through the latest developments in Android for Work that will help you make awesome apps for businesses and to meet the Android for Work team in-person at our shop to see the Android for Work retail experience.

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!

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.

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

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

Posted by Dan Austin and Jeff Vander Stoep, Android Security team

To help make Android more secure, we encourage and reward researchers who discover vulnerabilities. In 2015, a series of bugs in mediaserver’s libstagefright were disclosed to Google. We released updates for these issues with our August and September 2015 security bulletins.

In addition to addressing issues on a monthly basis, we’ve also been working on new security features designed to enhance the existing security model and provide additional defense in-depth. These defense measures attempt to achieve two goals:

• Prevention: Stop bugs from becoming vulnerabilities
• Containment: Protect the system by de-privileging and isolating components that handle untrusted content

Prevention

Most of the vulnerabilities found in libstagefright were heap overflows resulting from unsigned integer overflows. A number of integer overflows in libstagefright allowed an attacker to allocate a buffer with less space than necessary for the incoming data, resulting in a buffer overflow in the heap.

The result of an unsigned integer overflow is well defined, but the ensuing behavior could be unexpected or unsafe. In contrast, signed integer overflows are considered undefined behavior in C/C++, which means the result of an overflow is not guaranteed, and the compiler author may choose the resulting behavior—typically what is fastest or simplest. We have added compiler changes that are designed to provide safer defaults for both signed and unsigned integer overflows.

The UndefinedBehaviorSanitizer (UBSan) is part of the LLVM/Clang compiler toolchain that detects undefined or unintended behavior. UBSan can check for multiple types of undefined and unsafe behavior, including signed and unsigned integer overflow. These checks add code to the resulting executable, testing for integer overflow conditions during runtime. For example, figure 1 shows source code for the parseChunk function in the MPEG4Extractor component of libstagefright after the original researcher-supplied patch was applied. The modification, which is contained in the black box below, appears to prevent integer overflows from occurring. Unfortunately, while SIZE_MAX and size are 32-bit values, chunk_size is a 64-bit value, resulting in an incomplete check and the potential for integer overflow. In the line within the red box, the addition of size and chunk_size may result in an integer overflow and creation of buffer smaller than size elements. The subsequent memcpy could then lead to exploitable memory corruption, as size + chunk_size could be less than size, which is highlighted in the blue box. The mechanics of a potential exploit vector for this vulnerability are explained in more detail by Project Zero.

Figure 1. Source code demonstrating a subtle unsigned integer overflow.

Figure 2 compares assembly generated from the code segment above with a second version compiled with integer sanitization enabled. The add operation that results in the integer overflow is contained in the red box.

In the unsanitized version, size (r6) and chunk_size (r7) are added together, potentially resulting in r0 overflowing and being less than size. Then, buffer is allocated with the size specified in r0, and size bytes are copied to it. If r0 is less than r6, this results in memory corruption.

In the sanitized version, size (r7) and chunk_size (r5) are added together with the result stored in r0. Later, r0 is checked against r7, if r0 is less than r7, as indicated by the CC condition code, r3 is set to 1. If r3 is 1, and the carry bit was set, then an integer overflow occurred, and an abort is triggered, preventing memory corruption.

Note that the incomplete check provided in the patch was not included in figure 2. The overflow occurs in the buffer allocation’s add operation. This addition triggers an integer sanitization check, which turns this exploitable flaw into a harmless abort.

Figure 2. Comparing unsanitized and sanitized compiler output.

While the integer sanitizers were originally intended as code hygiene tools, they effectively prevent the majority of reported libstagefright vulnerabilities. Turning on the integer overflow checks was just the first step. Preventing the runtime abort by finding and fixing integer overflows, most of which are not exploitable, represented a large effort by Android's media team. Most of the discovered overflows were fixed and those that remain (mostly for performance reasons) were verified and marked as safe to prevent the runtime abort.

In Android N, signed and unsigned integer overflow detection is enabled on the entire media stack, including libstagefright. This makes it harder to exploit integer overflows, and also helps to prevent future additions to Android from introducing new integer overflow bugs.

Containment

For Android M and earlier, the mediaserver process in Android was responsible for most media-related tasks. This meant that it required access to all permissions needed by those responsibilities and, although mediaserver ran in its own sandbox, it still had access to a lot of resources and capabilities. This is why the libstagefright bugs from 2015 were significant—mediaserver could access several important resources on an Android device including camera, microphone, graphics, phone, Bluetooth, and internet.

A root cause analysis showed that the libstagefright bugs primarily occurred in code responsible for parsing file formats and media codecs. This is not surprising—parsing complex file formats and codecs while trying to optimize for speed is hard, and the large number of edge cases makes such code susceptible to both accidental and malicious malformed inputs.

However, media parsers do not require access to most of the privileged permissions held by mediaserver. Because of this, the media team re-architected mediaserver in Android N to better adhere to the principle of least privilege. Figure 3 illustrates how the monolithic mediaserver and its permissions have been divided, using the following heuristics:

• parsing code moved into unprivileged sandboxes that have few or no permissions
• components that require sensitive permissions moved into separate sandboxes that only grant access to the specific resources the component needs. For example, only the cameraserver may access the camera, only the audioserver may access Bluetooth, and only the drmserver may access DRM resources.

Figure 3. How mediaserver and its permissions have been divided in Android N.

Comparing the potential impact of the libstagefright bugs on Android N and older versions demonstrates the value of this strategy. Gaining code execution in libstagefright previously granted access to all the permissions and resources available to the monolithic mediaserver process including graphics driver, camera driver, or sockets, which present a rich kernel attack surface.

In Android N, libstagefright runs within the mediacodec sandbox with access to very few permissions. Access to camera, microphone, photos, phone, Bluetooth, and internet as well as dynamic code loading are disallowed by SELinux. Interaction with the kernel is further restricted by seccomp. This means that compromising libstagefright would grant the attacker access to significantly fewer permissions and also mitigates privilege escalation by reducing the attack surface exposed by the kernel.

Conclusion

The media hardening project is an ongoing effort focused on moving functionality into less privileged sandboxes and further reducing the permissions granted to those sandboxes. While the techniques discussed here were applied to the Android media framework, they are suitable across the Android codebase. These hardening techniques—and others—are being actively applied to additional components within Android. 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 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 security+asi@android.com.

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!

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.

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.

Posted by Josh Gordon, Developer Advocate

Channel surfing is a popular way of watching TV. You pick up the remote, lean back, and flip through channels to see what’s on. On Android TV, app developers can create their own channel-like experiences using the TV Input Framework.

To the user, the channels you create look and feel just like regular TV channel. But behind the scenes, they stream video over the internet. For example, you can create a channel from a video playlist.

Watch this DevByte for an overview of how to build to a channel, and see the sample app and developer training for more info. The sample shows how to work with a variety of media formats, including HLS, MPEG-Dash, and HTTP Progressive.

If you already have an app that streams video, consider also making your content available as a channel. It’s a great opportunity to increase engagement. We’re excited to see what you develop, and look forward to seeing your content on the big screen!

Posted by Alex Klyubin, Android Security team

When your app communicates with servers using cleartext network traffic, such as HTTP, the traffic risks being eavesdropped upon and tampered with by third parties. This may leak information about your users and open your app up to injection of unauthorized content or exploits. Ideally, your app should use secure traffic only, such as by using HTTPS instead of HTTP. Such traffic is protected against eavesdropping and tampering.

Many Android apps already use secure traffic only. However, some of them occasionally regress to cleartext traffic by accident. For example, an inadvertent change in one of the server components could make the server provide the app with HTTP URLs instead of HTTPS URLs. The app would then proceed to communicate in cleartext, without any user-visible symptoms. This situation may go unnoticed by the app’s developer and users.

Even if you believe your app is only using secure traffic, make sure to use the new mechanisms provided by Android Marshmallow (Android 6.0) to catch and prevent accidental regressions.

New protection mechanisms

For apps which only use secure traffic, Android 6.0 Marshmallow (API Level 23) introduced two mechanisms to address regressions to cleartext traffic: (1) in production / installed base, block cleartext traffic, and (2) during development / QA, log or crash whenever non-TLS/SSL traffic is encountered. The following sections provide more information about these mechanisms.

Block cleartext traffic in production

To protect the installed base of your app against regressions to cleartext traffic, declare android:usesCleartextTraffic=”false” attribute on the application element in your app’s AndroidManifest.xml. This declares that the app is not supposed to use cleartext network traffic and makes the platform network stacks of Android Marshmallow block cleartext traffic in the app. For example, if your app accidentally attempts to sign in the user via a cleartext HTTP request, the request will be blocked and the user’s identity and password will not leak to the network.

You don’t have to set minSdkVersion or targetSdkVersion of your app to 23 (Android Marshmallow) to use android:usesCleartextTraffic. On older platforms, this attribute is simply ignored and thus has no effect.

Please note that WebView does not yet honor this feature.

And under certain circumstances cleartext traffic may still leave or enter the app. For example, Socket API ignores the cleartext policy because it does not know whether the data it transmits or receives can be classified as cleartext. Android platform HTTP stacks, on the other hand, honor the policy because they know whether traffic is cleartext.

Google AdMob is also built to honor this policy. When your app declares that it does not use cleartext traffic, only HTTPS-only ads should be served to the app.

Third-party network, ad, and analytics libraries are encouraged to add support for this policy. They can query the cleartext traffic policy via the NetworkSecurityPolicy class.

Detect cleartext traffic during development

To spot cleartext traffic during development or QA, StrictMode API lets you modify your app to detect non-TLS/SSL traffic and then either log violations to system log or crash the app (see StrictMode.VmPolicy.Builder.detectCleartextNetwork()). This is a useful tool for identifying which bits of the app are using non-TLS/SSL (and DLTS) traffic. Unlike the android:usesCleartextTraffic attribute, this feature is not meant to be enabled in app builds distributed to users.

Firstly, this feature is supposed to flag secure traffic that is not TLS/SSL. More importantly, TLS/SSL traffic via HTTP proxy also may be flagged. This is an issue because as a developer, you have no control over whether a particular user of your app may have configured their Android device to use an HTTP proxy. Finally, the implementation of the feature is not future-proof and thus may reject future TLS/SSL protocol versions. Thus, this feature is intended to be used only during the development and QA phase.

Declare finer-grained cleartext policy in Network Security Config

Android N offers finer-grained control over cleartext traffic policy. As opposed to android:usesCleartextTraffic attribute, which applies to all destinations with which an app communicates, Android N’s Network Security Config lets an app specify cleartext policy for specific destinations. For example, to facilitate a more gradual transition towards a policy that does not allow cleartext traffic, an app can at first block accidental cleartext only for communication with its most important backends and permit cleartext to be used for other destinations.

Next steps

It is a security best practice to only use secure network traffic for communication between your app and its servers. Android Marshmallow enables you to enforce this practice, so give it a try!

As always, we appreciate feedback and welcome suggestions for improving Android. Contact us at security@android.com. HTTPS, Android-Security

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.

Google Play has seen tremendous growth over the past year, reaching more than 1 billion Android users across 190 countries. As a way to recognize our incredible developer community and highlight some of the best apps and games, we’re kicking off our first-ever Google Play Awards.

The program will showcase five nominees across 10 award categories and feature them in a dedicated collection on Google Play. Nominees were selected by a panel of experts on the Google Play team based on criteria emphasizing app quality, innovation, and having a launch or major update in the last 12 months. The winners of each category will be announced at Google I/O in May.

The full list of categories and nominees are below:

Standout Startup

Apps from new developers that offer a unique experience while achieving strong install growth. And the nominees are...

Dubsmash	Hopper	Musical.ly	Robinhood	Vrse

Standout Indie

Games from indie developers that focus on artistic design, high quality and innovative gameplay. And the nominees are...

Alphabear	Alto’s Adventure	Fast like a Fox	Neko Atsume: Kitty Collector	Prune

Best Families App

Apps or games with family friendly design that encourage creativity and exploration. And the nominees are...

Card Wars - Adventure Time	LEGO Jurassic World™	My Very Hungry Caterpillar	Thinkrolls 2	Toca Nature

Best Use of Material Design

First-class implementation of material design concepts that deliver an immersive and innovative user experience. And the nominees are...

Bring!	Robinhood	The Fabulous	Todoist	Vevo

Best Use of Google Play Game Services

High quality games with several strong GPGS feature implementations. And the nominees are...

Sea Battle 2	Table Tennis Touch	Tapventures	TowerMadness 2	Zombie Highway 2

Early Adopter

Early adopter of a nascent technology or platform, providing a delightful user experience. And the nominees are...

Glide	Mechanic Escape	Minecraft: Story Mode	World Around Me	Zumper

Go Global

Apps or games with great localization and culturalization, or subject matter appeal, across multiple regions. And the nominees are...

Dragon Ball Z Dokkan Battle	Freeletics Bodyweight	Memrise	Musixmatch	Pokémon Shuffle Mobile

Most Innovative

Apps or games offering a highly engaging novelty experience or unique benefit. And the nominees are...

Fast like a Fox	NYT VR	SmartNews	The Fabulous	This War of Mine

Best App

A true representation of beautiful design, intuitive UX and high user appeal, quality and rating. And the nominees are...

BuzzFeed News	Colorfy	Houzz	TuneIn Radio	Yummly

Best Game

Games with strong mechanics, informative tutorial, broad appeal and tasteful design. And the nominees are...

Alphabear	Clash of Kings	Clash Royale	MARVEL Future Fight	Star Wars™: Galaxy of Heroes

Join us live at the ceremony on May 19th at 7:00 pm PDT on stage 7 at Google I/O or via the live stream. You can also track the conversation on Twitter and G+ using the hashtags #io16.

Posted by Hoi Lam, Android Wear Developer Advocate

Android Wear is about choice. From the beginning, users could choose the style they wanted, including watches with circular screens. With Android Wear API 23, we have enabled even better developer support so that you can code delightful experiences backed by beautiful code. The key component of this is the new round resource identifier which helps you separate resource files such as layouts, dimens between round and square devices. In this blog post, I will lay out the options that developers have and why you should consider dimens.xml! In addition, I will outline how best to deal with devices which have a chin.

Getting started? Consider BoxInsetLayout!

If all your content can fit into a single square screen, use the BoxInsetLayout. This class has been included in the Wearable Support Library from the start and helps you put all the content into the middle square area of the circular screen and is ignored by square screens. For details on how to use the BoxInsetLayout, refer to the Use a Shape-Aware Layout section in our developer guide.

Without BoxInsetLayout	With BoxInsetLayout

Goodbye WatchViewStub, Hello layout-round!

Developers have been able to specify different layouts for square and round watches using WatchViewStub from the beginning. With Android Wear API 23, this has become even easier. Developers can put different layouts into layout-round and layout folders. Previously with WatchViewStub, developers needed to wait until the layout was inflated before attaching view elements, this added significant complexity to the code. This is eliminated using the -round identifier:

 <?xml version="1.0" encoding="utf-8"?>  
 <android.support.wearable.view.WatchViewStub    
     xmlns:android="http://schemas.android.com/apk/res/android"  
     xmlns:app="http://schemas.android.com/apk/res-auto"  
     xmlns:tools="http://schemas.android.com/tools"  
     android:id="@+id/watch_view_stub"  
     android:layout_width="match_parent"  
     android:layout_height="match_parent"  
     app:rectLayout="@layout/rect_activity_main"  
     app:roundLayout="@layout/round_activity_main"  
     tools:context="com.android.example.watchviewstub.MainActivity"  
     tools:deviceIds="wear"></android.support.wearable.view.WatchViewStub>

  
 protected void onCreate(Bundle savedInstanceState) {  
   super.onCreate(savedInstanceState);  
   setContentView(R.layout.activity_main);  
   final WatchViewStub stub = (WatchViewStub) findViewById(R.id.watch_view_stub);  
   stub.setOnLayoutInflatedListener(new WatchViewStub.OnLayoutInflatedListener() {  
     @Override  
     public void onLayoutInflated(WatchViewStub stub) {  
       mTextView = (TextView) stub.findViewById(R.id.text);  
     }  
   });  
 }  

 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     mTextView = (TextView) findViewById(R.id.text);    
 }  

That said, since WatchViewStub is part of the Android Wear Support Library, if your current code uses it, it is not a breaking change and you can refactor your code at your convenience. In addition to the -round identifier, developers also use the -notround idenifier to separate resources. So why would you want to use it in place of the default layout? It’s a matter of style. If you have a mixture of layouts, you might consider organising layouts in this way:

• layout/ - Layouts which works for both circular and square watches
• layout-round/ and layout-notround/ - Screen shape specific layouts

An even better way to develop for round - values-round/dimens.xml

Maintaining multiple layout files is potentially painful. Each time you add a screen element, you need to go to all the layout files and add this. With mobile devices, you will usually only do this to specify different layouts for phones and tablets and rarely for different phone resolutions. For watches, unless your screen layout is significantly different between round and square (which is rare based on the applications I have seen thus far), you should consider using different dimens.xml instead.

As I experimented with the -round identifier, I found that the easiest way to build for round and square watches is actually by specifying values/dimens.xml and values-round/dimens.xml. By specifying different padding settings, I am able to create the following layout with the same layout.xml file and two dimens files - one for square and one for round. The values used suits this layout, you should experiment with different values to see what works best:

values-round/dimens.xml	values/dimens.xml
<dimen name="header_start_padding">36dp</dimen>    <dimen name="header_end_padding">22dp</dimen>    <dimen name="list_start_padding">36dp</dimen>    <dimen name="list_end_padding">22dp</dimen>	<dimen name="header_start_padding">16dp</dimen>    <dimen name="header_end_padding">16dp</dimen>    <dimen name="list_start_padding">10dp</dimen>    <dimen name="list_end_padding">10dp</dimen>

Before API 23, to do the same would have involved a significant amount of boilerplate code manually specifying the different dimensions for all elements on the screen. With the -round identifier, this is now easy to do in API 23 and is my favourite way to build round / square layouts.

Don’t forget the chin!

Some watches have an inset (also know as a “chin”) in an otherwise circular screen. So how should you can you build a beautiful layout while keeping your code elegant? Consider this design:

activity_main.xml  <FrameLayout      ...>      <android.support.wearable.view.CircledImageView        android:id="@+id/androidbtn"        android:src="@drawable/ic_android"        .../>      <ImageButton        android:id="@+id/lovebtn"        android:src="@drawable/ic_favourite"        android:paddingTop="5dp"        android:paddingBottom="5dp"        android:layout_gravity="bottom"        .../>    </FrameLayout>

If we are to do nothing, the heart shape button will disappear into the chin. Luckily, there’s an easy way to fix this with fitsSystemWindows:

 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/ic_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
    android:fitsSystemWindows="true"  
     .../>  

For the eagle-eyed (middle image of the screen shown below under “fitsSystemWindows=”true””), you might noticed that the top and bottom padding that we have put in is lost. This is one of the main side effect of using fitsSystemWindows. This is because fitsSystemWindows works by overriding the padding to make it fits the system window. So how do we fix this? We can replace padding with InsetDrawables:

inset_favourite.xml

 <inset  
   xmlns:android="http://schemas.android.com/apk/res/android"  
   android:drawable="@drawable/ic_favourite" 
   android:insetTop="5dp"  
   android:insetBottom="5dp" />  

activity_main.xml

 <ImageButton  
     android:id="@+id/lovebtn"  
     android:src="@drawable/inset_favourite"  
     android:paddingTop="5dp"  
     android:paddingBottom="5dp"  
     android:fitsSystemWindows="true"  
     .../>  

Although the padding setting in the layout will be ignored, the code is tidier if we remove this redundant code.

Do nothing	fitsSystemWindows=”true”	fitsSystemWindows=”true” and use InsetDrawable

If you require more control than what is possible declaratively using xml, you can also programmatically adjust your layout. To obtain the size of the chin you should attach a View.OnApplyWindowInsetsListener to the outermost view of your layout. Also don’t forget to call v.onApplyWindowInsets(insets). Otherwise, the new listener will consume the inset and inner elements which react to insets may not react.

How to obtain the screen chin size programmatically

MainActivity.java

 private int mChinSize;  
 protected void onCreate(Bundle savedInstanceState) {  
     super.onCreate(savedInstanceState);  
     setContentView(R.layout.activity_main);  
     // find the outermost element  
     final View container = findViewById(R.id.outer_container);  
     // attach a View.OnApplyWindowInsetsListener  
     container.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {  
         @Override  
         public WindowInsets onApplyWindowInsets(View v, WindowInsets insets) {  
             mChinSize = insets.getSystemWindowInsetBottom();  
             // The following line is important for inner elements which react to insets  
             v.onApplyWindowInsets(insets); 
             return insets;  
     }  
   });  
 }  

Last but not least, remember to test your code! Since last year, we have included several device images for Android Wear devices with a chin to make testing easier and faster:

Square peg in a round hole no more!

Android Wear has always been about empowering users to wear what they want. A major part in enabling this is the round screen. With API 23 and the -round resource identifier, it is easier than ever to build for both round and square watches - delightful experiences backed by beautiful code!

Additional Resources

Why would I want to fitsSystemWindows? by Ian Lake - Best practice for using this powerful tool including its limitations. ScreenInfo Utility by Wayne Piekarski - Get useful information for your display including DPI, chin size, etc.

Posted by Wayne Piekarski, Developer Advocate, Android Wear

If you’re an Android Wear developer, we wanted to let you know of a change you might need to make to your app to improve the performance of your user’s devices. If your app is using BIND_LISTENER intent filters in your manifest, it is important that you are aware that this API has been deprecated on all Android versions. The new replacement API introduced in Google Play Services 8.2 is more efficient for Android devices, so developers are encouraged to migrate to this as soon as possible to ensure the best user experience. It is important that all Android Wear developers are aware of this change and update their apps as soon as possible.

Limitations of BIND_LISTENER API

When Android Wear introduced the WearableListenerService, it allowed you to listen to changes via the BIND_LISTENER intent filter in the AndroidManifest.xml. These changes included data item changes, message arrivals, capability changes, and peer connects/disconnects.

The WearableListenerService starts whenever any of these events occur, even if the app is only interested in one type. When a phone has a large number of apps using WearableListenerService and BIND_LISTENER, a watch appearing or disappearing can cause many services to start up. This applies memory pressure to the device, causing other activities and services to be shut down, and generates unnecessary work.

Fine-grained intent filter API

In Google Play Services 8.2, we introduced a new fine-grained intent filter mechanism that allows developers to specify exactly what events they are interested in. For example, if you have multiple listener services, use a path prefix to filter only those data items and messages meant for the service, with syntax like this:

 <service android:name=".FirstExampleService">  
   <intent-filter>  
       <action android:name="com.google.android.gms.wearable.DATA_CHANGED" />  
       <action android:name="com.google.android.gms.wearable.MESSAGE_RECEIVED" />  
       <data android:scheme="wear" android:host="*" android:pathPrefix="/FirstExample" />  
   </intent-filter>  
 </service>  

There are intent filters for DATA_CHANGED, MESSAGE_RECEIVED, CHANNEL_EVENT, and CAPABILITY_CHANGED. You can specify multiple elements, and if any of them match, it will call your service and filter out anything else. If you do not include a element, all events will be filtered out and your service will never be called, so make sure to include at least one. You should be aware that registering in an AndroidManifest.xml for CAPABILITY_CHANGED will cause your service to be called any time a device advertising this capability appears or disappears, so you should use this only if there is a compelling reason.

Live listeners

If you only need these events when an Activity or Service is running, then there is no need to register a listener in AndroidManifest.xml at all. Instead, you can use addListener() live listeners, which will only be active when the Activity or Service is running, and will not impact the device otherwise. This is particularly useful if you want to do live status updates for capabilities being available in an Activity, but with no further background impact. In general, you should try to use addListener(), and only use AndroidManifest.xml when you need to receive events all the time.

Best practices

In general, you should only use a listener in AndroidManifest.xml for events that must launch your service. For example, if your watch app needs to send an interactive message or data to the phone.

You should try to limit the number of wake-ups of your service by using filters. If most of the events do not need to launch your app, then use a path and a filter that only matches the event you need. This is critical to limit the number of launches of your service.

If you have other cases where you do not need to launch a service, such as listening for status updates in an Activity, then register a live listener only for the duration it is needed.

Documentation

There is more information available about Data Layer events and the use of WearableListenerService, and tags in the manifest. Android Studio has a guide with a summary of how to convert to the new API. The Android Wear samples also show best practices in the use of WearableListenerService, such as DataLayer and XYZTouristAttractions. The changes needed are very small, and can be seen in this git diff from one of the samples here.

Removal of BIND_LISTENER

With the release of Android Studio 2.1, lint rules have been added that flag the use of BIND_LISTENER as a fatal error, and developers will need to make a small change to the AndroidManifest.xml to declare accurate intent filters. If you are still using BIND_LISTENER, you will receive the following error:

 AndroidManifest.xml:11: Error: The com.google.android.gms.wearable.BIND_LISTENER action is deprecated. [WearableBindListener]  
          <action android:name="com.google.android.gms.wearable.BIND_LISTENER" />  
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  

This will only impact developers who are recompiling their apps with Android Studio 2.1 and will not affect existing apps on user’s devices.

For developers who are using Google Play Services earlier than 8.2, the lint rules will not generate an error, but you should update to a newer version and implement more accurate intent filters as soon as possible.

In order to give users the best experience, we plan to disable BIND_LISTENER in the near future. It is therefore important that developers take action now, to avoid any future disruption experienced by users of their apps.

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

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:

• Khronos’s Vulkan resources, including overviews, reference pages, specification, and community demos
• Android’s documentation for Vulkan
• Android Vulkan samples
• Android Vulkan tutorials
• LunarG’s LunarXchange has resources for Windows and Linux Vulkan development

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().

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

Posted by Jamal Eason, Product Manager, Android

Android Studio 2.0 is the fastest way to build high quality, performant apps for the Android platform, including phones and tablets, Android Auto, Android Wear, and Android TV. As the official IDE from Google, Android Studio includes everything you need to build an app, including a code editor, code analysis tools, emulators and more. This new and stable version of Android Studio has fast build speeds and a fast emulator with support for the latest Android version and Google Play Services.

Android Studio is built in coordination with the Android platform and supports all of the latest and greatest APIs. If you are developing for Android, you should be using Android Studio 2.0. It is available today as a easy download or update on the stable release channel.

Android Studio 2.0 includes the following new features that Android developer can use in their workflow :

• Instant Run - For every developer who loves faster build speeds. Make changes and see them appear live in your running app. With many build/run accelerations ranging from VM hot swapping to warm swapping app resources, Instant Run will save you time every day.
• Android Emulator - The new emulator runs ~3x faster than Android’s previous emulator, and with ADB enhancements you can now push apps and data 10x faster to the emulator than to a physical device. Like a physical device, the official Android emulator also includes Google Play Services built-in, so you can test out more API functionality. Finally, the new emulator has rich new features to manage calls, battery, network, GPS, and more.
• Cloud Test Lab Integration - Write once, run anywhere. Improve the quality of your apps by quickly and easily testing on a wide range of physical Android devices in the Cloud Test Lab right from within Android Studio.
• App Indexing Code Generation & Test - Help promote the visibility your app in Google Search for your users by adding auto-generated URLS with the App Indexing feature in Android Studio. With a few click you can add indexable URL links that you can test all within the IDE.
• GPU Debugger Preview - For those of you developing OpenGL ES based games or apps, you can now see each frame and the GL state with the new GPU debugger. Uncover and diagnosis GL rendering issues by capturing and analyzing the GPU stream from your Android device.
• IntelliJ 15 Update - Android Studio is built on the world class Intellij coding platform. Check out the latest Intellij features here.

Instant Run

Today, mobile platforms are centered around speed and agility. And yet, building for mobile can sometimes feel clunky and slow. Instant Run in Android Studio is our solution to keep you in a fast and fluid development flow. The feature increases your developer productivity by accelerating your edit, build, run cycles. When you click on the Instant Run button (), Instant Run will analyze the changes you have made and determine how it can deploy your new code in the fastest way.

Whenever possible, it will inject your code changes into your running app process, avoiding re-deployment and re-installation your APK. For some types of changes, an activity or app restart is required, but your edit, build and run cycles should still be generally much faster than before. Instant Run works with any Android Device or emulator running API 14 (Ice Cream Sandwich) or higher.

Since previewing Instant Run at the end of last year, we’ve spent countless hours incorporating your feedback and refining for the stable release. Look for even more acceleration in future releases because build speeds can never be too fast. To learn how you can make the most out of Instant Run in your app development today, please check out our Instant Run documentation.

Android Emulator

The new Android Emulator is up to 3x faster in CPU, RAM, & I/O in comparison to the previous Android emulator. And when you're ready to build, ADB push speeds are a whopping 10x faster! In most situations, developing on the official Android Emulator is faster than a real device, and new features like Instant Run will work best with the new Android emulator.

In addition to speed and performance, the Android Emulator has a brand user interface and sensor controls. Enhanced since the initial release, with the emulator you can drag and drop APKs for quick installation, resize and rescale the window, use multi-touch actions (pinch & zoom, pan, rotate, tilt) and much more.

Trying out the new emulator is as easy as updating your SDK Tools to 25.1.1 or higher, create a fresh Android Virtual Device using one of the recommended x86 system images and you are ready to go. Learn more about the Android Emulator by checking out the documentation.

Cloud Test Lab is a new service that allows you to test your app across a wide range of devices and device configurations at scale in the cloud. Once you complete your initial testing with your Android Emulator or Android device, Cloud Test Lab is a great extension to your testing process that provides you to run through a collection of tests against a portfolio of physical devices hosted in Google’s data centers. Even if you do not have tests explicitly written, Cloud Test Lab can perform a basic set of tests to ensure that your app does not crash.

The new interface in Android Studio allows you to configure the portfolio of tests you want to run on Cloud Test Lab, and allows you to also see the results of your tests. To learn more about the service go here.

It is now easier for your users to find your app in Google Search with the App Indexing API. Android Studio 2.0 helps you to create the correct URL structure in your app code and add attributes in your AndroidManifest.xml file that will work the Google App Indexing service. After you add the URLs to your app, can you test and validate your app indexing code as shown here:

Check out this link for more details about app indexing support in Android Studio.

If you are developing OpenGL ES games or graphics-intensive apps, you have a new GPU debugger with Android Studio 2.0. Although the GPU debugger is a preview, you can step through your app frame by frame to identify and debug graphics rendering issues with rich information about the GL state. For more details on how to setup your Android device and app to work with the tool, check out the tech documentations here.

Update

If you are using a previous version of Android Studio, you can check for updates on the Beta 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. If you developing for the N Developer Preview, check out this additional setup instructions.

Set Up Instant Run & Android Emulator

After you update to or download Android Studio 2.0, you should upgrade your projects to use Instant Run, and create a fresh Android Virtual Device (AVD) for the new Android emulator and you are on your way to a fast Android development experience.

Using Instant Run is easy. For each of your existing projects you will see a quick prompt to update your project to the new gradle plugin version (com.android.tools.build:gradle:2.0.0).

For all new app projects in Android Studio 2.0, Instant Run is on by default. Check out the documentation for more details.

We are already hard at work developing the next release of Android Studio. 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 new Google+ page or on Twitter.

Posted by Lily Sheringham, Google Play team

WeVideo is a video editing platform founded on a vision to make video creation accessible to anyone, anywhere. They first launched the popular WeVideo Video Editor app for Android, and since the latest update to the app, revenue on the platform has doubled every two months. In fact, almost 85% of their mobile users are on Android devices.

Watch Krishna Menon, President & CTO, and Oleg Tsaregorodtsev, Head of Mobile Development at WeVideo, explain how relaunching their app with material design increased user engagement by 100%. They also share how WeVideo improved monetization and installs using ratings & reviews, store listing experiments, and other features on Google Play.

Find out more about material design principles, and, learn how to find success on Google Play.

Posted by Mark Koudritsky, software engineer

There is a new addition in the arsenal of instruments used by Android and ChromeOS teams in the battle to measure and minimize touch and audio latency: the WALT Latency Timer.

When you use a mobile device, you expect it to respond instantly to your touch or voice: the more immediate the response, the more you feel directly connected to the device. Over the past few years, we have been trying to measure, understand, and reduce latency in our Chromebook and Android products.

Before we can reduce latency, we must first understand where it comes from. In the case of tapping a touchscreen, the time for a response includes the touch-sensing hardware and driver, the application, and the display and graphics output. For a voice command, there is time spent in sampling input audio, the application, and in audio output. Sometimes we have a mixture of these (for example, a piano app would include touch input and audio output).

Most previous work to study latency has focused on measuring a single round-trip latency number. For example, to measure audio latency, an app would measure time from app to speaker/mic and back to the app using the Dr. Rick O'Rang loopback audio dongle together with an appropriate app such as the Dr Rick O’Rang Loopback app or Superpowered Mobile Audio Latency Test App. Similarly, the TouchBot uses a fast camera to measure the round-trip delay from physical touch until a change on the screen is visible. While valuable, the problem with such a setup is that it’s very difficult to break down the latency into input vs output components.

An important innovation in WALT (a descendant of QuickStep) is that it synchronizes an external hardware clock with the Android device or Chromebook to within a millisecond. This allows it to measure input and output latencies separately as opposed to measuring a round-trip latency.

WALT is simple. The parts cost less than $50 and with some basic hobby electronics skills, you can build it yourself.

We’ve been using WALT within Google for Nexus and Chromebook development. We’re now opening this tool to app developers and anyone who wants to precisely measure real-world latencies. We hope that having readily accessible tools will help the industry as a whole improve and make all our devices more responsive to touch and voice.

Google Play lets you distribute your apps and games to over 1 billion active Android users around the world. With advances in space exploration and the advent of galactic tourism, there will be a high number of users beyond this world that developers need to start thinking about, too. Google Play can now help you reach them. We’ve added new features to the Google Play Developer Console and updated the material design guidelines, to help you design, test, and distribute your apps and games in space.

Here’s a look at how The Guardian, one of the largest English-news organizations in the world, enhanced its Android app to enable astronauts and space travellers to stay informed and up-to-date, while in orbit or on the surface of the moon.

"I am pleased to have The Guardian's application to test the growing Interplanetary Internet" says Vint Cerf, distinguished visiting scientist at the Jet Propulsion Laboratory and Google's Chief Internet Evangelist. "The interstellar version is in development and I'm looking forward to having more Google Play apps and games tested in space flight."

Get your apps and games ready for take off today.

Starting with Google Play services 8.3, we did a major revamp of the Google Sign-In APIs, supporting both client and server auth. Behind the scenes, these APIs use OAuth 2.0 tokens to ensure secure authentication and authorization. To maintain security, we provide tools in the Google Developers Console to register the clients using these tokens.

In this post, we’ll discuss the important task of registering OAuth clients for Google Sign-In, and the tools that we offer to make this as easy as possible.

Here are some scenarios that might apply to you:

1. Start by creating a project in the Google Developers Console, which registers the client app on your behalf.
2. If you have a backend server in your project, you’ll need an OAuth client ID for it, too.
3. And don't forget to register OAuth clients for other test and release versions of your app, too!

In this post, we’ll cover some details on this process and address common pitfalls.

Getting Started - Create a Project in the Google Developers Console.

If you have not used Google Sign-In before, you can start integrating the API into your app by following the ‘Get a configuration file’ steps on this site. You’ll be taken to a setup wizard that will create an OAuth 2.0 client ID as shown in Figure 1.

Once you’ve specified your app, you’ll be taken to a screen to choose and configure services such as Google Sign-In, Cloud Messaging or Google Analytics that you want your app to be able to use.

Choose Google Sign-In. In order to use it, you’ll need to get the SHA-1 of the signing certificate for your Android app. This can either be a debug or a release certificate, and for the purposes of this blog you’ll look at a debug one, but keep in mind that you’ll need to repeat this process for each package / certificate pair you end up using (described in the last section below).

You can get the debug SHA-1 using the keytool command like this:

keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

Once you have your SHA-1, enter it as seen in Figure 2.

Now that your project is set up, you can get started with integrating the Sign-In API. But if you need to configure your project to work with a backend server or additional package name / keystores, keep reading the sections below.

Server Config - Ensure your server is registered within the same project.

If you have your own web or cloud server with data for your application, you’ll need OAuth credentials for your backend. Details on doing this can be found in the ID token and server auth code documentation.

Before using these flows, you’ll need to make sure you register your web server correctly in the Google Developers Console. Once there, you’ll be asked to select your project. See Figure 3.

Once you’ve selected your project, press the ‘Continue’ button, and you’ll go directly to the Credentials tab where all credential types are managed. Check the “OAuth 2.0 client IDs” section, and you will see the “Web client” and “Android client for com.my.package.name” that were created for you by the setup wizard. See Figure 4.

Take note of the Client ID for for your Web client, you’ll need it for both your app and server as illustrated below. (If you’ve created your project in the past and there’s no OAuth 2.0 client ID with Type “Web application”, then you will need to create one by selecting ‘New Credentials’ -> ‘OAuth client ID’.)

If you use an ID token flow for backend authentication, when you start developing your Android app, request an ID token in your GoogleSignInOptions, supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestIdToken(serverClientId)
        .requestEmail()
        .build();

And then on your server, set the same OAuth client ID for your web application to be the audience:

GoogleIdTokenVerifier verifier =
    new GoogleIdTokenVerifier.Builder(transport, jsonFactory)
        .setAudience(Arrays.asList(serverClientId))
        .setIssuer("https://accounts.google.com")
        .build();

Successful verification will allow you to authenticate and issue a session for this newly signed-in user.

Alternatively, if you are using the server auth code flow for backend access to Google APIs, request a server auth code in your GoogleSignInOptions on Android, again supplying the web client ID for your server:

GoogleSignInOptions gso =
    new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN)
        .requestScopes(new Scope(Scopes.DRIVE_APPFOLDER))
        .requestServerAuthCode(serverClientId)
        .requestEmail()
        .build();

And then on the server, both the OAuth client ID and the “Client secret” will be useful. The server SDK from Google can directly consume a downloaded JSON configuration file. You can click the download icon to download the JSON file (as shown in Figure 4) and use below code to construct GoogleClientSecrets:

GoogleClientSecrets clientSecrets =
    GoogleClientSecrets.load(
        JacksonFactory.getDefaultInstance(),
        new FileReader(PATH_TO_CLIENT_SECRET_FILE));

At which point you can access authenticated Google APIs on behalf of the signed-in user. Note that the “client secret” is really a secret that you should never reveal in your Android client.

Handling multiple environments - Registering other client IDs for your project.

Note that it can be common for apps to have different package names as well as different certificates (and thus SHA-1 keys) for various types of environment (such for different developers or test and release environments). Google uses your package name together with SHA-1 signing-certificate fingerprint to uniquely identify your Android application. It’s important to register every package name + SHA1 fingerprint pair in Google Developers Console.

For example, to register the release version of this package, you can do so by selecting ‘New Credentials’ -> ‘OAuth client ID’, shown in Figure 5 below, and then following the steps to add the package name and production keystore SHA-1.

Now you are ready to handle the different environments where your app might be running and release to your users!

Hopefully, this has been helpful to you in understanding how to register for OAuth keys to keep your apps and servers secure. For more information, check out the Google Developers homepage for Identity.

Last summer we launched Android Experiments: a showcase of creative Android projects, and an open invitation for all developers to submit their own experiments to the gallery. So far we’ve seen some amazing work from the developer community - from live wallpaper, to watch faces, to interesting hacks of the IOIO board - and we want to see more.

Today we announce the Android Experiments I/O Challenge: a chance for your experiment (and you) to go to I/O 2016!

From now through April 13, you can enter by submitting your experiments to the gallery. The top three winners of the contest will receive a trip to this year’s Google I/O, and the five runner-ups will get the new Nexus 6P.

So what makes a good Android Experiment? It’s a project that utilizes the unique capabilities of the Android platform in an innovative way. Here are a few suggestions:

• Creative uses of Android’s new or distinctive features
• Projects that explore how we interact with our devices, in small and big ways
• Unique visual aesthetics
• Open source projects that inspire other developers
• Surprise us - we want to see the amazing things you’re cooking up

All projects on Android Experiments are open source. If you’re not sure where to start take a look on the site gallery, dig in and get inspired.

We can’t wait to see how you’re combining code and creativity! Enter on androidexperiments.com/challenge today.

Posted by Morgan Dollard, Product Manager of Google Play Games

With mobile gamers across 190 countries, Google Play Games is made up of a vibrant and diverse gaming community. And these players are more engaged than ever. Over the past year, the number of games reaching over 1 million installs grew by 50 percent.

Today, at our annual Developer Day at the Game Developers Conference, we announced new platform and ads tools for developers, of all sizes reach, to reach this global audience and accelerate the growth of their games business. Check out below the full range of features that will help game developers build their apps, grow their user base, and earn more revenue.

Making Google Play Games better for players

In February, we introduced Gamer IDs so that anyone could create a gaming persona. We also simplified the sign-in process for Google Play Games so players could pick up playing their game more quickly. We’re also working on product enhancements to make Play Games a little more social and fun, which will mean more engaged players who’re playing your game for longer. One example is the launch of Gamer friends (coming soon!), where your players can add and interact with their friends from within the Google Play Games app (without needing a Google+ account).

We’re also launching the Indie Corner, a new collection on Google Play, that will highlight amazing games built by indie developers. You can nominate your awesome indie game for inclusion at g.co/indiecornersubmission. We’ll pick the best games to showcase based on the quality of the experience and exemplary use of Google Play game services.

Grow your game with powerful new features from Google Play game services

In January, we added features to Player Analytics, the free reporting tool of Google Play game services, which helps you understand how players are progressing, spending and churning. Today, we previewed some upcoming new tools that would be available in the coming months, including:

• Game parameters management: With game parameters management, you will be able to update gameplay and game economy parameters without the need for APK changes or resubmitting your app. You’ll be able to optimize virtual goods and currencies from the Developer Console or the Google Play Developer API.

• Video Recording API: You will be able to easily add video recording to your app and let users share their videos with their friends and on YouTube in a few simple steps. We are also adding live streaming functionality to allow your fans to broadcast their gameplay experiences in real time on YouTube.

• Predictive Analytics: The Player Stats API now has Predictive Analytics to help you identify which groups of players are likely to spend or churn, and we are adding new predictions for how much a player is likely to spend within 30 days and the probability that a player is a high spender. This allows you to tailor experiences for these players to try to increase their spend or engagement. Learn more about the
  
  Player Stats API.

New ad formats and targeting to find, keep and monetize high-quality gamers

Promoting your game and growing your audience is important, but it’s just as important to reach the right audience for your game, the players who want to open the game again and again. That’s why today we’ve unveiled new features that make it simpler to reach the right audience at scale.

• Search Trial Run Ads: In the next few weeks, we’ll launch a new way for users to try your game out when they do a search for games on Google through a new ad format, Search Trial Run Ads. After tapping “Try now”, an individual can play your game for up to 10 minutes, and then download the game in full if they choose. These ads will appear to smartphone users on WiFi. Using this format, you can drive qualified users who are likely to stay engaged with your game after install.

• Portrait Video Ads: More than 80% of video ad views in mobile apps on the Google Display Network are from devices held vertically, but often these videos are created for landscape viewing. Over the next few weeks, we’re launching Portrait Video Ads for a full-screen, immersive portrait video experience. Developers have seen significant improvement in both click-through and conversion rates, resulting in lower cost per install and more installs.
• Active User Targeting for Games: In the coming weeks, we’re rolling out a new type of targeting for Android apps that allows you to show ads to users who have spent more than 30 minutes playing games, or who have played a Google Play Games integrated game, in the last 30 days.

Earn more revenue in your game with AdMob

AdMob helps game developers around the world maximize revenue through in-app advertising. At GDC, we also announced a new way to help you earn more through AdMob Mediation. Rewarded advertising is a popular form of game monetization -- users are given the choice to engage with ads in exchange for an in-app reward. AdMob Mediation will enable you to easily monetize your apps with rewarded video ads from a number of ad providers. Supported networks and platforms include AdColony, AppLovin, Chartboost, Fyber, Upsight and Vungle, with more being added all the time.

You can learn more about this, and all our ads announcements on the Inside AdWords blog.

This is just the start of what we’ve got planned for 2016. We hope you can make use of these tools to improve your game, engage your audience, and grow your business and revenue.

Posted by Morgan Dollard, Product Manager of Google Play Games

Next week, we’ll be in San Francisco to host our annual Developer Day at the Game Developers Conference (GDC). Join us to get a first look at our latest efforts to help developers of all sizes build successful mobile games businesses with powerful tools to develop high quality apps, grow a valuable user base, and earn more revenue.

Our Developer Day will take place in room 2020 of the West Hall of Moscone Center on Monday, March 14. Based on your feedback from last year, we're going to keep presentations short and informative with lightning talks around virtual reality, the cloud, ads, and so much more, while dedicating more time to interactive discussions with Google engineers and your peers in the industry.

Here’s a glimpse of the agenda on Monday, March 14:

Opening keynote || 10AM: Be the first to see what’s new and hear about the investments Google is making to help mobile developers grow their game business.

Best practices for success on Google Play || 10:30AM: In this talk, you’ll learn how successful mobile game developers acquire users and bring them back to keep them playing longer.

Lightning talks || 11:15AM: A series of 5-minute talks on innovative technologies to tantalize players, like Project Tango, software to speed and simplify game development, and new ways to predict and prevent user churn.

Interactive roundtables || 2:00PM: After lunch, we’ll break up into interactive roundtables to interact with Google experts and peers on how to build better and more successful games. Ask questions, tell Google product teams what you need, and learn from fellow game developers.

Visit the agenda page to get a full list of our talks and speaker details. Please note that these events are part of the official Game Developer's Conference, so you will need a pass to attend.

For everyone who can’t make it in person, we’ll be live streaming our event on YouTube. Tune in from 10am on Monday, March 18.

Posted by Dave Burke, VP of Engineering

Today we’re happy to announce a Developer Preview of the N release of Android! We’re doing something a little different this year by releasing the preview early… really early. By releasing a “work in progress” build earlier in development, we have more time to incorporate developer feedback. Also, the earlier preview allows us to hand off the final N release to device makers this summer, so they can get their hands on the latest version of Android earlier than ever. We’re looking forward to getting your feedback as you get your apps ready for N.

Here are a few APIs and features we want to highlight which are available as a part of the Android N Developer Preview today, with more to come as we continue developing the release:

Multi-window - A new manifest attribute called android:resizableActivity is available for apps targeting N and beyond. If this attribute is set to true, your activity can be launched in split-screen modes on phones and tablets. You can also specify your activity's minimum allowable dimensions, preventing users from making the activity window smaller than that size. Lifecycle changes for multi-window are similar to switching from landscape to portrait mode: your activity can handle the configuration change itself, or it can allow the system to stop the activity and recreate it with the new dimensions. In addition, activities can also go into picture-in-picture mode on devices like TVs, and is a great feature for apps that play video; be sure to set android:supportsPictureInPicture to true to take advantage of this.

Direct reply notifications: The RemoteInput notification API, which was originally added for Android Wear, now works in N for phones and tablets. Using the RemoteInput API enables users to reply to incoming message notifications quickly and conveniently, without leaving the notification shade. Learn more here.

Bundled notifications - With N, you can use the Notification.Builder.setGroup() method to group notifications from the same app together - for example individual messages from a messaging app. Grouped notifications can be expanded into individual notifications by using a two-finger gesture or tapping the new expansion button. Learn more here.

Efficiency - We launched Doze in Marshmallow to save battery when your device is stationary. In N, Doze additionally saves battery whenever the screen turns off. If you’ve already adapted your app for Doze, e.g. by using the GCM high priority message for urgent notifications, then you’re set; if not, here’s how to get started. Also, we’re continuing to invest in Project Svelte, an effort to reduce the memory needs of Android so that it can run on a much broader range of devices, in N by making background work more efficient. If you use JobScheduler for background work, you’re already on the right track. If not, N is a good time to make that switch. And to help you out, we’re making JobScheduler even more capable, so now you can use JobScheduler to react to things like changes to content providers.