Jun 12

Wear OS developer preview reenabling alarms and jobs for background apps


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

From the outset of the Wear OS by Google developer preview, battery life has been a major focus area. When we talked to the developer community, the update that attracted the most feedback was the disabling of alarms and jobs for background apps. After listening to developer feedback and reviewing the battery statistics, we are reversing this change. This should be reflected in all connected Wear OS preview devices, so there is no need to reflash your device.

App Standby Buckets

The decision came as we reviewed the feedback and saw that a strict on/off setting prevents reasonable usage and promotes anti-patterns. Going forward, we plan to leverage the App Standby Buckets feature in Android P to fine-tune a suitable setting for Wear OS devices. The exact setting for alarms and jobs for background apps is still being iterated on. Developers are advised to follow the best practices to make sure their apps behave well, whichever bucket the apps are in.

Input and data privacy in background apps

Another area that developers should pay attention to is the strengthening of input and data privacy for background apps in Android P. Depending on an app’s requirements, developers may need to use a foreground service to enable access to the device sensor throughout the day.

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.


Android Developers Blog

Jun 09

Porting Your Android Wear Developer Preview Code to the Latest Support Library

Today’s post on #AndroidWear is from +Wayne Piekarski.

Now that the full Android Wear SDK is available, it’s time to port your existing wearable-enabled notification code from the Developer Preview. In the process, you’ll switch to using the latest Android support library, and there are some small API changes that will require you to update your code. This article will show you how to update my previous code samples that were released earlier for stacks and pages, which you can use to guide the conversion of your own code as well.

To get started with an existing project in Android Studio, you should update to the 0.8 or later release. You also need to make sure you’ve downloaded the Google Support Library version 20 or later from the SDK Manager. Since this is only a notification-based example, there’s no need to download the full Android Wear SDK, which is only needed if you want to create an APK to run on the wearable device.

Unix diff output is used to show the necessary changes in an easy to understand way. Do not copy the + or – symbols at the start of each line, and ignore the lines starting with @@ which are used to indicate the line number that changed. For the curious, I used the following command to generate the diff output from the last commit in my GIT repository (the -U1 shows one line of context to keep the output simple):

git show HEAD -U1

Gradle changes

To add the new support-v4 library, you need to edit your build.gradle file like so:

@@ -24,2 +24,3 @@ dependencies {
     compile 'com.android.support:appcompat-v7:19.+'
+    compile 'com.android.support:support-v4:20.0+'
 }

Make sure you remove the wearable-preview-support.jar that was provided with the Developer Preview from your libs directory and build.gradle file, since these features are now in the standard support library.

Package imports

Since the APIs and package names have changed, the import statements at the top of MainActivity.java need to be adjusted like this:

@@ -7,3 +7,2 @@ import android.view.MenuItem;
-import android.support.v4.app.NotificationCompat;
 import android.app.Notification;
@@ -13,4 +12,9 @@ import android.graphics.Bitmap;
 import android.graphics.BitmapFactory;
-import android.preview.support.v4.app.NotificationManagerCompat;
-import android.preview.support.wearable.notifications.WearableNotifications;
+import android.support.v4.app.NotificationCompat;
+import android.support.v4.app.NotificationManagerCompat;
+
+// Extra dependencies needed for the pages example
+import java.util.ArrayList;
+import java.util.List;
+import android.support.v4.app.NotificationCompat.BigTextStyle;

Stacking notifications

Since the preview SDK, we have simplified how notifications are implemented. The existing NotificationCompat.Builder() was extended to support groups directly, instead of a separate WearableNotifications class. The steps are a lot simpler, as can be seen with the following changes to showStackNotifications():

