Package and distribute Wear apps

With Wear OS by Google, a user can visit the Play Store on a watch and download a Wear app directly to the watch. Additionally, a user can install an app directly onto their watch via the web Play Store.

All devices that are running Wear 2.0 are using Android 7.1.1 (API level 25). If your app only supports devices running Wear 2.0 or higher, the minimum and target API level should be 25. If your app supports both Wear 1.x and 2.0, the minimum and target API level can be 23. All Wear apps must target API level 23 or higher, so run-time permissions are required.

Also see Standalone Apps.

When a Wear 2.0 app has a companion app, you must use the same key to sign each of the two apps. This requirement also holds true for a Wear 1.x app (which always has a companion app).

Plan for the Play Store

To make your app appear in the on-watch Play Store, you 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.

Distribution to Wear 2.0 watches

On devices running Wear 2.0, when a user installs a phone app that has an associated watch app (either an embedded APK or an APK uploaded via the Play Console), the user gets a watch notification about the available watch app. Tapping the notification opens the watch Play Store, giving the user the option to install the watch app.

Additionally:

When you update a phone APK with a new embedded watch APK, the user's watch APK automatically is updated.
When you upload a watch APK via the Play Console, you can update your Wear APK independently from the phone APK, and users receive updates via the watch Play Store.
For an embedded watch APK, the user's watch APK is automatically updated when the APK on the phone is updated. In the case of multi-APK, the update behavior depends on the Play Store setting (Auto-update apps). It is strongly discouraged to have both an embedded APK and multi-APK for your app if they are not the same version. Take an example where you have an embedded APK v1, and multi-APK v2. If the embedded APK is installed first, the multi-APK version will replace the embedded APK since it is a higher version. Later, if a developer updates the phone APK to v3, an embedded APK will be automatically installed, overriding the higher version delivered via multi-APK.

Distribution to Wear 1.x and 2.0 watches

The standard distribution model for Wear 1.x was embedding a watch app inside a phone app. Wear OS now allows you to distribute your Wear app the same way for both Wear 1.0 and 2.0. When a user installs your phone app, if you have a compatible Wear app in the Play Store, it will automatically be installed on Wear 1.0 watches. This feature allows you to stop embedding Wear apps within your phone app's APK. You can provide standalone versions of your watch APK in the Play Store for both Wear 1.0 and Wear 2.0 watches.

Specify a version code

To ensure that a standalone APK upgrades an existing, embedded Wear APK on a watch, 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 codes are 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.

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:

Set the first two digits of the version code to the targetSdkVersion, e.g. 25
Set the next three digits to the product version, e.g. 152 for a product version of 1.5.2
Set the next two digits to build or release number, e.g. 01
Reserve the last two digits for a multi-APK variant, e.g. 00

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 Wear 1.x 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 app
       minSdkVersion 23
       ...
    }
    buildTypes {...}
    productFlavors {
        wear1 {
          // Use the defaultConfig value
        }
        wear2 {
            minSdkVersion 25
        }
    }
}

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.

Migrate a Wear 1.0 APK from embedded to Multi-APK

Note: Due to a latency issue affecting an app's availability on Wear 1.x watches, you can embed a Wear APK rather than using the Multi-APK delivery method (for Wear 1.x watches).

Traditionally, Wear 1.0 APKs were embedded in phone APKs for distributing wearable apps to users. Wear OS now allows you to upload Wear 1.0 APKs directly to the Play Store, rather than embedding them. This helps decrease the size of a phone APK and enables greater flexibility in versioning and releasing APKs. If you have an existing, embedded Wear 1.0 APK, you can follow the steps below to configure, build, and upload the APK to the Play Store:

Add a wearAppUnbundled true setting to your phone module's build.gradle file. This is needed only if you previously published an embedded Wear app in the Play Store.

android {
  ...
  defaultConfig {
    ...
    wearAppUnbundled true
  }
}

Remove the following wearApp dependency rule from your phone app's build.gradle file:

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

Ensure that the following feature restriction is specified in your Wear app's manifest file:

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

Set the minimum SDK version to 23 in the build.gradle file of your Wear module.
If desired, specify your Wear app as standalone, after reviewing the Standalone Apps page.
Build your Wear APK and use the Google Play Developer Console to deploy it.

For your Wear app's minimum SDK version, consider the following:

If you have different APKs for Wear 1.0 and Wear 2.0, be sure to set the higher minimum SDK version of 25 in the Wear 2.0 module's build.gradle file. This ensures that the Play Store distributes the Wear 2.0 APK to Wear 2.0 devices only, and not to Wear 1.0 devices.
If you already have a Wear 2.0 app and want to distribute it to Wear 1.0 devices, you must ensure that it works well on Wear 1.0 devices before setting its minimum SDK version to 23.

Set up targeting for a watch

In your Android manifest file, you must set the uses-feature element to android.hardware.type.watch. Additionally, 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.

