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
- Specifying a bridging configuration at runtime
- Setting a dismissal ID so notification dismissals are synced across devices
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
entry in the manifest file of the watch app (e.g. the standalone watch
app), as follows:
as a child of the
Setting that entry to
NO_BRIDGING will prevent bridging:
<application> ... <meta-data android:name="com.google.android.wearable.notificationBridgeMode" android:value="NO_BRIDGING" /> ... </application>
The default bridging behavior occurs if you do not
<meta-data> entry or
if you specify a value of
BRIDGING instead of
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
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:
BridgingManager.fromContext(context).setConfig( new BridgingConfig.Builder(context, false) .build());
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
BridgingManager.fromContext(context).setConfig( new BridgingConfig.Builder(context, false) .addExcludedTags(Arrays.asList("foo", "bar", "baz")) .build());
As another example, you can exclude notifications with
specific tags (such as
BridgingManager.fromContext(context).setConfig( new BridgingConfig.Builder(context, false) .addExcludedTag("foo") .addExcludedTag("bar") .build());
Setting a bridge tag
A bridge tag can be set on a notification by using the
method as follows:
NotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(context) // ... set other fields ... .extend( new NotificationCompat.WearableExtender() .setBridgeTag("foo")); Notification notification = notificationBuilder.build();
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
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
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
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 ... .extend(wearableExtender) .build();
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:
- If you cancel a notification on the phone, it may take some time for the corresponding notification on the watch to be canceled. During this time, a user could send one of the pending intents on that notification. For this reason, your app should be prepared to receive pending intents from notifications it has canceled. Thus, when canceling notifications, you should make sure to keep those notifications’ pending intent receivers valid.
- Do not cancel and retrigger an entire stack of notifications at one time. Only modify or remove the notifications that have actually been modified. This avoids the latency on updating the wearable device and ensures that the impact of your app on battery life is minimal.
Wear OS notifications have their own design guidelines. For more information, review the Material Design page.
- All notifications bridged from the paired phone to the Wear device use expanded notifications.
- To learn when to use the different notification templates supported on Wear OS, read the Notifications patterns design guide.
- To learn how to style your Wear notifications, read the Notifications style design guide.
- If you have a chat messaging app, your notifications should use
NotificationCompat.MessagingStyle. Wear uses the chat messages included in a
MessagingStylenotification (see addMessage()) to provide a rich chat app-like experience in the expanded notification.
- Add an inline action ( setHintDisplayActionInline(true)) within the notification stream to include a primary action that a user can quickly take on a notification. Examples of good use cases for an inline action within a notification stream include replying to a text message, stopping a fitnes activity, or archiving an email message.
- Enable Smart Reply ( setAllowGeneratedReplies(true)) for your MessagingStyle notifications.