Tag Archives: wear

Announcing Glance: Tiles for Wear OS made simple

Posted by Anna Bernbaum, Associate Product Manager


Last year we announced the Wear Tiles API. To complement that Java API, we are excited to announce that support for Wear OS Tiles has been added to Glance, a new framework built on top of Jetpack Compose designed to make it easier to build for surfaces outside your app on Android. We'd love to get your feedback on this alpha version.

Tiles provide Wear OS users easy access to the information and actions they need in order to get things done quickly. They also are one of the most used surfaces on Wear OS. Just one swipe away from the Watch Face, users can quickly access the most important information or actions from an app, like start a timer or get the latest weather forecast.


Watch face gif


Let's see how we can create a Tile with Glance:


class HelloTileService : GlanceTileService() {
   @Composable
   override fun Content() {
       Text(text = "Hello Glance")
   }
}

The simple code above generates the Tile below.


“Hello Glance” Tile sample with Glance

“Hello Glance” Tile sample with Glance


Note: Using Glance-wear-tiles requires`minSdkVersion`>= 26.



How it works

Glance creates “glanceable” experiences across Android surfaces using a base-set of Composables. For Tiles on Wear OS, Glance translates Composables into Tiles.


Diagram: Glance structure 

Diagram: Glance structure


Glance requires Compose to be enabled and depends on Runtime, Graphics, and Unit UI Compose layers, but it’s not directly interoperable with other existing Jetpack Compose UI elements, like Compose for Wear OS.

What’s in the Alpha

This initial release introduces the main APIs to build wear Tiles:

We are working on bringing even more functionality with default theming, further Android Studio support, and more. Stay tuned for new releases.

Get started with Glance

For a quick start, take a look at the samples in the AndroidX repository. Glance works with the latest stable Android Studio, although since Glance relies on Compose Runtime, follow the steps on the Jetpack Compose docs to set it up first.

The Alpha version is your opportunity to influence the APIs, so please share your feedback and let us know your experience!

Happy Composing with Glance!

Develop watch faces with the stable Jetpack Watch Face library

Posted by Alex Vanyo, Developer Relations Engineer

Illustration of tan hand showing a watch

Watch faces are one of the most visible ways that people express themselves on their smartwatches, and they’re one of the best ways to display your brand to your users.

Watch Face Studio from Samsung is a great tool for creating watch faces without writing any code. For developers who want more fine-tuned control, we've recently launched the Jetpack Watch Face library written from the ground up in Kotlin.

The stable release of the Jetpack Watch Face library includes all functionality from the Wearable Support Library and many new features that make it easier to support customization on the smartwatch and on the system companion app on mobile, including:

  • Watch face styling which persists across both the watch and phone (with no need for your own database or companion app).
  • Support for a WYSIWYG watch face configuration UI on the phone.
  • Smaller, separate libraries (that only include what you need).
  • Battery improvements through encouraging good battery usage patterns out of the box, such as automatically reducing the interactive frame rate when battery is low.
  • New screenshot APIs so users can see previews of their watch face changes in real time on both the watch and phone.

If you are still using the Wearable Support Library, we strongly encourage migrating to the new Jetpack libraries to take advantage of the new APIs and upcoming features and bug fixes.


Below is an example of configuring a watch face from the phone with no code written on or for the phone.

GIF showing how to edit a watch face using the Galaxy Wearable mobile companion app

Editing a watch face using the Galaxy Wearable mobile companion app


If you use the Jetpack Watch Face library to save your watch face configuration options, the values are synced with the mobile companion app. That is, all the cross-device communication is handled for you.

The mobile app will automatically present those options to the user in a simple, intuitive user interface where they change them to whatever works best for their style. It also includes previews that update in real time.

Let’s dive into the API with an overview of the most important components for creating a custom watch face!


WatchFaceService

A subclass of WatchFaceService forms the entry point of any Jetpack watch face. Implementing a WatchFaceService requires creating 3 objects: A UserStyleSchema, a ComplicationSlotsManager, and a WatchFace:

Diagram showing the 3 main parts of a WatchFaceService

Diagram showing the 3 main parts of a WatchFaceService

These 3 objects are specified by overriding 3 abstract methods from WatchFaceService:

class CustomWatchFaceService : WatchFaceService() {

