Skip to content

Most visited

Recently visited


Bridging Mode for Notifications on Wear

By default, notifications are bridged (shared) from an app on a companion phone to the paired watch. If you build a standalone watch app and you have a companion phone app, the apps may duplicate notifications. Wear OS by Google includes features to handle this problem of duplicate notifications.

Refer to the following related resources:

Note: You can use Firebase Cloud Messaging (FCM) to send notification alerts to devices. See Engage your users across Android, iOS and Chrome.

Developers can change the behavior of notifications with one or more of the following:

Specifying a Bridging Configuration in the Manifest File

An app's Android manifest file can indicate that notifications from the corresponding phone app should not be bridged to the watch. Specifically, to prevent bridging of notifications from a phone app, you can use a <meta-data> entry in the manifest file of the watch app (e.g. the standalone watch app), as follows:

Add that <meta-data> entry as a child of the <application> element. Setting that entry to NO_BRIDGING will prevent bridging:

    android:value="NO_BRIDGING" />

The default bridging behavior occurs if you do not include the <meta-data> entry or if you specify a value of BRIDGING instead of NO_BRIDGING.

The bridging configuration that is set in the manifest takes effect as soon as a watch app is installed.

Specifying a Bridging Configuration at Runtime

You can use the Bridging mode feature to specify a bridging configuration at runtime. Specifically, you use the BridgingManager class.

You can set a bridging mode, and optionally set tags for notifications that are exempt from the bridging mode, using a BridgingManager object. Specifically, create a BridgingConfig object and set it as shown in this section.

Specifying a bridging configuration at runtime overrides a bridging-related setting in the Android manifest file.

Disable bridging for all notifications

You can disable bridging for all notifications, as follows:

  new BridgingConfig.Builder(context, false)

If the above configuration is not set, the bridging mode defaults to true.

Exempt notifications that are tagged

You can disable bridging for all notifications except those with certain tags.

For example, you can disable bridging for all notifications except those tagged as foo, bar, or baz.

  new BridgingConfig.Builder(context, false)
    .addExcludedTags(Arrays.asList("foo", "bar", "baz"))

As another example, you can exclude notifications with specific tags (such as foo or bar):

  new BridgingConfig.Builder(context, false)

Setting a bridge tag

A bridge tag can be set on a notification by using the setBridgeTag(String) method as follows:

NotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(context)
// ... set other fields ...
    new NotificationCompat.WearableExtender()
  Notification notification =;

Existing Method of Preventing Bridging

In an existing app, you may already have disabled bridging for when a phone is not connected when an alert is received. In this case, you may still want to dismiss the notification across other devices when it is dismissed in a watch app.

An existing way to prevent bridging is with the Notification.Builder class; specify true in the setLocalOnly method.

However, this way to prevent bridging may not be preferable. For example, if a user installs a phone app but not the corresponding watch app, the setLocalOnly method could prevent the bridging of helpful notifications. Additionally, users may have multiple paired watches and the watch app may not be installed on all of them.

Using a Dismissal ID to Sync Notification Dismissals

If you prevent bridging with the Bridging mode feature, dismissals (cancellations) of notifications are not synced across a user's devices. However, the following methods of the NotificationCompat.WearableExtender class enable you to use dismissal IDs:

public WearableExtender setDismissalId(String dismissalId)
public String getDismissalId()

To enable a dismissal to be synced, use the setDismissalId() method. For each notification, pass a globally unique ID, as a string, when you call the setDismissalId() method. When the notification is dismissed, all other notifications with the same dismissal ID are dismissed on the watch(es) and on the companion phone. To retrieve a dismissal ID, use getDismissalId().

In the following example, syncing of dismissals is enabled because a globally unique ID is specified for a new notification:

NotificationCompat.WearableExtender wearableExtender =
  new NotificationCompat.WearableExtender().setDismissalId("abc123");
Notification notification = new NotificationCompat.Builder(context)
// ... set other fields ...

Dismissal IDs work if a watch is paired to an Android phone, but not if a watch is paired to an iPhone.

Best Practices for Bridged Notifications

Bridged notifications take time to be pushed or removed from a wearable device. As you design your notifications, make sure to avoid unexpected behavior caused by this latency. The guidelines below will help you to ensure that your bridged notifications work with asynchronous notifications:

Design Considerations

Wear OS notifications have their own design guidelines. For more information, review the Material Design page.

This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields


Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)