Independent versus dependent Wear OS apps

The default recommendation is for a Wear OS app to work independently of a phone so users can complete tasks on a watch, without access to an Android or iOS phone.

It is possible to mark your Wear OS app as dependent on an Android phone with a partner Android app, but it isn't recommended. Not only does it mean your app won't work when paired with an iOS device but your app won't qualify for promotion on the Google Play Store.

Plan your app

You can use Android App Bundle to automatically generate optimized APKs for each user’s device configuration under the same application listing. This allows users to download only the code and resources they need to run your app.

For information about setting up your app for distribution through the Google Play Store, see Package and distribute Wear OS Apps and the Android App Bundle getting started guide.

Note: To qualify for promotion in the Google Play Store on Wear OS (that is, in the on-watch Play Store), your app needs to function independently from a phone. Both iOS and Android support are required.

Generally, the minimum and target API level for a standalone app and for Wear OS 2.0 is API level 25.

For information about network requests and high-bandwidth network access, see Network access and sync on Wear OS.

Define an app as a Wear OS app

You must define the <uses-feature> tag in the Android Manifest file in your app. For example, indicate that it is a watch app, as shown in the following example:

  <manifest>
  ...
  <uses-feature android:name="android.hardware.type.watch" />
  ...
  </manifest>
  

Identify an app as standalone

Wear OS apps must set the meta-data element com.google.android.wearable.standalone to true or false in the Android manifest file.

The element indicates whether your watch app is a standalone (independent/semi-independent) app that doesn't require a phone-side Android app to operate. 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 (such as the beta channel) have the element set to true.

If the setting isn't applied to all of your APKs (alpha, beta, and production) that currently are served to users, your app will be unavailable when a user searches on a watch paired to an iPhone.

A watch app can be considered 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, it is in the standalone category. You must indicate this categorization to the Google Play store by setting the value of this 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 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. Therefore, if a watch app detects that a companion phone lacks a necessary phone app, the watch app should prompt the user to install the phone app.

Shared code and data storage

Code can be shared between a Wear OS app and a phone app. Optionally, code that is specific to a form factor can be in a separate module.

For example, common code for networking can be in a shared library.

You can use standard Android storage APIs to store data locally, as you would on a phone. For example, you can use the SharedPreferences APIs or the Room persistence library.

Detect your app on another device

Your watch app can detect if the corresponding phone app is available and vice versa.

Your phone app or watch app can use the CapabilityClient to advertise the app's presence to a paired device. It can do so statically and dynamically. When an app is on a node in a user's Wear OS network (such as on a phone, paired watch, or in the cloud), the CapabilityClient enables another app to detect if it is installed. For more information, see Advertise capabilities.

If one of your apps cannot detect the other, you can enable a user to open the Play Store listing on their remote device. This is a solution for watch apps that require their companion phone app's presence to function properly. A prerequisite is to check for the Play Store's presence on the remote device.

Note that not all phones support the Play Store (such as iPhones, etc.).

This section describes best practices for these scenarios:

  • Your standalone watch app needs your phone app
  • Your phone app needs your standalone watch app

Review the sample on GitHub that shows this functionality. For more information about the classes described below, see the Wear OS API reference. Also in that reference is information about the PhoneDeviceType class, which contains a getPhoneDeviceType() method that enables your Wear OS app to check if a companion phone is an Android or iOS device.

Specify capability names for detecting your apps

For the app corresponding to each device type (watch or phone), specify a unique string for the capability name in the res/values/wear.xml file.

For example, in your mobile module, the wear.xml file could include the following:

<resources xmlns:tools="http://schemas.android.com/tools"
        tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_phone_app</item>
    </string-array>
</resources>

In your Wear OS module, the wear.xml file would include a different value for the capability name, such as the following:

<resources xmlns:tools="http://schemas.android.com/tools"
        tools:keep="@array/android_wear_capabilities">
    <string-array name="android_wear_capabilities">
        <item>verify_remote_example_wear_app</item>
    </string-array>
</resources>

For more information, see Advertise capabilities.

App detection and opening a URL from a watch

Your watch app can detect if a user's companion phone has your phone app:

  1. Use the CapabilityClient to check if your phone app is installed on the paired phone. For more information, see the sample on GitHub.
  2. If your phone app isn't installed on the phone, use the PhoneDeviceType.getPhoneDeviceType() method to check the type of the phone.
  3. If PhoneDeviceType.DEVICE_TYPE_ANDROID is returned, the phone is an Android phone. Call RemoteActivityHelper.startRemoteActivity() on the Wear OS device to open the app store on the phone. Use the market URI for your phone app (which may be different from your phone URI). For example, use a market URI such as: market://details?id=com.example.android.wearable.wear.finddevices
  4. If PhoneDeviceType.DEVICE_TYPE_IOS is returned, it means the phone is an iOS phone (with no Play Store available). Open the App Store on the iPhone by calling RemoteActivityHelper.startRemoteActivity() on the Wear device. You can specify your app's iTunes URL, for example, https://itunes.apple.com/us/app/yourappname. On an iPhone, from Wear OS, you cannot programmatically determine if your phone app is installed. As a best practice, provide a mechanism to the user (e.g., a button) to manually trigger the opening of the App Store.

Note that using the RemoteActivityHelper API described above, you can specify that any URL be opened on the phone from the watch, and no phone app is required.

Details for detecting the type of paired phone

Here is a snippet that uses the getPhoneDeviceType() method to check the type of phone to which the watch is paired:

Kotlin

var phoneDeviceType: Int = PhoneDeviceType.getPhoneDeviceType(context)

Java

int phoneDeviceType = PhoneDeviceType.getPhoneDeviceType(context);

The value returned by the getPhoneDeviceType() method is one of the following:

Return value Description
DEVICE_TYPE_ANDROID The companion phone is an Android device.
DEVICE_TYPE_IOS The companion phone is an iOS device.
DEVICE_TYPE_ERROR_UNKNOWN An error occurred in determining the type of the paired phone; another check should be made later.

App detection starting from an Android phone

Your Android phone can detect if a user's Wear OS devices have your watch app:

  1. Using the NodeClient, find all watches connected to the user's phone. For more information, see the sample on GitHub.
  2. Using the CapabilityClient, check which of the user's watches have your app installed.
  3. If your app isn't installed on all of the user's watches (compare the results from Step 1 with the results from Step 2), allow the user to open the Play Store on the remaining Wear OS devices from the phone via the RemoteActivityHelper.startRemoteActivity() method. Specifically, use the market URI for the Wear OS app (which may be different from your phone app's URI). For example, use a market URI such as: market://details?id=com.example.android.wearable.wear.finddevices

Location data for watches paired to iPhones

For watches paired with iPhones, developers should use the Fused Location Provider (FLP) to get location data on a watch. See Detect location on Wear OS.

If the companion phone is available, FLP uses the companion phone for location data.

Obtain only the necessary data

Generally, when obtaining data from the internet, you should get only the necessary data. Otherwise, you may introduce unnecessary latency, memory use, and battery use.

When a watch is connected over a Bluetooth LE connection, your app may have access to a bandwidth of only 4 kilobytes per second, depending on the watch. Therefore, the following steps are recommended:

  • Audit your network requests and responses for extra data that only is for a phone app
  • Shrink large images before you send them over a network to a watch

For cases where a high-bandwidth network is needed, see High-bandwidth network access.

Additional code samples

The WearVerifyRemoteApp sample further demonstrates the use of the APIs covered on this page.