@@ -63,3 +67,3 @@ public class MainActivity extends ActionBarActivity {
         // Group notification that will be visible on the phone
-    NotificationCompat.Builder builderG = new NotificationCompat.Builder(this)
+    Notification summaryNotification = new NotificationCompat.Builder(this)
             .setContentTitle("2 Pet Notifications")
@@ -67,5 +71,5 @@ public class MainActivity extends ActionBarActivity {
             .setSmallIcon(R.drawable.ic_launcher)
-                .setLargeIcon(bitmapMila);
-    Notification summaryNotification = new WearableNotifications.Builder(builderG)
-            .setGroup(GROUP_KEY_MESSAGES, WearableNotifications.GROUP_ORDER_SUMMARY)
+                .setLargeIcon(bitmapMila)
+            .setGroup(GROUP_KEY_MESSAGES)
+            .setGroupSummary(true)
             .build();
@@ -76,3 +80,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Treat Fed", viewPendingIntent1)
@@ -81,4 +85,3 @@ public class MainActivity extends ActionBarActivity {
                     + "Can we have steak?")
-                .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)
@@ -89,3 +92,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+2, viewIntent2, 0);
-    NotificationCompat.Builder builder2 = new NotificationCompat.Builder(this)
+    Notification notification2 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Water Filled", viewPendingIntent2)
@@ -93,4 +96,3 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("Can you refill our water bowl?")
-            .setSmallIcon(R.drawable.ic_launcher);
-        Notification notification2 = new WearableNotifications.Builder(builder2)
+            .setSmallIcon(R.drawable.ic_launcher)
             .setGroup(GROUP_KEY_MESSAGES)

Page notifications

Page notifications have also changed to use a WearableExtender() class instead of the WearableNotifications class, as can be seen here in showPageNotifications():

@@ -151,3 +153,3 @@ public class MainActivity extends ActionBarActivity {
             PendingIntent.getActivity(this, notificationId+1, viewIntent1, 0);
-    NotificationCompat.Builder builder1 = new NotificationCompat.Builder(this)
+    Notification notification1 = new NotificationCompat.Builder(this)
             .addAction(R.drawable.ic_action_done, "Returned", viewPendingIntent1)
@@ -155,5 +157,4 @@ public class MainActivity extends ActionBarActivity {
             .setContentText("You have " + numOverdue + " books due at the library")
-            .setSmallIcon(R.drawable.ic_launcher);
-    Notification notification1 = new WearableNotifications.Builder(builder1)
-            .addPages(extras)
+                .setSmallIcon(R.drawable.ic_launcher)
+            .extend(new NotificationCompat.WearableExtender().addPages(extras))
             .build();

Conclusion

If you want to download the final source code of showStackNotifications() and showPageNotifications(), you can download the MainActivity.java file. You can build this file easily by creating a new project in Android Studio, adding the support library, and then copying in this MainActivity.java.

As you can see, porting this previous code over to the latest Android Wear SDK is really easy! It should take you hardly any time at all to get your experimental applications ported over and ready for publishing on the Google Play!

Join the discussion on
+Android Developers


Android Developers Blog

May 16

Android Wear 2.0 Developer Preview 3: Play Store and More

Posted by Hoi Lam, Developer
Advocate

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

Play Store features

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

Why an on-watch store?

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

Publish your apps

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

Download the New Android Wear companion app

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

Other additions in Developer Preview 3

Developer Preview 3 also includes:

  • Complications improvements: Starting with Developer Preview
    3, watch face developers will need to request
    RECEIVE_COMPLICATION_DATA permission before the watch face can receive
    complication data. We have added ComplicationHelperActivity to make
    this easier. In addition, watch face developers can now set
    default complications, including a selection of system data complications
    which do not require special permission (e.g. battery level and step count), as
    well as data providers that have whitelisted the watch face. Lastly, there are
    behavior changes related to ComplicationData to 1) help better
    differentiate various
    scenarios leading to “empty data” and 2) ease development by returning a default
    value for fields not supported by a complication type instead of throwing a
    runtime exception.

  • New WearableRecyclerView:
    This new UI component helps developers display and manipulate vertical lists of
    items while optimizing for round displays.

  • Inline
    Action for Notifications:
    A new API makes it easy to take action on
    a notification right from the stream. Developers can specify which action is
    displayed inline at the bottom of the notification by calling setHintDisplayActionInline:

    NotificationCompat.Action replyAction =
        new NotificationCompat.Action.Builder(R.drawable.ic_message_white_24dp,
                "Reply", replyPendingIntent)
                .addRemoteInput(remoteInput)
                .extend(new NotificationCompat.Action.WearableExtender()
                        .setHintDisplayActionInline(true))
                .build(); 
  • Smart
    Reply:
    Android Wear now generates Smart Reply responses for
    MessagingStyle
    notifications. Smart Reply responses are generated by an entirely on-watch
    machine learning model using the context provided by the
    MessagingStyle notification, and no data is uploaded to the cloud
    to generate the responses.

  • And much more: Read about the complete list of changes in
    the Android Wear developer preview release
    notes.

    Timeline

    We’ve gotten tons of great feedback from the developer community about Android
    Wear 2.0––thank you! We’ve decided to continue the preview program into early
    2017, at which point the first watches will receive Android Wear 2.0. Please
    keep the feedback coming by filing bugs
    or posting in our Android Wear
    Developers community, and stay tuned for Android Wear Developer Preview 4.


    Android Developers Blog

