Category Archives: Android Developers Blog

An Open Handset Alliance Project

Project Capillary: End-to-end encryption for push messaging, simplified

Posted by Giles Hogben, Privacy Engineer and Milinda Perera, Software Engineer

Developers already use HTTPS to communicate with Firebase Cloud Messaging (FCM). The channel between FCM server endpoint and the device is encrypted with SSL over TCP. However, messages are not encrypted end-to-end (E2E) between the developer server and the user device unless developers take special measures.

To this end, we advise developers to use keys generated on the user device to encrypt push messages end-to-end. But implementing such E2E encryption has historically required significant technical knowledge and effort. That is why we are excited to announce the Capillary open source library which greatly simplifies the implementation of E2E-encryption for push messages between developer servers and users' Android devices.

We also added functionality for sending messages that can only be decrypted on devices that are unlocked. This includes support for decrypting messages on devices using File-Based Encryption (FBE): encrypted messages are cached in Device Encrypted (DE) storage and message decryption keys are stored in Android Keystore, requiring user authentication. This allows developers to specify messages with sensitive content, that remain encrypted in cached form until the user has unlocked and decrypted their device.

The library handles:

  • Crypto functionality and key management across all versions of Android back to KitKat (API level 19).
  • Key generation and registration workflows.
  • Message encryption (on the server) and decryption (on the client).
  • Integrity protection to prevent message modification.
  • Caching of messages received in unauthenticated contexts to be decrypted and displayed upon device unlock.
  • Edge-cases, such as users adding/resetting device lock after installing the app, users resetting app storage, etc.

The library supports both RSA encryption with ECDSA authentication and Web Push encryption, allowing developers to re-use existing server-side code developed for sending E2E-encrypted Web Push messages to browser-based clients.

Along with the library, we are also publishing a demo app (at last, the Google privacy team has its own messaging app!) that uses the library to send E2E-encrypted FCM payloads from a gRPC-based server implementation.

What it's not

  • The open source library and demo app are not designed to support peer-to-peer messaging and key exchange. They are designed for developers to send E2E-encrypted push messages from a server to one or more devices. You can protect messages between the developer's server and the destination device, but not directly between devices.
  • It is not a comprehensive server-side solution. While core crypto functionality is provided, developers will need to adapt parts of the sample server-side code that are specific to their architecture (for example, message composition, database storage for public keys, etc.)

You can find more technical details describing how we've architected and implemented the library and demo here.

.app is open for general registration

Posted by Christina Chiou Yeh, Google Registry

On May 1 we announced .app, the newest top-level domain (TLD) from Google Registry. It's now open for general registration so you can register your desired .app name right now. Check out what some of our early adopters are already doing on .app around the globe.

We begin our journey with sitata.app, which provides real-time travel information about events like protests or transit strikes. Looks all clear, so our first stop is the Caribbean, where we use thelocal.app and start exploring. After getting some sun, we fly to the Netherlands, where we're feeling hungry. Luckily, picnic.app delivers groceries, right to our hotel. With our bellies full, it's time to head to India, where we use myra.app to order the medicine, hygiene, and baby products that we forgot to pack. Did we mention this was a business trip? Good thing lola.app helped make such a complex trip stress free.

We hope these apps inspire you to also find your home on .app! Visit get.app to choose a registrar partner to register your domain.

Insider Attack Resistance

Posted by Shawn Willden, Staff Software Engineer

Our smart devices, such as mobile phones and tablets, contain a wealth of personal information that needs to be kept safe. Google is constantly trying to find new and better ways to protect that valuable information on Android devices. From partnering with external researchers to find and fix vulnerabilities, to adding new features to the Android platform, we work to make each release and new device safer than the last. This post talks about Google's strategy for making the encryption on Google Pixel 2 devices resistant to various levels of attack—from platform, to hardware, all the way to the people who create the signing keys for Pixel devices.

We encrypt all user data on Google Pixel devices and protect the encryption keys in secure hardware. The secure hardware runs highly secure firmware that is responsible for checking the user's password. If the password is entered incorrectly, the firmware refuses to decrypt the device. This firmware also limits the rate at which passwords can be checked, making it harder for attackers to use a brute force attack.

To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.

