Packaging and Distributing Wear Apps

This lesson teaches you about

Planning for the Play Store
Setting Up Targeting for a Watch
Specifying an App as Standalone
Using the Play Console
Publishing a Wear 1.x APK

With Wear 2.0, 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).

Planning 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

The standard distribution model for Wear 1.x was embedding a watch app inside a phone app. 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 only when the APK on the phone is updated.

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 must embed the watch APK inside the phone APK, as described below.

Distribution to Wear 1.x and 2.0 watches

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

Provide a Wear 2.0 (standalone) version of your watch APK that can be made available in the Play Store on Wear.
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 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 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 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.

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

Using the Play Console

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

If your app supports both Wear 1.x and Wear 2.0, continue embedding the Wear 1.x APK (setting the minimum SDK version to 20, 21, 22, or 23) in the corresponding phone APK, and continue uploading that 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

In 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:

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

Advanced mode is unnecessary if you only have a Wear 2.0 app and no phone app. Instead of using advanced mode, you can use simple mode.
Use advanced mode if you support Wear 1.x or if you have a phone app.

Warning: If you have an existing phone app (in addition to your Wear 2.0 app), you must use advanced mode, which enables you to configure multiple, active APKs.

On the above APK screen, determine whether to click the Switch to advanced mode button by considering the following:

If your app does not support Wear 1.x, and only has a watch APK, you can upload it using simple mode.
If your app does not support Wear 1.x and has both a watch APK and a phone APK, click Switch to advanced mode to upload the watch and phone APKs.

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

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

Reviewing and publishing

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

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:

When you are ready, publish your app.

Publishing a Wear 1.x APK

The processes in this section are used for distributing Wear 1.x apps. As stated above, a Wear 1.x app must be packaged in a phone app. When users download the phone app, the system pushes the Wear app to the paired watch.

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.

Packaging a Wear 1.x app with Android Studio

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.

Signing 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"/>

Build and sign the phone app.

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

Most visited

Recently visited

Results for