May 10

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.


Android Developers Blog

May 09

Update on Android Wear Paid Apps

We have a workaround to enable paid apps (and other apps that use Google Play’s forward-lock mechanism) on Android Wear. The assets/ directory of those apps, which contains the wearable APK, cannot be extracted or read by the wearable installer. The workaround is to place the wearable APK in the res/raw directory instead.

As per the documentation, there are two ways to package your wearable app: use the “wearApp” Gradle rule to package your wearable app or manually package the wearable app. For paid apps, the workaround is to manually package your apps with the following two changes, and you cannot use the “wearApp” Gradle rule. To manually package the wearable APK into res/raw, do the following:

  1. Copy the signed wearable app into your handheld project’s res/raw directory and rename it to wearable_app.apk, it will be referred to as wearable_app.
  2. Create a res/xml/wearable_app_desc.xml file that contains the version and path information of the wearable app:
    <wearableApp package="com.google.android.wearable.myapp">
        <versionCode>1</versionCode">
        <versionName>1.0</versionName">
        <rawPathResId>wearable_app</rawPathResId">
    </wearableApp>

    The package, versionCode, and versionName are the same as values specified in the wearable app’s AndroidManifest.xml file. The rawPathResId is the static variable name of the resource. If the filename of your resource is wearable_app.apk, the static variable name would be wearable_app.

  3. Add a <meta-data> tag to your handheld app’s <application> tag to reference the wearable_app_desc.xml file.
    <meta-data android:name="com.google.android.wearable.myapp"
               android:resource="@xml/wearable_app_desc"/>
  4. Build and sign the handheld app.

We will be updating the “wearApp” Gradle rule in a future update to the Android SDK build tools to support APK embedding into res/raw. In the meantime, for paid apps you will need to follow the manual steps outlined above. We will be also be updating the documentation to reflect the above workaround. We’re working to make this easier for you in the future, and we apologize for the inconvenience.


Android Developers Blog

Apr 06

Fitness Apps on Android Wear

Posted by Joshua Gordon, Developer Advocate

Go for a run, improve your game, and explore the great outdoors with Android Wear! Developers are creating a diverse array of fitness apps that provide everything from pace and heart rate while running, to golf tips on your favorite course, to trail maps for hiking. Let’s take a look features of the open and flexible Wear platform they use to create great user experiences.

Always-on stats

If your app supports always-on, you’ll never have to touch or twist your watch to activate the display. Running and want to see your pace? Glance at your wrist and it’s there! Runtastic, Endomondo, and MapMyRun use always-on to keep your stats visible, even in ambient mode. When it’s time for golf, I use Golfshot. Likewise, Golfshot uses always-on to continuously show yardage to the hole, so I never have to drop my club. Check out the doc, DevByte, and code sample to learn more.

Runtastic automatically transitions to ambient mode to conserve battery. There, it reduces the frequency at which stats are updated to about once per 10 seconds.