In the past, device makers have focused on safeguarding these keys by storing the keys in secure locations and severely restricting the number of people who have access to them. That's good, but it leaves those people open to attack by coercion or social engineering. That's risky for the employees personally, and we believe it creates too much risk for user data.

To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user's cooperation. Specifically, it is not possible to upgrade the firmware that checks the user's password unless you present the correct user password. There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it.

The Android security team believes that insider attack resistance is an important element of a complete strategy for protecting user data. The Google Pixel 2 demonstrated that it's possible to protect users even against the most highly-privileged insiders. We recommend that all mobile device makers do the same. For help, device makers working to implement insider attack resistance can reach out to the Android security team through their Google contact.

Acknowledgements: This post was developed in joint collaboration with Paul Crowley, Senior Software Engineer

Insider Attack Resistance

Posted by Shawn Willden, Staff Software Engineer

Our smart devices, such as mobile phones and tablets, contain a wealth of personal information that needs to be kept safe. Google is constantly trying to find new and better ways to protect that valuable information on Android devices. From partnering with external researchers to find and fix vulnerabilities, to adding new features to the Android platform, we work to make each release and new device safer than the last. This post talks about Google's strategy for making the encryption on Google Pixel 2 devices resistant to various levels of attack—from platform, to hardware, all the way to the people who create the signing keys for Pixel devices.

We encrypt all user data on Google Pixel devices and protect the encryption keys in secure hardware. The secure hardware runs highly secure firmware that is responsible for checking the user's password. If the password is entered incorrectly, the firmware refuses to decrypt the device. This firmware also limits the rate at which passwords can be checked, making it harder for attackers to use a brute force attack.

To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.

In the past, device makers have focused on safeguarding these keys by storing the keys in secure locations and severely restricting the number of people who have access to them. That's good, but it leaves those people open to attack by coercion or social engineering. That's risky for the employees personally, and we believe it creates too much risk for user data.

To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user's cooperation. Specifically, it is not possible to upgrade the firmware that checks the user's password unless you present the correct user password. There is a way to "force" an upgrade, for example when a returned device is refurbished for resale, but forcing it wipes the secrets used to decrypt the user's data, effectively destroying it.

The Android security team believes that insider attack resistance is an important element of a complete strategy for protecting user data. The Google Pixel 2 demonstrated that it's possible to protect users even against the most highly-privileged insiders. We recommend that all mobile device makers do the same. For help, device makers working to implement insider attack resistance can reach out to the Android security team through their Google contact.

Acknowledgements: This post was developed in joint collaboration with Paul Crowley, Senior Software Engineer

All the (Android) Things at Google I/O

Melissa Daniels, Program Manager for Android Things

Android Things enables you to build and maintain IoT devices at scale. We recently released Android Things 1.0 with long-term support for production devices, so you can easily take an IoT device from prototype to commercial product.

We packed Google I/O this year with Android Things content to inspire and empower the developer community, from talks and codelabs to interactive demos and a scavenger hunt. Here's a closer look at the fun stuff we had on display that you won't see on the shelves of retail stores.

Demos

We introduced a handful of new interactive Android Things demos across I/O, showcasing the AI and ML capabilities of the platform, so if you didn't get an opportunity to attend this year, here's a few of our favorites-- perfect for exploring from wherever you are in the world!

Smart Flowers: Flos Mobilis

What do you get when you combine machine learning, Android Things and robotics? Flos Mobilis, a continuum robot where each flower is backed by an i.MX7D development board and a camera to run an embedded neural net model that controls the motion of the flower. This is all done offline with no data stored or transmitted.

Smart Flowers: Flos Affectus

What if a robot could respond to the way you feel? Flos Affectus is a cluster of robotic flowers that "bloom" and "un-bloom" depending on the expression detected on the user's face. The 4 broad expressions Flos Affectus is trained to detect are: happy, sad, angry, surprised. Using a camera embedded in the head of the alpha flower, the flower cluster is able to detect the user's face and infer the facial emotion. The flower cluster runs offline with no data stored or transmitted and demonstrates movement capabilities and on-device machine learning models.

Rosie the Android

Initially designed by a team of Google engineers for the annual Grace Hopper conference, Rosie the Android is a 5 foot selfie-taking Android, complete with machine-learning capabilities. Inspired by Rosie the Riveter, she's a fully controllable robot that can take photos, respond to commands, wheel around and interact with those around her.