    /**
     * The specification of settings the watch face supports.
     * This is similar to a database schema.
     */
    override fun createUserStyleSchema(): UserStyleSchema = // ...

    /**
     * The complication slot configuration for the watchface.
     */
    override fun createComplicationSlotsManager(
        currentUserStyleRepository: CurrentUserStyleRepository
    ): ComplicationSlotsManager = // ...

    /**
     * The watch face itself, which includes the renderer for drawing.
     */ 
    override suspend fun createWatchFace(
        surfaceHolder: SurfaceHolder,
        watchState: WatchState,
        complicationSlotsManager: ComplicationSlotsManager,
        currentUserStyleRepository: CurrentUserStyleRepository
    ): WatchFace = // ...

}

Let’s take a more detailed look at each one of these in turn, and some of the other classes that the library creates on your behalf.


UserStyleSchema

The UserStyleSchema defines the primary information source for a Jetpack watch face. The UserStyleSchema should contain a list of all customization settings available to the user, as well as information about what those options do and what the default option is. These settings can be boolean flags, lists, ranges, and more.

By providing this schema, the library will automatically keep track of changes to settings by the user, either through the mobile companion app on a connected phone or via changes made on the smartwatch in a custom editor activity.

    override fun createUserStyleSchema(): UserStyleSchema =
        UserStyleSchema(
            listOf(
                // Allows user to change the color styles of the watch face
                UserStyleSetting.ListUserStyleSetting(
                    UserStyleSetting.Id(COLOR_STYLE_SETTING),
                    // ...
                ),
                // Allows user to toggle on/off the hour pips (dashes around the outer edge of the watch
                UserStyleSetting.BooleanUserStyleSetting(
                    UserStyleSetting.Id(DRAW_HOUR_PIPS_STYLE_SETTING),
                    // ...
                ),
                // Allows user to change the length of the minute hand
                UserStyleSetting.DoubleRangeUserStyleSetting(
                    UserStyleSetting.Id(WATCH_HAND_LENGTH_STYLE_SETTING),
                    // ...
                )
            )
        )

CurrentUserStyleRepository

The current user style can be observed via the ​​CurrentUserStyleRepository, which is created by the library based on the UserStyleSchema.

It gives you a UserStyle which is just a Map with keys based on the settings defined in the schema:

Map<UserStyleSetting, UserStyleSetting.Option>

As the user’s preferences change, a MutableStateFlow of UserStyle will emit the latest selected options for all of the settings defined in the UserStyleSchema.

currentUserStyleRepository.userStyle.collect { newUserStyle ->
    // Update configuration based on user style
}

CurrentUserStyleRepository

Complications allow a watch face to display additional information from other apps on the watch, such as events, health data, or the day.

The ComplicationSlotsManager defines how many complications a watch face supports, and where they are positioned on the screen. To support changing the location or number of complications, the ComplicationSlotsManager also uses the ​​CurrentUserStyleRepository.

    override fun createComplicationSlotsManager(
        currentUserStyleRepository: CurrentUserStyleRepository
    ): ComplicationSlotsManager {
        val defaultCanvasComplicationFactory =
            CanvasComplicationFactory { watchState, listener ->
                // ...
            }
    
        val leftComplicationSlot = ComplicationSlot.createRoundRectComplicationSlotBuilder(
            id = 100,
            canvasComplicationFactory = defaultCanvasComplicationFactory,
            // ...
        )
            .setDefaultDataSourceType(ComplicationType.SHORT_TEXT)
            .build()
    
        val rightComplicationSlot = ComplicationSlot.createRoundRectComplicationSlotBuilder(
            id = 101,
            canvasComplicationFactory = defaultCanvasComplicationFactory,
            // ...
        )
            .setDefaultDataSourceType(ComplicationType.SHORT_TEXT)
            .build()

        return ComplicationSlotsManager(
            listOf(leftComplicationSlot, rightComplicationSlot),
            currentUserStyleRepository
        )
    }

WatchFace

The WatchFace describes the type of watch face and how to draw it.

A WatchFace can be specified as digital or analog and can optionally have a tap listener for when the user taps on the watch face.