Maps, routes, and markers

It’s encouraging to see how much ground I’ve covered when I go for a run or ride! Using the Maps API, you can show users their route, position, and place markers on the map they can tap to see more info you provide. All of this functionality is available to you using the same Maps API you’ve already worked with on Android. Check out the doc, DevByte, code sample, and blog post to learn more.

Endomondo tracks your route while your run. You can pan and zoom the map.


Google Fit

Google Fit is an open platform designed to make it easier to write fitness apps. It provides APIs to help with many common tasks. For example, you can use the Recording API to estimate how many steps the user has taken and how many calories they’ve burned. You can make that data to your app via the History API, and even access it over the web via REST, without having to write your own backend. Now, Google Fit can store data from a wide variety of exercises, from running to weightlifting. Check out the DevByte and code samples to learn more.

Bluetooth Low Energy: pair with your watch

With the latest release of Android Wear, developers can now pair BLE devices directly with the Wearable. This is a great opportunity for all fitness apps — and especially for running — where carrying both a phone and the Wearable can be problematic. Imagine if your users could pair their heart rate straps or bicycle cadence sensors directly to their Wear device, and leave their phones at home. BLE is now supported by all Wear devices, and is supported by Google Fit. To learn more about it, check out this guide and DevByte.

Pack light with onboard GPS

When I’m running, carrying both a phone and a wearable can be a bit much. If you’re using an Android Wear device that supports onboard GPS, you can leave your phone at home! Since not all Wear devices have an onboard GPS sensor, you can use the FusedLocationProviderApi to seamlessly retrieve GPS coordinates from the phone if not available on the wearable. Check out this handy guide for more about detecting location on Wear.

RunKeeper supports onboard GPS if it’s available on your Wearable.



Sync data transparently

When I’m back home and ready for more details on my activity, I can see them by opening the app on my phone. My favorite fitness apps transparently sync data between my Wearable and phone. To learn more about syncing data between devices, watch this DevByte on the DataLayer API.

Next Steps

Android Wear gives you the tools and training you need to create exceptional fitness apps. To get started on yours, visit developer.android.com/wear and join the discussion at g.co/androidweardev.

Join the discussion on

+Android Developers


Android Developers Blog

Mar 29

Wear OS by Google developer preview

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

Today we launched the Wear OS by Google developer preview and brought Android P platform features to wearables. The developer preview includes updated system images on the official Android Emulator and a downloadable system image for the Huawei Watch 2 Bluetooth or Huawei Watch 2 Classic Bluetooth. This initial release is intended for developers only and is not for daily or consumer use. Therefore, it is only available via manual download and flash. Please refer to the release notes for known issues before downloading and flashing your device.

In this release, we would like to highlight the following features that developers should pay attention to:

  • Restriction related to non-SDK methods and fields: To improve app compatibility, Android P has started the process of restricting access to non-SDK methods and fields. Developers should make plans to migrate away from these. If there is no public equivalent for your use case, please let us know.
  • Dark UI system theme: To enhance glanceability, Wear OS has switched to a UI theme with a darker / black background for the notifications stream and system launcher since the start of the year. This is now also the default for the system theme and should improve the glanceability for wear apps. Developers should check the accessibility of their app’s UI after this change.
  • Limited background activity: To improve power, apps will no longer be allowed to run in the background unless the watch is on the charger. Developers should note that Wear OS is going further with Android’s app standby feature than some other form factors. Exceptions to this include watch faces and complications that the user currently has selected. This feature will be rolled out gradually in the developer preview, so you may not see it immediately on your device, but should build your apps accordingly by removing background services.
  • Turning off radios when off body: To improve power, bluetooth, WiFi, and cellular radios will be turned off when the watch is detected to be off body for an extended period of time. Again, this feature will be rolled out gradually so you may not initially see it on your device. If this feature causes challenges in your development process, you can disable the feature via adb; please follow the instructions in the release notes.
  • WiFi off when BT is disconnected: To improve power, the device will no longer automatically connect to wifi when disconnected from bluetooth. Exceptions include if an app is requesting a high bandwidth network or if the watch is on the charger. This feature will be rolled out gradually so you may not initially see it on your device.

