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.

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.

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.

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:

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.

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.

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:

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:

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.

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:

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:

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.

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