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'sbuild.gradle
file. This is needed only if you previously published an embedded Wear app in the Play Store. - Remove the following
wearApp
dependency rule from your phone app'sbuild.gradle
file: - Ensure that the following feature restriction is specified in your Wear app's manifest file:
- 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.
android { ... defaultConfig { ... wearAppUnbundled true } }
dependencies { ... wearApp project(path: ':wear', configuration: 'wear1Release') }
<manifest package="com.example.standalone" xmlns:android="http://schemas.android.com/apk/res/android"> <uses-feature android:name="android.hardware.type.watch"/> ... </manifest>
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 aswearable_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
, andversionName
are the same as those in the watch app's manifest file. TherawPathResId
is the static variable name of the APK resource. For example, forwearable_app.apk
, the static variable name iswearable_app
. - Add a
meta-data
tag to your phone app's<application>
tag to reference thewearable_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."