Most importantly, a WatchFace specifies a Renderer, which actually renders the watch face:

    override suspend fun createWatchFace(
        surfaceHolder: SurfaceHolder,
        watchState: WatchState,
        complicationSlotsManager: ComplicationSlotsManager,
        currentUserStyleRepository: CurrentUserStyleRepository
    ): WatchFace = WatchFace(
        watchFaceType = WatchFaceType.ANALOG,
        renderer = // ...
    )

Renderer

The prettiest part of a watch face! Every watch face will create a custom subclass of a renderer that implements everything needed to actually draw the watch face to a canvas.

The renderer is in charge of combining the UserStyle (the map from ​​CurrentUserStyleRepository), the complication information from ComplicationSlotsManager, the current time, and other state information to render the watch face.

class CustomCanvasRenderer(
    private val context: Context,
    surfaceHolder: SurfaceHolder,
    watchState: WatchState,
    private val complicationSlotsManager: ComplicationSlotsManager,
    currentUserStyleRepository: CurrentUserStyleRepository,
    canvasType: Int
) : Renderer.CanvasRenderer(
    surfaceHolder = surfaceHolder,
    currentUserStyleRepository = currentUserStyleRepository,
    watchState = watchState,
    canvasType = canvasType,
    interactiveDrawModeUpdateDelayMillis = 16L
) {
    override fun render(canvas: Canvas, bounds: Rect, zonedDateTime: ZonedDateTime) {
        // Draw into the canvas!
    }

    override fun renderHighlightLayer(canvas: Canvas, bounds: Rect, zonedDateTime: ZonedDateTime) {
        // Draw into the canvas!
    }
}

EditorSession

In addition to the system WYSIWYG editor on the phone, we strongly encourage supporting configuration on the smartwatch to allow the user to customize their watch face without requiring a companion device.

To support this, a watch face can provide a configuration Activity and allow the user to change settings using an EditorSession returned from EditorSession.createOnWatchEditorSession. As the user makes changes, calling EditorSession.renderWatchFaceToBitmap provides a live preview of the watch face in the editor Activity.

To see how the whole puzzle fits together to tell the time, check out the watchface sample on GitHub. To learn more about developing for Wear OS, check out the developer website.

Watch out for Wear OS at Android Dev Summit 2021

Posted by Jeremy Walker, Developer Relations Engineer

image of 4 watch faces against dark blue background.

This year’s Android Dev Summit had many exciting announcements for Android developers, including some major updates for the Wear OS platform. At Google I/O, we announced the launch of the new Wear OS. Since then, Wear OS Powered by Samsung has launched on the Galaxy Watch4 series. Many developers such as Strava, Spotify, and Calm have already created helpful experiences for the latest version of Wear OS, and we’re looking forward to seeing what new experiences developers will help bring to the watch. To learn more and create better apps for the wrist, read more about the updates to our APIs, design tools, and the Play store.


Compose for Wear OS

The Jetpack Compose library simplifies and accelerates UI development, and we’re bringing Compose support to Wear OS. You can design your app with familiar UI components, adapted for the watch. These components include Material You, so you can create beautiful apps with less code.

Compose for Wear OS is now in developer preview. To learn more and get started:

Try it out and share your feedback here or join the #compose-wear channel on the Jetbrains Slack and let us know there! Make sure you do it before we finalize APIs during beta!


Watch Face Studio

image of clock face in editing software

Watch faces are one of the most visible ways that users can express themselves on their smartwatches. Creating a watch face is a great way to showcase your brand for users on Wear OS. We’ve partnered with Samsung to provide better tools for watch face creation and make it easier to design watch faces for the Wear OS ecosystem.

Watch Face Studio is a design tool created by Samsung that allows you to produce and distribute your own watch faces without any coding. It includes includes intuitive graphics tools to allow you to easily design watch faces. You can create watch faces for your personal use, or upload them in Google Play Console to share with your users on Wear OS devices that support API level 28 and above.


Library updates

We recently released a number of Android Jetpack Wear OS libraries to help you follow best practices, reduce boilerplate, and create performant, glanceable experiences for your users.

Tiles are now enabled for most devices in the market, providing predictable, glanceable access to information and quick actions. The API is now in beta, check it out!

For developers who want more fine-grain control of their watch faces (outside of Watch Face Studio), we've launched the new Jetpack Watch Face APIs beta built from the ground up in Kotlin.

