By default, notifications are bridged (shared) from an app on a companion phone to the watch. If you build a standalone watch app and have a companion phone app, they may duplicate notifications. The Android Wear 2.0 Preview includes features to handle this problem of repeated notifications.
With the Android Wear 2.0 Preview, developers can change the behavior of notifications with one or more of the following:
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:
com.google.android.wearable.notificationBridgeMode
Setting that entry to NO_BRIDGING will prevent bridging:
<meta-data android:name="com.google.android.wearable.notificationBridgeMode"
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.
For an existing app, if you are using Google Cloud Messaging (GCM) or Firebase Cloud Messaging (FCM) to send notification alerts to devices, you may already have disabled bridging in case a phone is not connected at the time of receiving an alert. In this case, you may still want to dismiss the notification across other devices when it is dismissed in a watch app.
The bridging configuration that is set in the manifest takes effect as soon as a watch app is installed.
This section describes how to specify a bridging configuration at runtime
using the BridgingManager class
(android.support.wearable.notifications.BridgingManager).
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,
optionally using the setBridgingEnabled method. If you
specify a bridging configuration at runtime, then if the
setBridgingEnabled method is not set, bridging is enabled by
default.
Specifying a bridging configuration at runtime overrides a bridging-related setting in the Android manifest file.
You can use the setBridgingEnabled method, as follows:
BridgingManager.setConfig(context,
new BridgingConfig.Builder(context)
.setBridgingEnabled(false)
.build());
If the above setter is not called, the bridging mode defaults to true.
Here is an example of setting tags without using the
setBridgingEnabled method, excluding notifications with a
tag of foo or bar:
BridgingManager.setConfig(context,
new BridgingConfig.Builder(context)
.addExcludedTag("foo")
.addExcludedTag("bar")
.build());
You can disable bridging for all notifications except those with certain tags.
For example, you can disable bridging, except for notifications tagged as
foo or bar, with the following:
BridgingManager.setConfig(context,
new BridgingConfig.Builder(context)
.setBridgingEnabled(false)
.addExcludedTag("foo")
.addExcludedTag("bar")
.build());
As another example, you can disable bridging for all notifications except
for notifications tagged as foo, bar or
baz.
BridgingManager.setConfig(context,
new BridgingConfig.Builder(context)
.setBridgingEnabled(false)
.addExcludedTags(Arrays.asList("foo", "bar", "baz"))
.build());
You can enable bridging for all notifications except those with certain tags.
For example, you can enable bridging for all notifications, except for
notifications tagged as foo or bar, with the
following:
BridgingManager.setConfig(context,
new BridgingConfig.Builder(context)
.setBridgingEnabled(true)
.addExcludedTag("foo")
.addExcludedTag("bar")
.build());
A bridge tag can be set on a notification by calling the
setNotificationBridgeTag method as follows:
BridgingManager.setNotificationBridgeTag(<NotificationCompat.Builder>, <String>);
For example:
NotificationCompat.Builder builder = new NotificationCompat.Builder(context) <set other fields>; BridgingManager.setNotificationBridgeTag(builder, "foo"); Notification notification = builder.build();
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.
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>
.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.