Skip to content

Most visited

Recently visited

navigation

App Distribution

Important: The Wear 2.0 preview is over. Please see the main Android Wear documentation.

With Android Wear 2.0, a user can visit the Play Store on a watch and download a Wear app directly to the watch.

Generally, a Wear 2.0 app in the Play Store needs a minimum and target API level of 25 or higher in the Android manifest file. The minimum SDK level can be 23 only if you are using the same APK for Wear 1.x and 2.0 (and thus have an embedded Wear 1.x APK).

Publish Your APKs

To make your app appear in the on-watch Play Store, upload the watch APK in the Play Console just as you would any other APK. If you only have a watch APK and no phone APK, no other steps are required.

If you have a phone APK in addition to a watch APK, you must use the Multi-APK delivery method.

Run-time permissions are required.

Also see Standalone Apps.

Distribution to Wear 2.0 watches

If you only want your app to be distributed to Wear 2.0 watches, it is unnecessary to embed the watch APK inside the phone APK.

If you want your app to be distributed to Wear 1.x watches, you need to embed the watch APK inside the phone APK, as described below.

Note that the standard distribution model for Wear 1.x is embedding a watch APK inside a phone APK. Starting with Developer Preview 4, when a user installs a phone APK that has an embedded watch APK, the user is notified on the watch that the watch APK can be installed. Tapping on the notification opens the Play Store on the watch and allows the embedded watch APK to be installed. Additionally, if the phone APK is updated with a new embedded watch APK, the user's watch APK automatically is updated.

Distribution to Wear 1.x and 2.0 watches

If you are already distributing your app to Wear 1.x watches, follow these steps:

  1. Provide a Wear 2.0 (standalone) version of your watch APK that can be made available in the Play Store on Wear.
  2. Continue embedding a Wear 1.x APK in your phone APK, for use by watches that do not have Wear 2.0.

Specifying a version code

To ensure that a standalone APK upgrades an embedded Wear APK, the standalone Wear APK's version code generally should be higher than the embedded Wear APK's version code. (A phone APK's version code scheme can be independent from that of a watch APK, although they must be unique.) However, the version codes of the standalone APK and the embedded Wear APK can be the same if the APKs are equivalent. If the APKs are not equivalent, but the version code is the same, then when a watch updates from Wear 1.x to 2.0, the watch may get the new APK only after waiting for a longer-than-expected period of time.

Note that it currently is not possible to create a single APK that works on a phone and watch.

If your Wear APK and companion APK share code and require coordinated releases, you should reserve the last two digits of the version code for APK variants. An example of an APK variant is CPU architecture. See, for example, Supporting multiple CPU architectures.

Here is a suggested version code scheme:

If the example values (25,152, 01, and 00) in this suggested version code scheme are used, the version code for the example APK variant would be 251520100.

Also see Set Application Version Information.

Support in the Gradle file

If you have a Wear app that is intended for both Wear 1.x and Wear 2.0, consider using product flavors. For example, if you want to target both SDK version 23 and version 25, update your Wear module's build.gradle file to include the following if an existing embedded app has a minimum SDK version of 23:

android {
    // Allows you to reference product flavors in your
    // phone module's build.gradle file
    publishNonDefault true
    ...
    defaultConfig
    {
       // This is the minSdkVersion of the Wear 1.x embedded app
       minSdkVersion 23
       ...
    }
    buildTypes {...}
    productFlavors {
        wear1 {
          // Use the defaultConfig value
        }
        wear2 {
            minSdkVersion 25
        }
    }
}

Then update your phone module’s build.gradle file, replacing wearApp as follows:

dependencies {
    ...
    wearApp project(path: ':wear', configuration: 'wear1Release')
}

A build variant is a combination of the product flavor and build type. In Android Studio, select the appropriate build variant when debugging or publishing your app. For example, if wear2 is a product flavor, select wear2Release as the release build variant.

For purposes of code that is Wear 2.0-specific or Wear 1.x-specific, consider source sets for build variants.

Setting Up Targeting for a Watch

In your Android Manifest file, you must specify the following feature restriction: the uses-feature element is set to android.hardware.type.watch. Do not set the required attribute to false. A single APK for Wear and non-Wear devices presently is not supported.

Thus, if an APK has the following setting, Google Play provides the APK to watches only:

<manifest package="com.example.standalone"
    xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-feature
        android:name="android.hardware.type.watch"
    ...
</manifest>

The android.hardware.type.watch setting above can be combined with other criteria such as SDK version, screen resolution, and CPU architecture. Thus, different Wear APKs can target different hardware configurations.

Specifying an App as Standalone

Wear 2.0 requires a new meta-data element in the Android Manifest file of watch apps, as a child of the <application> element. The name of the new meta-data element is com.google.android.wearable.standalone and the value must be true or false. The new element indicates whether your watch app is a standalone app and thus doesn't require a phone-side Android app to operate. If this element is set to true, it indicates that the app can be made available in the Play Store on watches paired to iPhones.

A watch app may or may not be considered standalone. A watch app can be categorized as one of the following:

If a watch app is completely independent or semi-independent, set the value of the new meta-data element to true:

<application>
...
  <meta-data
    android:name="com.google.android.wearable.standalone"
    android:value="true" />
...
</application>

Since a standalone app (that is, an independent or semi-independent app) can be installed by an iPhone user or a user of an Android phone that lacks the Play Store, the watch app should be usable without the Android phone app.

If a watch app depends on a phone app, set the value of the above meta-data element to false. Setting the element to false signifies that the watch app should be installed only on a watch that is paired with a phone that has the Play Store.

Note: Even if the value is false, the watch app can be installed before the phone app is installed.

Using the Play Console

Below is an introduction to uploading a standalone Wear APK to an application listing using the Play Developer Console.

If your app supports both Wear 1.x and Wear 2.0, continue embedding the Wear 1.x APK (minimum SDK version of 20, 21, or 22, or 23) in the phone APK and upload the phone APK. In addition, upload your standalone Wear 2.0 APK (which has a minimum SDK version of 25).

Also see Multiple APK Support and Manage Your App. Before uploading an APK as described below, the APK must be signed.

Uploading your APK

Go to the Play Developer Console, navigate to your application listing, and select APK in the left-navigation panel. An APK screen similar to the following is displayed:

alt_text

You may need to use advanced mode for uploads, as follows:

Therefore, on the above APK screen, to determine whether to click the Switch to advanced mode button, consider the following:

See Simple mode and advanced mode for more information about toggling between modes.

Select the appropriate tab (Production, Beta Testing, or Alpha Testing) for your upload. Then click the Upload New APK button and select your standalone Wear APK for upload.

Reviewing and publishing

After you upload your standalone Wear APK and scroll down the resulting page, the APK is shown in the Current APK table, with a version number, in a similar way to the following:

alt_text

Finally, in the Current APK table above, click the line with the Version to review the APK. The APK Details panel is displayed. You can verify, for example, that the number in the Supported Android Devices line is far fewer than the number would be for a typical phone APK:

alt_text

When you are ready, publish your app.

This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.