Please give us your feedback

We expect to provide several 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.


Android Developers Blog

Mar 22

Android Developer Story: Hole19 improves user retention with Android Wear

Posted by Lily Sheringham, Google Play team

Based in Lisbon, Portugal, Hole19
is a golfing app which assists golfers before, during, and after their golfing
journey with GPS and a digital scorecard. The app connects the golfing community
with shared statistics for performance and golf courses, and now has close to 1
million users across all platforms.

Watch Anthony Douglas, Founder & CEO, and Fábio Carballo, Head Android Developer, explain how Hole19 doubled its number of Android Wear users in 6 months, and improved user engagement and retention on the platform. Also, hear how they are using APIs and the latest Wear 2.0 features to connect users to their golfing data and improve the user experience.


Learn
more how to get started with Android Wear and get the Playbook
for Developers app to stay up-to-date with more features and best practices
that will help you grow a successful business on Google Play.


Android Developers Blog

Mar 12

An Android Wear Design Story

By Roman Nurik and Timothy Jordan, Design and Developer Advocates on Android Wear

A few weeks ago, Timothy and I were chatting about designing apps for wearables to validate some of the content we’re planning for Google I/O 20141. We talked a lot about how these devices require scrutiny to preserve user attention while exposing some unique new surface areas for developers. We also discussed user context and how the apps we make should be opportunistic, presenting themselves in contexts where they’re useful; it’s more important than ever to think of apps on wearable devices not as icons on a grid but rather as functional overlays on the operating system itself.

But while I’d designed a number of touch UIs for Android in the past and Timothy had a ton of experience with Glass, neither of us had really gone through the exercise of actually designing an app for Android Wear. So we set out to put our ideas in practice and see what designing for this new platform is like.

Before we got started, we needed an idea. Last year, I participated in an informal Glass design sprint in NYC run by Nadya Direkova, and my sprint team came up with a walking tour app. The idea was you’d choose from a set of nearby tours, walk between the stops, and at each stop on the tour, learn about the destination.


My rough mocks of a walking tour app from a Glass design sprint.

While the design sprint ended at rough mocks, the idea stuck around in my mind, and came up again during this exercise. It seemed like a perfect example of a contextually aware app that could enhance your Android Wear experience.

Designing a walking tour app for Android Wear

We started fleshing out the idea by thinking through the app’s entry points: how will users “launch” this app? While exposing a “start XYZ walking tours app” voice command is pretty standard, it’d be interesting to also suggest nearby walking tours as you go about your day by presenting notifications in the user’s context stream. These notifications would be “low priority,” so you’d only see them after addressing the more important stuff like text messages from friends. And with today’s geofencing and location functionality in Google Play services, this type of contextual awareness is possible in a battery-friendly way.

At this point we were pretty excited and decided to begin mocking up the UI. Rather than starting from scratch, we used Taylor Ling’s excellent Android Wear 0.1 design template as a baseline, which includes templates for both square and round devices. We started with square since we were most familiar with rectangle UI design:



Idea: You get a notification in the context stream when a walking tour is available nearby.

I’ve got to admit, it was pretty thrilling designing in such a constrained environment. 140×140 dp (280×280 px @ XHDPI) isn’t a lot of space to work with, so you need to make some tough choices about when and how to present information. But these are exactly the types of problems that make design really, really fun. You end up spending more time thinking and less time actually pushing pixels around in Photoshop or Sketch.

We pretty quickly fleshed out the rest of the app for square devices. They included just a handful of additional screens: a dynamic notification showing the distance to your next stop, and a 4-page detail screen when you arrive at the tour stop, where you can spend a few moments reading about where you’re standing.



A notification guiding you to your next stop, and a multi-page stop detail screen for learning about the stop when you get there.

Seeing our design in real life