The new API offers a number of new features:

  • Watch face styling which persists across both the watch and phone (no need for your own database).
  • Support a WYSIWYG watch face configuration UI on the phone.
  • Smaller, separate libraries (only include what you need).
  • Battery improvements by encouraging good battery usage patterns out of the box; for example, reducing the interactive frame rate when battery is low.
  • New Screenshot APIs so users can see their watch face changes in real time.
  • And many more...

This is a great time to start moving from the older Watch Face Support Library to this new version.


Play Store updates

We’re making it easier for people to discover your Wear OS apps in the Google Play Store. Earlier this year, we enabled searching for watch faces and made it easier for people to find your apps in the Wear category. We also launched the capability for people to download apps onto their watches directly from the mobile Play Store. You can read more about these changes here.

We’ve also released updated Wear OS quality guidelines to help you meet your users’ expectations, as well as new screenshot guidelines to help your users have a better understanding of what your app will look like. To help people better understand how your app would work on their device in their location, we will be launching form factor and location specific ratings in 2022.

To learn more about developing for Wear OS, check out the developer website.

Privacy protections for physical activity in Android 10

Since Google Fit was released in 2015, apps with an abundance of features for health and fitness tracking have integrated with the Google Fit APIs. Over the years, the number of users using Google Fit as a central repository for their fitness and wellness data has grown significantly.

With Android 10, we're making further updates to give users even more control over this personal data. One key change concerns how Android apps can monitor a user’s physical activity and retrieve data from Android sensor APIs and the Google Fit platform.

In Android 10: Activity recognition permission

Android 10 introduces a new runtime permission for activity recognition for apps that make use of the user's step and calorie count or classify the user's physical activity, such as walking, biking, or moving in a vehicle through one of the following APIs:

If your app relies only on raw data from other built-in sensors on the device, such as the accelerometer and gyroscope, you don't need to declare this new permission in your app.

Activity Recognition Permission Enforcement

  • Starting December 2019, data will be restricted from apps not including the Google Play Services legacy activity recognition permission in the manifest. If your app doesn’t currently request this permission, you should add it today to ensure no loss of service for your users.
  • When a user upgrades to Android 10, the system auto-grants this permission to your app if it previously requested the legacy permission.
  • As you begin targeting Android 10, you should register the ACTIVITY_RECOGNITION permission and adopt the new permission model to adhere to the new policy.

Google Fit physical activity APIs

This new permission affects a subset of data types available in the Google Fit APIs on Android. If your app accesses these types from Google Fit today, then you need to update your app inline with the new permissions.

The activity recognition runtime permission is required for accessing the following APIs / data types:

  • RecordingAPI - recording the following data types:
    • com.google.step_count.delta
    • com.google.step_count.cadence
    • com.google.activity.segment
    • com.google.calories.expended
  • HistoryAPI - reading the following data types:
    • com.google.step_count.delta
    • com.google.step_count.cadence
    • com.google.activity.segment
    • com.google.activity.exercise
    • com.google.activity.summary

With Android 10 now launched and SDK 29 becoming your primary development target, now is the time to make sure your apps are compatible with the new runtime permission.

Android Wear SDK and Emulator Update

Posted by Hoi Lam, Lead Developer Advocate, Android Wear
Today we launched the latest version of the Android Wear SDK (2.2.0) with several watch face related enhancements. These include the addition of an unread notification indicator for all watch faces, which is planned to be part of the upcoming consumer release of Android Wear. With the Wear SDK 2.2.0, you can customize the notification indicator or display your own. This feature is available to the developer community early, via the SDK and emulator, so you can verify that the indicator fits the design of your watch face. In addition, we are adding enhancements to the ComplicationDrawable class and publishing the final version of the Wear emulator based on Android Oreo.

Introducing the unread notification indicator


Notification is a vital part of the Wear experience. As a result, starting from the next consumer release of Wear (version 2.9.0), a dot-shaped indicator will be displayed by default at the bottom of the watch face if there are new, unread notifications. Watch face developers can preview the indicator with their watch faces by using the latest version of the emulator. Developers can customise the indicator's accent color via WatchFaceStyle.setAccentColor - the default color is white as shown in the example below, but developers can set the color for the ring around the dot to an accent color of their choice, to match the rest of the watch face.
If the new indicator does not fit with the design of your watch face, you can switch it off using WatchFaceStyle.setHideNotificationIndicator and choose another option for displaying the notification, including: 1) displaying the number of unread notifications in the system tray using WatchFaceStyle.setShowUnreadCountIndicator, or 2) getting the number of unread notifications using WatchFaceStyle.getUnreadCount and displaying the number in a way that fits your watch face's unique style.