Did you take a selfie with Rosie at I/O? Redeem your unique access code at g.co/rosie

Smart Projector

Smart Projector is built on Lantern, an Android Things project exploring the relationship between surfaces and content — augmenting real-world objects and environments with glanceable, meaningful data. It leverages the Google Experiments project known as Quick Draw, using the world's largest doodling data set that has been shared publicly to help with machine learning research.

To learn more about Lantern or to start building your own, start here.

3D Printer

This modified Printrbot Smalls 3D Printer uses a real-time subsystem that showcases the flexibility of Android Things-- a microcontroller does the low-latency motor control, while Android Things handles OpenGL rendering. By keeping most of the logic on a high-level platform like Android you make development and debugging much easier, thanks to Android's great tooling.

The future of 3D printing? Making real-time control as easy and portable as the rest of Android Things.

Codelabs

Phew! That was just the tip of the demo iceberg. With so many demos and so many ways to use Android Things, it's easy to start imagining all the things you can build! At I/O, we helped a lot of developers get started building their first Android Things device using the Android Things Starter Kit. We're making these codelabs available, so you can get to them whenever you need, or build your own.

Videos

Missed the I/O talks? Catch the recordings of each Android Things talk, so you can start, pause, and rewind at your own leisure. Or, just lean back and watch them all.

What's new in Android Things

Build effective OEM-level apps on Android Things

Build real consumer devices with Android Things

Electronic design for Android Things System on Modules

Women Techmakers panel: experiences developing on Android Things

Product design: how to build better products with Android Things

Device provisioning and authentication with Android Things

Update production devices in the field with the Android Things Console

Start building!

On top of all the resources we just mentioned, we have a corpus of information on our developer documentation, and our new community website where you can see more inspiring projects and even submit your own. So, what are you waiting for? Pick up an Android Things Starter Kit and start building something today!

Keeping 2 billion Android devices safe with machine learning

Posted by Sai Deep Tetali, Software Engineer, Google Play Protect

At Google I/O 2017, we introduced Google Play Protect, our comprehensive set of security services for Android. While the name is new, the smarts powering Play Protect have protected Android users for years.

Google Play Protect's suite of mobile threat protections are built into more than 2 billion Android devices, automatically taking action in the background. We're constantly updating these protections so you don't have to think about security: it just happens. Our protections have been made even smarter by adding machine learning elements to Google Play Protect.

Security at scale

Google Play Protect provides in-the-moment protection from potentially harmful apps (PHAs), but Google's protections start earlier.

Before they're published in Google Play, all apps are rigorously analyzed by our security systems and Android security experts. Thanks to this process, Android devices that only download apps from Google Play are 9 times less likely to get a PHA than devices that download apps from other sources.

After you install an app, Google Play Protect continues its quest to keep your device safe by regularly scanning your device to make sure all apps are behaving properly. If it finds an app that is misbehaving, Google Play Protect either notifies you, or simply removes the harmful app to keep your device safe.

Our systems scan over 50 billion apps every day. To keep on the cutting edge of security, we look for new risks in a variety of ways, such as identifying specific code paths that signify bad behavior, investigating behavior patterns to correlate bad apps, and reviewing possible PHAs with our security experts.

In 2016, we added machine learning as a new detection mechanism and it soon became a critical part of our systems and tools.

Training our machines

In the most basic terms, machine learning means training a computer algorithm to recognize a behavior. To train the algorithm, we give it hundreds of thousands of examples of that behavior.

In the case of Google Play Protect, we are developing algorithms that learn which apps are "potentially harmful" and which are "safe." To learn about PHAs, the machine learning algorithms analyze our entire catalog of applications. Then our algorithms look at hundreds of signals combined with anonymized data to compare app behavior across the Android ecosystem to find PHAs. They look for behavior common to PHAs, such as apps that attempt to interact with other apps on the device, access or share your personal data, download something without your knowledge, connect to phishing websites, or bypass built-in security features.

When we find apps exhibit similar malicious behavior, we group them into families. Visualizing these PHA families helps us uncover apps that share similarities to known bad apps, but have yet remained under our radar.

