A Wear OS app can work independently of a phone. Users can complete tasks on a watch, without access to an Android or iOS phone.
Refer to the following related resources:
Plan your apps
You can use the multiple APK (multi-APK) feature of Google Play to publish more than one APK under the same application listing. A watch APK should be distributed using that feature; do not embed a watch APK in a phone APK. For information about setting up your app for distribution through the Google Play Store, see Packaging and Distributing Wear Apps and How Multiple APKs Work.
Note: To qualify for promotion in the Google Play Store on Wear (that is, in the on-watch Play Store), your app needs to function independently from a phone. iOS as well as Android support is required.
Generally, the minimum and target API level for a standalone app, and for Wear 2.0, is level 25. The minimum SDK level can be 23 only if you are using the same APK for Wear 1.0 and 2.0 (and thus have an embedded Wear 1.0 APK).
Note: Due to a latency issue affecting an app's availability on Wear 1.x watches, if you build a standalone Wear 2.0 APK and will continue to have a Wear 1.0 APK, do both of the following:
- Provide a standalone version of the Wear APK, and
- Continue embedding a version of the Wear APK in your phone APK
Caution: If you publish an update to your existing, production phone APK that has removed an embedded Wear APK, production users who update the phone APK before installing your standalone Wear APK will lose their existing Wear app and its data. If you publish an update to your existing, production phone APK, continue to embed your watch APK into that phone APK.
Run-time permissions are required for standalone apps.
For information about network requests and high-bandwidth network access, see Network Access and Syncing.
Identify an app as standalone
Wear apps must have a
meta-data element in the Android Manifest file,
as a child of the
The name of the
com.google.android.wearable.standalone and the
value must be
false. The element
indicates whether your watch app is a standalone app and thus doesn't
require a phone-side Android app to operate. If the setting for the element
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
have the element set to
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 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 considered to be in the standalone category. You must indicate this
categorization to the Google Play store by setting the
value of this
meta-data element to
<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
false signifies that the watch app should be installed
only on a watch that is paired with a phone that has the Play Store.
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.
Define an app as a Wear app
You must ensure the
<uses-feature> tag is defined in the Android Manifest file in your
app. It must indicate that it is a
watch app, for example,
android:name="android.hardware.type.watch" as follows:
<manifest> ... <uses-feature android:name="android.hardware.type.watch" /> ... </manifest>
Shared code and data storage
Code can be shared between a Wear 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.
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 network (i.e., on a phone, paired watch, or
in the cloud), the
CapabilityClient enables another
app to detect if it is installed. For more information, see
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
that shows this functionality. For more information
about the classes described below, see the
Wear API Reference.
Also in that reference is information about the
PhoneDeviceType class, which contains a
getPhoneDeviceType() method that enables your
Wear 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
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 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:
CapabilityClientto check if your phone app is installed on the paired phone. For more information, see the sample.
If your phone app isn't installed on the phone, use the
PhoneDeviceType.getPhoneDeviceType()method to check the type of the phone.
PhoneDeviceType.DEVICE_TYPE_ANDROIDis returned, the phone is an Android phone. Call
RemoteIntent.startRemoteActivity()on the Wear 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:
PhoneDeviceType.DEVICE_TYPE_IOSis returned, it means the phone is an iOS phone (with no Play Store available). Open the App Store on the iPhone by calling
RemoteIntent.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
RemoteIntent 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
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 if a user's Wear devices have your watch app:
NodeClient, find all watches connected to the user's phone. For more information, see the sample.
CapabilityClient, check which of the user's watches have your app installed.
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 devices from the phone via
RemoteIntent.startRemoteActivity()method. Specifically, use the market URI for the Wear app (which may 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 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.