Enhancement to ComplicationDrawable


We launched the ComplicationDrawable class at last year's Google I/O, and we are continuing to improve it. In this latest SDK release, we added two enhancements:
  • Permission Handling - If the watch face lacks the correct permission to display the content of a complication, the complication type of TYPE_NO_PERMISSION is issued. ComplicationDrawable now handles this automatically and will launch a permission request in onTap. If you previously implemented your own code to start the permission screen, please check that the permission screen is not triggered twice and, if necessary, remove unneeded code.
  • Drawable Callback - If a complication contains an image or an icon, it can take a small amount of time to load after the other initial data arrives. Our previous recommendation therefore was that you redraw the screen every second. But this is unnecessary for watch faces that only update once per minute, for example. As a result, we have added new support for Drawable.Callback to ComplicationDrawable. Developers who update the screen less frequently than once per second should adopt this new callback to redraw the watch face when images have loaded.
For more, please see the Android Wear Release Notes which includes other information regarding the emulator.

More improvements to come


Many of you have noticed a steady release of enhancements to Android Wear over the last few months since the launch of Wear 2.0. We are developing many more for the months ahead and look forward to sharing more when the features are ready.



Android Wear Beta

Posted by Hoi Lam, Lead Developer Advocate, Android Wear
LG Watch Sport

Today, we are launching the beta of the next Android Wear update. As we mentioned at Google I/O, this will mainly be a technical upgrade to API 26 with enhancements to background limits and notification channels. LG Watch Sport users can go to this webpage to sign up and the factory image will automatically be downloaded to the watch you enroll. As this is a beta, please be sure to review the known issues before enrolling. If you don't have a watch to test on, you can use the Android emulator. For developers working with Android Wear for China, an updated emulator image is also available.

Notification Channels

In this update, users can choose the types of notifications they receive via an app through notification channels. This gives users finer-grained control than muting all notifications from the app. For notifications generated locally by Android Wear apps, users will be able to customise the notifications channel they want to see, right on their watch. Please refer to the Wear notification sample for more details. For notifications bridged from the phone, the phone notifications channel settings will dictate what is shown on the watch.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    mNotificationManager.createNotificationChannel(
        NotificationChannel("1001", "New Follower",
            NotificationManager.IMPORTANCE_DEFAULT))

    mNotificationManager.createNotificationChannel(
        NotificationChannel("1002", "Likes",
            NotificationManager.IMPORTANCE_LOW))
}

Background Limits

There are increased restrictions on background services. Developers should assume services can no longer run in the background without a visible notification. In addition, the background location update frequency will be reduced. Battery-saving best practices such as using JobScheduler should be adopted to ensure your app is battery-efficient and able to perform background tasks when possible.

Please give us your feedback

We expect this to be the only beta release before the final production release. Thank you for your feedback so far. Please submit any bugs you find via the Android Wear issue tracker. The earlier you submit them, the higher the likelihood that we can include the fixes in the final release.

Get a glimpse of Wear 2.0’s upcoming standalone apps

Kacey Fahey, Marketing Programs Manager, Google Play

The upcoming Android Wear 2.0 experience will introduce standalone apps, expanding your potential reach to both Android and iOS audiences with Wear devices. Users will be able to search, install, and use apps without ever leaving their device. See how other developers are enhancing their user experience with standalone apps for messaging, travel & local, and health & fitness.

Glide

Having a watch app further simplifies video messaging with Glide. Using the Wear Complications API, Glide is now able to live broadcast directly from the watch face. By tapping contact shortcuts from the watch face, you can now launch directly into a conversation. This experience brings speed and intimacy to the world of messaging, making wrist-based communication more accessible and effortless.
Foursquare

Travelers around the world use Foursquare’s Android Wear app to discover hidden gems and be in the know about the best places to eat, drink and explore. With their upcoming 2.0 app, the team has a clean new canvas for rich notifications giving users an immersive experience with Foursquare content.