Specify an app as standalone

Wear 2.0 requires a meta-data element in the Android manifest file of watch apps, as a child of the <application> element. The name of the meta-data element is com.google.android.wearable.standalone and the value must be true or false. The element indicates whether your watch app is a standalone app. If the setting for the element is true, your app can be made available in the Play Store on watches paired to iPhones, as long as your active APKs in all channels (e.g., in the beta channel) have the element set to true. If not all of your APKs (alpha, beta, and production) that currently are served to users have the above setting, your app will be unavailable when a user searches on a watch paired to an iPhone.

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

Completely independent of a phone app
Semi-independent (a phone app is not required and would provide only optional features)
Dependent on a phone app

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.

If your Wear 2.0 app has an accompanying phone app, use the same package name for your Wear app and that phone app.

Use the Play Console

You can use the Play Console to upload a standalone Wear APK to an app listing.

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

Upload and publish your APK

To upload and publish your APK using Play Console:

Go to your Play Developer Console.
From the left menu, select Release management > App releases.
Note: If your APK is in draft mode, select App releases directly from the left menu.
Next to the release type (production, alpha, or beta) you want to create, select Manage
To create a new release, select Create release.
Select Add APK from library to add your standalone Wear APK. Alternatively, drag and drop your APK file or select Browse Files.
When you've finished preparing your release, select Review. The "Review and rollout release" screen is displayed. Here, you can use the info icon to review details of your APK, such as the number of supported Android devices. Also make sure that you have set the hardware feature to android.hardware.type.Watch.
Select Confirm rollout to publish your app.

Embed a Wear 1.x APK

The processes in this section are kept for reference purposes. If a Wear 1.x APK is packaged in a phone app APK, the system pushes the Wear app to the paired watch when users download the phone app.

Note: This feature doesn't work when you are signing your apps with a debug key. While developing, installing apps with adb install or Android Studio directly to the watch is required.

Package a Wear 1.x app with Android Studio

Note: Due to a latency issue affecting an app's availability on Wear 1.x watches, you can embed a Wear APK rather than using the Multi-APK delivery method (for Wear 1.x watches).

To package a Wear 1.x app in Android Studio:

Ensure that both the watch and phone app modules have the same package name.
Declare a Gradle dependency in the phone app's build.gradle file that points to the watch app module. The declaration would be similar to the following, but see Set Up Google Play Services and v4 compat library for the latest versions:
```
dependencies {
   compile 'com.google.android.gms:play-services-wearable:10.0.1'
   compile 'com.android.support:support-compat:25.1.0'
   wearApp project(':wearable')
}
```
Follow the instructions in Sign your release build for specifying your release keystore and signing your app. Android Studio exports (into your project's root folder) a signed phone app that includes an embedded watch app.
Alternatively, sign both apps from the command line using the Gradle wrapper. Both apps must be signed to enable an automatic push of the watch app. See Sign Your App.

Sign the Wear 1.x app and phone app separately

If your build process requires signing the watch app separately from the phone app, you can declare the following Gradle rule in the phone module's build.gradle file to embed the previously-signed watch app:

dependencies {
  ...
  wearApp files('/path/to/wearable_app.apk')
}

You then sign your phone app as desired (with the Android Studio Build > Generate Signed APK... menu item or with Gradle signingConfig rules).

Package a Wear 1.x app manually

You can package a watch app in a phone app manually if you are using another IDE or another method of building:

Ensure that both the watch and mobile APKs have the same package name and version number.
Copy the signed watch app to your phone project's res/raw directory. We'll refer to the APK as wearable_app.apk.
Create a res/xml/wearable_app_desc.xml file that contains the version and path information of the watch app. For example:
```
<wearableApp package="wearable.app.package.name">
  <versionCode>1</versionCode>
  <versionName>1.0</versionName>
  <rawPathResId>wearable_app</rawPathResId>

</wearableApp>
```
The values for the package, versionCode, and versionName are the same as those in the watch app's manifest file. The rawPathResId is the static variable name of the APK resource. For example, for wearable_app.apk, the static variable name is wearable_app.
Add a meta-data tag to your phone app's <application> tag to reference the wearable_app_desc.xml file.
```
  <meta-data android:name="com.google.android.wearable.beta.app"
                 android:resource="@xml/wearable_app_desc"/>
```
Note: The above meta-data tag should not be changed. com.google.android.wearable.beta.app is required.
Build and sign the phone app.

Turn off asset compression

Android Studio doesn't compress your APK by default, but if you use another build process, ensure that the watch app is not doubly compressed. Many build tools automatically compress files added to the res/raw directory of an Android app. The watch APK is already zipped, so double compression occurs. As a result, the watch app installer cannot read the watch app, installation fails, and the PackageUpdateService logs the following error: "This file cannot be opened as a file descriptor; it is probably compressed."

Adding voice capabilities

Debugging a Wear app