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

        NotificationChannel("1001", "New Follower",

        NotificationChannel("1002", "Likes",

Background Limits

There are increased restrictions on background
. 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
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.

Updates to Google Play policy promote standalone Android Wear apps

Posted by Hoi Lam, Lead Developer
Advocate, Android Wear

Strava – a standalone wear app available to both Android and iOS users

Android Wear 2.0 represents the the latest evolution of the Android Wear
platform. It introduced the concept of standalone
that can connect to the network directly and work independently of a
smartphone. This is critical to providing apps not only to our Android users,
but also iOS users – which is increasingly important as we continue to expand
our diverse ecosystem of watches and users. In addition, Wear 2.0 brought
multi-APK support to Wear apps, which reduces the APK size of your phone apps,
and makes it possible for iOS users to experience your Wear apps.

Today, we are announcing that multi-APKs will also work for Android Wear 1.0
watches, so you can now reach all of your users without needing to bundle your
Wear app within your phone app’s APK. Additionally, the Google Play Store policy
will change to promote the use of multi-APKs and standalone apps. This covers
all types of apps that are designed to run on the watch, including watch faces,
complication data providers as well as launchable apps.

Policy change

The policy change will be effective from the 18th of January, 2018. At this
time, the following apps will lose the “Enhanced for Android Wear” badge in the
Google Play Store and will not be eligible to be listed in the top charts in the
Play Store for Android Wear:

  • Mobile apps that support Wear notification enhancements but do not have a
    separate Wear app.
  • Wear apps that are bundled with mobile apps instead of using

Since multi-APK is now supported by devices running Wear 1.0 and 2.0, developers
embedding their Wear app APKs in phone APKs should unbundle their Wear APK
and upload
it to the Play Store as a multi-APK
. This will allow them to continue to
qualify for the “Enhanced for Android Wear” badge as well as be eligible to
appear in the Android Wear top charts. The two APKs can continue to share the
same package name.

In addition to providing top app charts, we periodically put together curated
featured collections. To be eligible for selection for these collections,
developers will need to make their Wear apps function independently from the
phone, as a standalone app. These apps will need to work on watches that are
paired with both iOS and Android phones.

What are standalone apps?

are Wear apps that do not require a phone app to run. The app either
does not require network access or can access the network directly without the
phone app – something that is supported by Android Wear 2.0.

To mark your app as standalone, put the following meta-data tag in the

    android:value="true" />

In some rare cases, the user experience may be enhanced by the syncing of data
between the phone and watch. For example, a cycling app can use the watch to
display the current pace, and measure the user’s heart rate, while displaying a
map on the phone. In this scenario, we recommend that developers ensure that
their Wear apps function without a phone and treat the phone experience as
optional as far as the Wear apps are concerned. In these cases, a Wear app is
still considered standalone and should be marked as such in its
AndroidManifest.xml file.

Wear what you want

From the beginning, Android Wear has been about wear what you want — the
styles, watches, and apps you want to wear. This latest policy change lets you
highlight your Android Wear apps, giving users even more choice about what apps
they want on their watches.

How to improve app design for Wear 2.0

Posted by Steven Tepper, App Quality Consultant, Google Play

2.0 launched
back in February with added support for new hardware features
in addition to adopting new Material
Design themes
and a simpler vertical UI pattern. It also introduces a complications
, making it easier for apps to provide data to watch faces, and watch
faces to incorporate external data. The final big update was that, apps
targeting Wear 2.0 now have the ability to operate in a standalone
, without needing a connection to a companion app on the phone.

There are a few design considerations in relation to navigation, notifications,
the complications API, and the standalone functionality to help you better
optimize for Wear 2.0 devices:


  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent
    Simple navigation includes tasks such as accessing app
    settings, switching users or logging out. You can implement
    this on Wear 2.0 to switch between different views or sections of the app via a
    swipe down from the top of the screen, or an action drawer can be set up for
    context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users
    to navigate views quickly:
    A navigation drawer can be presented as
    either a multi-page or single-page drawer. The single-page layout is useful for
    when the user is expected to navigate quickly between 7 or less views of the
    app. Remember that if the app is using a single-page drawer, the iconography
    should be clear and understandable as there will not be any sort of text
    labeling in this layout. If there are more than 7 views to navigate to or the
    views are not easily represented by icons, you should instead use the multi-page
    drawer layout.

  3. Use multiple app launchers if your app has two or three discrete
    For example, if your app supports
    both activity tracking—with various options, actions,
    and views—and historical analysis and management of tracked activities, you can
    use multiple app launchers to handle these tasks. Alternatively, if your app has
    a simple home screen, these features could be placed in line, at the bottom of
    the screen.
  4. Use peeking at the top of the action drawer to provide quick access
    to the primary action:
    If there is no primary action associated with
    the view, override the default behavior and force an overflow button to peek
    instead, exposing all actions at the bottom of a view, when tapped.

Ensure that for devices using Wear 2.0, your app takes advantage of these new UI
patterns to provide a consistent user experience. Check out more training
resources for Wear
Navigation and Actions
and the Material Design specifications for Navigation
and Action


Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal
swiping gesture to present actions for a notification. Notification actions are
now presented as a single primary action (if applicable) at the bottom of a
notification. If there is no primary action, expanding the notification will
present options in a single, vertically scrollable view.

Notifications will work without needing many changes on both 1.x and 2.0
devices, but appear quite different:

When creating apps for Wear 2.0 devices, improve the user experience with
notifications by applying the following best practices:

  1. Support expandable notifications: Use BigTextStyle
    so that users can see more content on their watch.
  2. Use the collapsed view of the notification (if applicable):
    Add the primary action for your notification to the collapsed view of the
    notification using setContentIntent(), where appropriate.
  3. For messaging apps, use the MessagingStyle:
    Provide a rich chat app-like experience in the expanded notification using this
  4. Update user directions which are specific to Wear 1.0:
    Remove any text guiding users to act on a card by swiping horizontally
    (the Wear 1.x pattern).
  5. Enhancing notifications to use inline actions: This allows
    users to do things without needing tap to see the expanded notification details.
    Actions for messaging notifications can use several different input methods
    including Smart Reply presets, voice, and keyboard input. Take advantage of
    these features to provide added functionality and delight users.

To learn more about adding
wearable features to notifications


The complications API in Wear 2.0 makes it much easier for watch face developers
and third-party data providers to surface important information users want, at a
glance. Watch faces that support the API can be configured to use any of the
data providers that have been installed on the watch while maintaining complete
control over their appearance. Apps supporting the complication API allow the
app’s data to be accessible on any watch faces that support complications. These
complications can be displayed in a variety of forms (short text, icon, ranged
value, long text, small image, and large image) depending on what the data
provider has configured and how much space has been allocated on the watch face.

To ensure that complications fit the overall design of the watch face and
properly handle their data type, when adding complication support we recommend
watch face makers should:

  1. Use the TextRenderer
    class found in the Wear 2.0 SDK:
    This allows the text within
    complications to be adjusted to their bounds by shrinking the text, dynamically
    supporting line breaks or ellipsizing strings when they exceed the bounds of a
    text-based complication.
  2. Use the ComplicationDrawable
    class to set the background color, shape, border, and font options for the
    This gives complete control of how the complication is
    rendered to the watch face.
  3. Design the watch face to provide a way for users to configure or
    adjust complications on the watch face through a settings menu:
    learn how to construct these settings see the watch face sample
    on GitHub.
  4. Use the data provider test
    app to feed dummy data to the watch face complications:
    will enable you to verify that all of the complications render properly and have
    fonts formatted for their bounds.
  5. As a complication data provider, expose relevant data by using the

    Simply define and configure what types of ComplicationData
    the app can provide for complications.

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion
    app installed when using the hardware feature
    : Using this feature enables your app to become searchable and
    installable directly on Wear devices without needing to install a companion
    phone app, so ensure your app can handle itself to avoid a confusing or broken
    user experience.
  2. Ensure your wearable app doesn’t rely on the phone app for
    sign-in/authentication or primary functionality
    : When requiring
    complicated input for authentication (for example, password entry) your wearable
    app can point to the companion phone, but should rely on web UI for
    account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app
    in some other way, the app should use the CapabilityApi:

    This should be used to properly direct users to the Play Store listing on their
    companion device to install the missing app. Otherwise, the app should function
    on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.

  4. Include wording about any companion app requirements or briefly
    mention how your Wear app should function within the Play Store listing
    : This will help set expectations and guide users to install
    the correct apps for the best possible experience.
  5. Incorporate the
    flag in the manifest if your Wearable app can function without any phone
    companion interaction
    : This flag indicates that the wearable app can be
    installed and will fully function when not paired to an Android or iOS companion

Though a lot was covered here, there are additional resources you can use to
ensure that your apps or games are optimized and use the latest patterns and
functionality on Wear. Be sure to review
the quality guidelines
and check out the developer training documentation to
learn more best practices for wearable app
and wearable
app design
in order to build quality apps for Wear.

How useful did you find this blogpost?