After we identify a new PHA, we confirm our findings with expert security reviews. If the app in question is a PHA, Google Play Protect takes action on the app and then we feed information about that PHA back into our algorithms to help find more PHAs.

Doubling down on security

So far, our machine learning systems have successfully detected 60.3% of the malware identified by Google Play Protect in 2017.

In 2018, we're devoting a massive amount of computing power and talent to create, maintain and improve these machine learning algorithms. We're constantly leveraging artificial intelligence and our highly skilled researchers and engineers from all across Google to find new ways to keep Android devices safe and secure. In addition to our talented team, we work with the foremost security experts and researchers from around the world. These researchers contribute even more data and insights to keep Google Play Protect on the cutting edge of mobile security.

To check out Google Play Protect, open the Google Play app and tap Play Protect in the left panel.

Acknowledgements: This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Damien Octeau, Sebastian Porst, Chuangang Ren, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, Zhikun Wang, and Mo Yu.

Learn Kotlin Fast with new Kotlin Bootcamp course

Posted by Aleks Haecky, Training Developer & Word Artist, Google+, LinkedIn, Medium

The Kotlin Bootcamp Udacity course is a free, self-paced online course that teaches you the basics of the Kotlin programming language. This introduction to Kotlin was created by Google experts in collaboration with Udacity and is for people who already know how to program.

The Kotlin language lets you create apps in less time, writing less code, and with fewer errors.

This modern object-oriented language offers a strong type system, type inference, null safety, properties, lambdas, extensions, coroutines, higher-order functions, and many other features. Kotlin is so concise that you can create complete data classes with a single line of code.

Kotlin is officially supported for building Android apps, fully interoperates with the Java programming language and libraries, and is included with IntelliJ and Android Studio.

In this course you will learn everything you need to program in Kotlin, including:

  1. Basics: Write Kotlin statements and expressions in the IntelliJ REPL Kotlin interpreter using nullable and non-nullable variables, data types, operators, and control structures.
  2. Functions: Create a main() function, create and call functions with default and variable arguments, pass functions as arguments to filters, program simple lambdas, function types, and compact single-expression functions.
  3. Classes: Create a class with methods and properties. Implement constructors and init(). Learn about inheritance, interfaces, and abstract classes. Use the special purpose classes data, object, enum, and sealed.
  4. Beyond the Basics: Dive deeper into Pairs, collections, and constants. Learn how to write extensions, implement generics, apply annotations, and use labeled breaks.
  5. Functional Manipulation: Explore more about lambdas, higher-order functions, and inline.

You'll learn how to use extension functions to add helpful functionality to existing classes.

Extend built-in types: 

fun Int.print() = println(this)
5.print() // prints 5

Extend Android classes: 

fun Context.toast(text: CharSequence, duration: Int = Toast.LENGTH_SHORT): Toast {
   return Toast.makeText(this, text, duration).apply { show() }
}
toast("Hello Toast")

Extend your own classes: 

class AquariumPlant(
       val color: String)

fun AquariumPlant.print() =
       println("Pretty Aquarium Plant")

val plant = AquariumPlant("green")
plant.print()
// prints -> Pretty Aquarium Plant

When you've completed the course, you will be able to create programs in Kotlin, taking advantage of the features and capabilities that make Kotlin unique.

The course is available free, online at Udacity; take it in your own time at your own pace.

Go learn how to build apps with less code at https://www.udacity.com/course/ud9011.

Building with Google Pay

Posted by Gerardo Capiel and Varouj Chitilian, Google Pay

Today's customers want to get things done faster than ever, whether they're ordering groceries or shopping for a new pair of shoes. With Google Pay, we want to ensure checkout doesn't slow them (or your conversions) down, while enhancing the customer experience at every step of the way.

Last week at Google I/O, we announced some exciting new features that do just that. We also shared the latest ways developers can use Google Pay to offer the best experiences at checkout and beyond—all available for free with our APIs. Here are some of the highlights and how you can make the most of them.

More places for customers to check out online

We've started rolling out support for checking out with Google Pay regardless of your browser or device. This means customers can pay with Google Pay on most major browsers from any device.

Enabling this functionality within your apps and sites is simple. Watch Google Pay software engineer Tony Chen do a website integration live on stage, then try it yourself using our developer docs.

