We recommend that Wear OS apps work independently of a phone so users can complete tasks on a watch without access to an Android or iOS phone. If your watch app requires phone interaction, you must mark your Wear OS app as non-standalone and take steps to ensure that the user has the phone app available.
Plan your app
You can use Android App Bundle to automatically generate optimized Android Package Kits (APKs) for each user’s device configuration under the same application listing. This lets users download only the code and resources they need to run your app.
Generally, the minimum API level for a Wear OS app is API level 25 (Wear OS 2.0).
The target API level must be API level 28 or higher. For more information, see
Meet Google Play's target API
level requirement. Set the
targetSdkVersion to API level 30 (Wear OS 3) to help ensure that your app works well
on the latest platform version.
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 your app's Android manifest file.
To indicate that it is a watch app, add an entry like the following:
<manifest> ... <uses-feature android:name="android.hardware.type.watch" /> ... </manifest>
Identify an app as standalone or non-standalone
A watch app is considered either standalone or non-standalone:
- Standalone: a completely independent app that does not require a phone app for core features, including authentication. If available, a phone app provides only optional features.
- Non-standalone: a dependent app that requires an app on a phone or another device for core features, including authentication.
In your Wear OS app, set the value of
in the Android manifest file to declare whether your app is standalone or non-standalone.
If your watch app is a completely independent, standalone app, indicate
this to the Google Play store by setting the
<application> ... <meta-data android:name="com.google.android.wearable.standalone" android:value="true" /> ... </application>
If your watch app is non-standalone and depends on another app for core features,
set the value of
false. This signifies that the watch app requires another device, but doesn't
affect your app promotion on the Google Play Store.
Even if the value of
false, the watch
app can be installed before the phone app is installed.
Therefore, if your watch app
detects that a companion phone
lacks the necessary phone app, as described on this page,
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. For example, common code for networking can be in a shared library.
Optionally, code that is specific to a form factor can be in a separate module.
Detect your app on another device
Your watch app and corresponding phone app can each detect whether the other app is available.
Your phone and watch apps can use the
CapabilityClient to advertise their presence
to a paired device. They can do so statically or 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 lets other
apps detect it. For more information, see
If one of your apps can't detect the other, you can prompt the user to open the Play Store listing on the affected device. This is a solution for watch apps that require their companion phone app's presence to function properly.
You must check whether the Play Store is available on the device, because not all phones—such as iPhones—support the Play Store.
The following sections describe best practices for two scenarios:
- Your standalone watch app needs your phone app.
- Your phone app needs your standalone watch app.
You can also review the
sample app on GitHub that demonstrates this functionality. For more information
about the classes described in the following section, see the
Wear OS API reference.
That reference also includes information about the
PhoneDeviceType class, which contains a
getPhoneDeviceType() method that lets your
Wear OS app check whether a companion phone is an Android or iOS device.
Specify capability names for detecting your apps
For the app corresponding to each device type, either watch or phone, specify a
unique string for the capability name in the
For example, in your mobile module, the
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 includes 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 whether a user's companion phone has your phone app. Follow these steps:
CapabilityClientto check whether your phone app is installed on the paired phone. For more information, see the sample app on GitHub.
If your phone app isn't installed on the phone, use the
PhoneDeviceType.getPhoneDeviceType()method to check the type of the phone. See the following section for details.
PhoneDeviceType.DEVICE_TYPE_ANDROIDis returned, the phone is an Android phone. Call
RemoteActivityHelper.startRemoteActivity()on the Wear OS device to open the Play Store on the phone. Use the market URI for your phone app, which might be different from your Wear app's URI. For example, use a market URI such as:
PhoneDeviceType.DEVICE_TYPE_IOSis returned, 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 OS device. You can specify your app's iTunes URL, such as
From Wear OS, you cannot programmatically determine whether your phone app is installed on an iOS device. As a best practice, provide a mechanism to the user to manually trigger the opening of the App Store.
Note: Use the
RemoteActivityHelper API previously described to
specify that any URL be opened on the phone from the watch,
and that 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:
var phoneDeviceType: Int = PhoneDeviceType.getPhoneDeviceType(context)
int phoneDeviceType = PhoneDeviceType.getPhoneDeviceType(context);
The value returned by the
method is one of the following:
||The companion phone is an Android device.|
||The companion phone is an iOS device.|
||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 whether a user's Wear OS devices have your watch app. Follow these steps:
NodeClient, find all watches connected to the user's phone. For more information, see the sample app on GitHub.
CapabilityClient, check which of the user's watches has your app installed.
If your app isn't installed on all of the user's watches, let the user
open the Play Store on the remaining Wear OS devices from the phone using
RemoteActivityHelper.startRemoteActivity()method. Use the market URI for the Wear OS app, which might be different from your phone app's URI. For example, use a market URI such as:
Location data for watches paired to iPhones
If the companion phone is available, FLP uses the companion phone for location data.
Obtain only necessary data
Generally, when obtaining data from the internet, 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 might 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 is only needed 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.