“The standalone nature of the Android Wear 2.0 app will offer a big boost in search performance and app responsiveness so you spend less time staring at the screen and more time exploring the world around you,” said Kyle Fowler, Software Engineer at Foursquare.
Lifesum

Lifesum helps users make better food choices, improve their exercise, and reach health goals. The upcoming 2.0 experience complements the existing Lifesum mobile app and as a standalone app, it will allow users to more easily track water and meals throughout the day.

“It's all about increasing access and being there for the user in a quick and simple way. We believe a simplified way of tracking meals and water will make it easier for our users on their journey of becoming healthier and happier,” said Joakim Hammer, Android Developer at Lifesum

Check out g.co/wearpreview for the latest builds and documentation about the recently released Android Wear Developer Preview 4.
How useful did you find this blogpost?


Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more

Posted by Hoi Lam, Developer Advocate

A key part of Android Wear 2.0 is letting watch apps work as standalone apps, so users can respond to messages, track their fitness, and use their favorite apps, even when their phone isn't around. Developer Preview 4 includes a number of new APIs that will help you build more powerful standalone apps.

Seamless authentication

To make authentication a seamless experience for both Android phone and iPhone users, we have created new APIs for OAuth and added support for one-click Google Sign-in. With the OAuth API for Android Wear, users can tap a button on the watch that opens an authentication screen on the phone. Your watch app can then authenticate with your server side APIs directly. With Google Sign-In, it's even easier. All the user needs to do is select which account they want to authenticate with and they are done.

In-app billing

In addition to paid apps, we have added in-app billing support, to give you another way to monetize your Android Wear app or watch face. Users can authorize purchases quickly and easily on the watch through a 4-digit Google Account PIN. Whether it's new levels in a game or new styles on a watch face, if you can build it, users can buy it.

Cross-device promotion

What if your watch app doesn't work standalone? Or what if it offers a better user experience when both the watch and phone apps are installed? We've been listening carefully to your feedback, and we've added two new APIs (PlayStoreAvailability and RemoteIntent) to help you navigate users to the Play Store on a paired device so they can more easily install your app. Developers can also open custom URLs on the phone from the watch via the new RemoteIntent API; no phone app or data layer is required.

// Check Play Store is available
int playStoreAvailabilityOnPhone =
    PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());

if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
    // To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")
    Intent intent =
        new Intent(Intent.ACTION_VIEW)
            .addCategory(Intent.CATEGORY_BROWSABLE)
            .setData(Uri.parse("market://details?id=com.google.android.wearable.app"));
    // mResultReceiver is optional; it can be null.
    RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);
}

Swipe-to-dismiss is back

Many of you have given us the feedback that the swipe-to-dismiss gesture from Android Wear 1.0 is an intuitive time-saver. We agree, and have reverted back to the previous behavior with this developer preview release. To support swipe-to-dismiss in this release, we've made the following platform and API changes:

  • Activities now automatically support swipe-to-dismiss. Swiping an activity from left to right will result in it being dismissed and the app will navigate down the back stack.
  • New Fragment and View support. Developers can wrap the containing views of a Fragment or Views in general in the new SwipeDismissFrameLayout to implement custom actions such as going down the back stack when the user swipes rather than exiting the activity.
  • Hardware button now maps to "power" instead of "back" which means it can no longer be intercepted by apps.

Additional details are available under the behavior changes section of the Android Wear Preview site.

Compatibility with Android Wear 1.0 apps

Android Wear apps packaged using the legacy embedded app mechanism can now be delivered to Android Wear 2.0 watches. When a user installs a phone app that also contains an embedded Android Wear app, the user will be prompted to install the embedded app via a notification. If they choose not to install the embedded app at that moment, they can find it in the Play Store on Android Wear under a special section called "Apps you've used".

Despite support for the existing mechanism, there are significant benefits for apps that transition to the multi-APK delivery mechanism. Multi-APK allows the app to be searchable in the Play Store on Android Wear, to be eligible for merchandising on the homepage, and to be remotely installed from the web to the watch. As a result, we strongly recommend that developers move to multi-APK.