Here’s the thing—there’s only so much you can do in Photoshop. To truly understand a platform as a designer, you really need to use (and ideally live with) a real device, and see your work on that device. Only then can you fully evaluate the complexity of your flows, the size of your touch targets, or the legibility of your text.

Luckily, Timothy and I both had test devices—I sported an LG G Watch prototype and Timothy carried a Moto 360 prototype. We then needed a way to quickly send screens to our devices so we could iterate on the design. A few years ago I’d published the Android Design Preview tool that lets you mirror a part of your screen to a connected Android device. Much to our delight, the tool worked great with Android Wear! After seeing our mocks show up on my LG G Watch, we made a few small tweaks and felt much more confident that the overall idea “felt right” on the wrist.

Android Design Preview mirrors a part of your computer screen to an Android device. It’s especially awesome seeing your UI running on an LG G Watch prototype.

Designing for round devices

We’d never designed round UIs before, so we weren’t sure what this new adventure would be like. Quite frankly, it ended up being unbelievably easy: tweaking all 8 of our screen mocks for round took under an hour. When you’re only showing the most important 2 or 3 pieces of information on screen at a time, that’s only 2 or 3 pieces of information you need to optimize for round devices. All in all, there were only a few types of minor tweaks we made:

  • Scaled up backgrounds to 160×160 dp (320×320 px @ XHDPI)
  • Bumped up content margins from 12dp on square to 26dp on round; this means content was 116×116 dp on square and only a little smaller at 108×108 dp on round
  • Pushed down circular actions like “Continue tour” to better vertically center with the watch frame
  • Center-aligned certain short snippets of text on round devices as opposed to left-aligning on square
  • Dropped the side padding for context stream cards (the platform automatically does this for notifications, so there isn’t any actual work to do here)

These weren’t completely different layouts—rather, the same layout with slightly tweaked metrics.

It’s hard to articulate the excitement we felt when we mirrored the mocks to Timothy’s Moto 360 prototype with Android Design Preview. To put it lightly, our minds were blown.

There’s something special and awe-inspiring about seeing one of your UIs running on a round screen..

And that was it—with round and square mocks complete, and mirrored on our devices, we’d gotten our first glimpse at designing apps for this exciting new platform. Below are our completed mocks for the tour discovery and engagement flows, not a grid of app icons in sight. You can download the full PSDs here.


An eye-opening experience

Designing for Android Wear is pretty different from designing for the desktop, phones or tablets. Just like with Glass, you really need to think carefully about the information and actions you present to the user, and even more so about the contexts in which your app will come to the surface.

As a designer, that’s the fun part—working with constraints involving scarce resources like device size and user attention means it’s more important than ever to think deeply about your ideas and iterate on them early and often. The actual pixel-pushing part of the process is far, far easier.

So there we were, putting our ideas into practice, on real actual device prototypes that we could’ve only dreamed about only a few years ago. It was the most fun I’ve had designing UIs in a long time. Remember that feeling when you first dreamed up an app, mocked or even coded it up, and ran it on your Android phone? It was that same feeling all over again, but amplified, because you were actually wearing your app. I can’t wait for you all to experience it!


1 Have we mentioned #io14 will have tons of great content around both design and wearable computing? Make sure to tune in June 25th and 26th!

Join the discussion on

+Android Developers


Android Developers Blog

Feb 18

Always-on and Wi-Fi with the latest Android Wear update

Posted by Wayne Piekarski, Developer Advocate

A new update to Android Wear is rolling out with lots of new features like always-on apps, Wi-Fi connectivity, media browsing, emoji input, and more. Let’s discuss some of the great new capabilities that are available in this release.

Always-on apps

Above all, a watch should make it easy to tell the time. That’s why most Android Wear watches have always-on displays, so you can see the time without having to shake your wrist or lift your arm to wake up the display. In this release, we’re making it possible for apps to be always-on as well.