But making checkout easier for your customers doesn't just apply to how they pay. Chrome Autofill helps customers fill in forms automatically, so they can speed through the entire checkout process without getting bogged down by typing. To ensure your shoppers are getting the fastest checkout experience with Chrome Autofill, we recommend you check out our new best practices guide.

We'll also be making it easier for customers to manage their payment methods in Google Pay by adding this functionality to our iOS and desktop experiences as well. The new functionality will allow people to add cards and see transactions whenever and wherever it's most convenient for them, giving you access to a new group of customers who will be able to use Google Pay within your apps and sites. It also means that customers who add cards from a laptop can use those cards with Google Pay on an iOS device. (Try it for yourself at g.co/pay/demo.)

This new functionality will be launching soon, and you can learn more about it in our Build with Google Pay session.

Mobile tickets and passes with the Google Pay API for Passes

Building off our newly-launched support for prepaid transit passes, we're now also supporting a new way for you to save and manage passes through our Google Pay API for Passes. This lets you create mobile event tickets and boarding passes that your customers can save to the Google Pay Android app. We've piloted this feature with Southwest, Fortress GB, and Ticketmaster, with more partners coming soon. Want to get on board? Sign up for more information.

Transactions come to Actions on Google

Actions on Google lets developers engage billions of users across the Google Assistant and soon Google Search, Android, and other surfaces by developing Actions and linking them with our ever-growing intents catalog. One of our sessions shows you how you can enable Google Pay in your Actions so your customers can make purchases with their Assistant across multiple surfaces, including mobile devices, Google Home, and soon, Smart Displays. Transactions are now available in Australia, Canada, Japan, France, Germany, the United States, and the United Kingdom. (We'll be bringing them to Brazil, India, Italy, and Spain soon.)

Plus, we're starting a developer preview where you can now enable transactions to sell digital content on the Google Assistant. That includes in-app purchases, subscriptions, games, experiences, and premium content.

We can't wait to see all of the creative ways you use Google Pay to amplify your business and build better checkout experiences for your customers. Be sure to check out all of our I/O sessions for more ideas, tools, and tips. In the meantime, we'll be hard at work on new features to keep making Google Pay the best experience possible—for you and your customers.

Faster Adoption with Project Treble

Posted by Iliyan Malchev, Project Treble Architect

Android P Beta available at android.com/beta

As Android continues to evolve, each new release of the OS brings new features, new user experiences, and better security. It is important that these new releases find their way to mobile devices as fast as possible.

Yesterday, we announced that the following devices, in addition to Pixel and Pixel 2, now support Android P Beta: Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21, OnePlus 6 and Essential PH‑1. Android P Beta provides an opportunity for developers and early adopters around the world to try the latest Android release, test their apps, and provide feedback.

In this post, we provide an update to Project Treble and the technology that allowed us to bring Android Beta to more phones this year.

Building the Foundation

Bringing the new Android release quickly to the hands of users takes a combined effort between Google, silicon manufacturers (SM), device manufacturers (OEMs), and carriers. This process is technically challenging and requires aligning the schedules between our industry partners.

To reduce the technical difficulties, we launched Project Treble as part of Android Oreo.

The Silicon Manufacturers

Next, to capitalize on the foundation we built, we collaborated closely with the silicon manufacturers, where the journey of making an Android device always begins.

Any device with the latest version of Android must be based on an SoC with the proper software support for it. This software, commonly referred to as the Board Support Package (BSP), contains not only the chip-specific vendor implementation, but also all of the Android Open Source Project (AOSP) and pieces of the framework that are missing from AOSP itself (e.g., carrier-specific telephony functionality).

These BSPs are the starting point for all device launches. OEMs adapt the vendor implementation to their hardware and add their own custom framework components.

While silicon manufacturers always want the latest version of Android in their BSPs, the costs have been prohibitive. By making it possible for newer AOSP frameworks to run on older, already-released vendor implementations, Project Treble dramatically reduces the need for continuous investment in older silicon to support each Android release. Silicon manufacturers have to do all this work just once, rather than every time there is a new release of Android.

Solving the Timing Problem

However, that first time still has to happen. Below is a chart, which illustrates the effort the various actors expend over time as they go through each release. You can think of it as code churn or bug count over time.

The chart shows how there is very little time in the year for Google, silicon manufacturers, and the OEMs to all this work. Any overlap between phases causes code churn and introduces significant schedule risk. For OEMs who target the holiday season, it is often safer to launch on an older BSP with a year-old or even older Android version. This dynamic has been at the heart of the slow uptake of the latest Android release, even on flagship devices.

To solve this, we've worked closely with Qualcomm, MediaTek and Samsung SLSI to co-develop their BSPs, starting with Android P. Their BSPs are now ready for Android P on a much-accelerated schedule, reducing the overall effort significantly. These silicon manufacturers are now able to provide a stable and high-quality release much earlier than before, allowing OEMs to bring the latest innovations of Android to their customers across the globe.

This is an important step in accelerating the adoption of Android releases that bring numerous benefits to our partners, users, and Android developers. We look forward to seeing many more partners launch or upgrade devices to Android P.

Wear OS by Google: AoG support and new enhanced battery saver mode

Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google

At Google I/O, we launched the Wear OS by Google developer preview 2. This update added support for Actions on Google (AoG) and more power-related enhancements including a new battery saver mode.

This developer preview includes updated Android Emulator images and a downloadable system image for the Huawei Watch 2 Bluetooth or Huawei Watch 2 Classic Bluetooth. This preview release is intended for developers only and not for daily or consumer use. Therefore, the preview release is only available via manual download and flash. Please refer to the release notes for known issues before downloading and flashing your device.

Support for Actions on Google

We have revamped the Google Assistant on Wear OS to support features such as visual cards, follow-on suggestion chips, and text-to-speech. For developers, we added support for Actions on Google to Wear OS and existing Actions will work on Wear OS out of the box. Be sure to observe best practices for Actions on Google to get the best results such as short concise dialog and adopting to both visual and vocal feedback. This feature does not depend on Android P and is being rolled out to all Wear 2.0 users.

Enhanced battery saver mode

In this Android P developer preview, we are launching an enhanced battery saver mode. While the watch is in this mode, the watch shows a power-efficient watch face and turns off a set of services including radios, the touch screen, and tilt to wake. Users can get the time by pressing the side button. A long press allows the user to switch back to a fully-operational mode and perform tasks such as paying with NFC or replying to a message. Developers should assume that their apps, watch faces, and complication data providers are not available in enhanced battery saver mode.

Update on power saving features

We received much feedback on the power saving features in the last developer preview. As a result, we have updates on two features:

  • Roll back of Wi-Fi off when BT is disconnected: To improve power consumption, the last developer preview would not connect to Wi-Fi when disconnected from Bluetooth. After listening carefully to user and developer feedback, we decided to roll back this change.
  • Limited background activity and foreground service: A number of health and fitness developers have said their apps require background monitoring of the user's motion and other vitals throughout the day. The developers said their apps cannot perform background monitoring if background services are unable to set alarms and jobs. For these types of exceptional use cases, we recommend that the apps use foreground services to anchor alarms and jobs. For other use-cases, developer should look at both foreground service as well as limiting jobs and alarms to while the watch is on charger. We are still fine tuning this feature, your feedback and use-cases will be most helpful in helping us get this right.

Smart Reply for bridged notifications

Smart Reply has been enabled for bridged notifications from the user's smartphone for some time. With the latest developer preview, we are introducing simplified Chinese support for our users in China. This feature is powered by an on-device model using TensorFlow Lite and the model is optimized for low-memory, low-power devices.

To use this feature, developers should set setAllowGeneratedReplies of the reply action to true. Here's a sample code snippet with the important part highlighted in bold: 

NotificationCompat.Action action =
    new NotificationCompat.Action.Builder(R.drawable.ic_reply_white_24dp,
        replyLabel, replyPendingIntent)
        .addRemoteInput(remoteInput)
        .setAllowGeneratedReplies(true) // <--- true to enable smart replies
        // Wear OS requires a hint to display the reply action inline.
        .extend(new NotificationCompat.Action.WearableExtender()
            .setHintDisplayActionInline(true))
        .build();

In addition, for messaging apps, we recommend that developers use MessagingStyle notifications. This can give the algorithm a more structured data set on which to base its recommendations.

Please give us your feedback

We expect to provide more updates to this preview before the final production release. Please submit any bugs you find via the Wear OS by Google issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.