More additions in Developer Preview 4

  • Action and Navigation Drawers: An enhancement to peeking behavior allows the user to take action without scrolling all the way to the top or bottom of a list. Developers can further fine-tune drawer peeking behavior through new APIs, such as setShouldPeekOnScrollDown for the action drawer.
  • WearableRecyclerView: The curved layout is now opt-in, and with this, the WearableRecyclerView is now a drop-in replacement for RecyclerView.
  • Burn-in protection icon for complications: Complication data providers can now provide icons for use on screens susceptible to burn-in. These burn-in-safe icons are normally the outline of the icon in interactive mode. Previously, watch faces may have chosen not to display the icon at all in ambient mode to prevent screen burn-in.

Feedback welcome!

Thanks for all your terrific feedback on Android Wear 2.0. Check out g.co/wearpreview for the latest builds and documentation, keep the feedback coming by filing bugs or posting in our Android Wear Developers community, and stay tuned for Android Wear Developer Preview 5!

Android Wear 2.0 Developer Preview 2

Posted by Hoi Lam, Android Wear Developer Advocate

At Google I/O 2016, we launched the Android Wear 2.0 Developer Preview, which gives developers early access to the next major release of Android Wear. Since I/O, feedback from the developer community has helped us identify bugs and shape our product direction. Thank you!

Today, we are releasing the second developer preview with new functionalities and bug fixes. Prior to the consumer release, we plan to release additional updates, so please send us your feedback early and often. Please keep in mind that this preview is a work in progress, and is not yet intended for daily use.

What’s new?

  • Platform API 24 - We have incremented the Android Platform API version number to 24 to match Nougat. You can now update your Android Wear 2.0 Preview project’s compileSdkVersion to API 24, and we recommend that you also update targetSdkVersion to API 24.
  • Wearable Drawers Enhancements - We launched the wearable drawers as part of the Android Wear 2.0 Preview 1, along with UX guidelines on how to best integrate the navigation drawer and action drawer in your Android Wear app. In Preview 2, we have added additional support for wearable drawer peeking, to make it easier for users to access these drawers as they scroll. Other UI improvements include automatic peek view and navigation drawer closure and showing the first action in WearableActionDrawer’s peek view. For developers that want to make custom wearable drawers, we’ve added peek_view and drawer_content attributes to WearableDrawerView. And finally, navigation drawer contents can now be updated by calling notifyDataSetChanged.
  • Wrist Gestures: Since last year, users have been able to scroll through the notification stream via wrist gestures. We have now opened this system to developers to use within their applications. This helps improve single hand usage, for when your users need their other hand to hold onto their shopping or their kids. See the code sample below to get started with gestures in your app:
 public class MainActivity extends Activity {  
   ...    
   @Override /* KeyEvent.Callback */  
   public boolean onKeyDown(int keyCode, KeyEvent event) {  
     switch (keyCode) {  
       case KeyEvent.KEYCODE_NAVIGATE_NEXT:  
         Log.d(TAG, "Next");  
         break;  
       case KeyEvent.KEYCODE_NAVIGATE_PREVIOUS:  
         Log.d(TAG, "Previous");  
         break;  
     }  
     // If you did not handle, then let it be handled by the next possible element as deemed by  
     // Activity.  
     return super.onKeyDown(keyCode, event);  
   }  
 }  

Get started and give us feedback!

The Android Wear 2.0 Developer Preview includes an updated SDK with tools and system images for testing on the official Android emulator, the LG Watch Urbane 2nd Edition LTE, and the Huawei Watch.

To get started, follow these steps:

  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 from the developer preview downloads page
  5. Test your app with your supported device or emulator
  6. Give us feedback

We will update this developer preview over the next few months based on your feedback. The sooner we hear from you, the more we can include in the final release, so don't be shy!

Watch your language! 44 of them, actually.

More than 500 million people use Google Translate every month across web and mobile phones, translating more than 100 billion words every day around the globe. Now, we’re launching Google Translate on all Android Wear watches, too.

Translate is built into the latest Android Wear software update, so you can have bilingual conversations even if you don’t have Google Translate on your phone, or if you’re away from your phone but connected via Wi-Fi.

And it’s easy to use - just speak into your watch to see your conversation translated into any of 44 languages. Flip your wrist to show the translation to a friend. When they respond in their own language, flip your wrist back, and you’ll see in your language what they’ve just said. Google Translate will automatically recognize which of the two languages is being spoken, so once you tap to start the conversation, all you and your buddy need to do is keep talking naturally.
Google Translate covers 90 languages total (for text translation), and we are always working to expand the number of languages that work across various features.