With always-on functionality, your app can display dynamic data on the device, even when the app is in ambient mode. This is useful if your app displays information that is continuously updated. For example, running apps like Endomondo, MapMyRun, and Runtastic use the always-on screen to let you keep track of how long and far you’ve been running. Zillow keeps you posted about the median price of homes nearby when you’re house-hunting.

Always-on functionality is also useful for apps that may not update data very frequently, but present information that’s useful for reference over a longer period of time. For example, Bring! lets you keep your shopping list right on your wrist, and Golfshot gives you accurate distances from tee to pin. If you’re at the airport and making your way to your gate, American Airlines, Delta, and KLM let you keep all of your flight info a glance away on your watch.

Note: the above apps will not display always-on functionality on your watch until you receive the update for the latest version of Android Wear.

Always-on functionality works similar to watch faces, in that the power usage of the display and processor is kept to a minimum by reducing the colors and refresh rate of the display. To implement an always-on Activity, you need to make a few small changes to your app’s AndroidManifest.xml, your app’s build.gradle, and the Activity to declare that it supports ambient mode. A code sample and documentation are available to show you how it works. Be sure to tune in to the livestream at Google I/O next week for Android Wear: Your app and the always-on screen.

Wi-Fi connectivity and cloud sync

Many existing Android Wear devices already contain hardware support for Wi-Fi, and this release enables software support for Wi-Fi. The saved Wi-Fi networks on your phone are copied to your watch during setup, and your watch automatically connects to those Wi-Fi networks when it loses Bluetooth connection to your phone. Your watch can then connect to your phone over the Internet, even if they’re not on the same Wi-Fi network.

You should continue to use the Data Layer API for all communications between the watch and phone. By using this standard API, your app will always work, no matter what kind of connectivity the user’s wearable supports. Cloud sync also introduces a new virtual node in the Data Layer called the cloud node, which may be returned in calls to getConnectedNodes(). Learn more in the Multi-wearable support section below.

Multi-wearable support

The release of Google Play services 7.3 now allows support for multiple wearable devices to be paired simultaneously to a single phone or tablet, so you can have a wearable for fitness, and another for dressing up. While DataItems will continue to work in the same way, since they are synchronized to all devices, working with the MessageApi is a little different. When you update your build.gradle to use version 7.3 or higher, getConnectedNodes() from the NodeApi will usually return multiple nodes. There is an extra virtual node added to represent the cloud node used to communicate over Wi-Fi, so all developers need to deal with this situation in their code.

To help simplify finding the right node among many devices, we have added a CapabilityApi, allowing your nodes to announce features they provide, for example downloading images or music. You can also now use the ChannelApi to open up a connection to a specific device to transfer large resources such as images or audio streams, without having to send them to all devices like you would when embedding assets into data items. We have updated our Android Wear samples and documentation to show the best practices in implementing this.

MediaBrowser support

The Android 5.0 release added the ability for apps to browse the media content of another app, via the android.media.browse API. With the latest Android Wear update, if your media playback app supports this API, then you will be able to browse to find the next song directly from your watch. This is the same browse capability used in Android Auto. You implement the API once, and it will work across a variety of platforms. To do so, you just need to allow Android Wear to browse your app in the onGetRoot() method validator. You can also add custom actions to the MediaSession that will appear as controls on the watch. We have a Universal Media Player sample that shows you how to implement this functionality.

Updates to existing devices

The latest version of Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. To take advantage of these new features, you will need to use targetSdkVersion 22 and add the necessary dependencies for always-on support. We have also expanded the collection of emulators available via the SDK Manager, to simulate the experience on all the currently available devices, resolutions, and shapes, including insets like the Moto 360.

In this update, we have also disabled support for apps that use the unofficial, activity-based approach for displaying watch faces, as announced in December. These watch faces will no longer work and should be updated to use the new watch face API.

Since the launch of Android Wear last summer, Android Wear has grown into a platform that gives users many possibilities to personalize their watches, with a variety of shapes and styles, a range of watch bands, and thousands of apps and watch faces. Features such as always-on apps and Wi-Fi allow developers even more flexibility to give users amazing experiences with Android Wear.


Android Developers Blog