通知的橋接選項
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
根據預設,系統會把手機應用程式的通知橋接或分享到配對手錶。如果您建構的手錶應用程式也同時存在於配對手機上,使用者可能會收到重複的應用程式通知:其中一則通知由手機應用程式產生並橋接,另外一則由手錶應用程式產生。Wear OS 提供用於控制通知橋接方式和時間的功能。
避免重複通知
如果您使用 Firebase 雲端通訊等外部來源建立通知,行動應用程式和穿戴式應用程式就可以各自在手錶上顯示自己的通知。為避免發生這類重複通知,請在穿戴式應用程式中透過程式輔助方式停用橋接功能。
如果想在已安裝穿戴式應用程式的情況下把一部分行動應用程式所建立的通知橋接到手錶上,請設定橋接標記。
使用 setBridgeTag(String)
方法即可為通知設定橋接標記,如以下程式碼範例所示:
val notification = NotificationCompat.Builder(context, channelId)
// ... set other fields ...
.extend(
NotificationCompat.WearableExtender()
.setBridgeTag("tagOne")
)
.build()
停用橋接功能
您可以停用部分通知或所有通知的橋接功能。建議您選擇性停用橋接功能。
停用「部分」通知的橋接功能
您可使用動態方式停用橋接功能,並視需要依據通知的標記允許顯示部分通知。舉例來說,如要停用除了標記 tagOne
、tagTwo
或 tagThree
之外所有通知的橋接功能,請使用 BridgingConfig
物件,如下列範例中所示:
BridgingManager.fromContext(context).setConfig(
BridgingConfig.Builder(context, false)
.addExcludedTags(listOf("tagOne", "tagTwo", "tagThree"))
.build()
)
停用「所有」通知的橋接功能 (不建議)
注意:不建議您停用所有通知的橋接功能,因為安裝手錶應用程式後,在資訊清單中設定的橋接設定就會立即生效。如果使用者需要先開啟及設定手錶應用程式才能收到通知,則這項設定可能會導致通知遺失。
為避免對來自特定手機應用程式的所有通知執行橋接功能,請在手錶應用程式的資訊清單檔案中使用 <meta-data>
項目,如以下範例所示:
<application>
...
<!-- Beware, this can have unintended consqequences before the user is signed-in -->
<meta-data
android:name="com.google.android.wearable.notificationBridgeMode"
android:value="NO_BRIDGING" />
...
</application>
注意:如果在執行階段指定橋接設定,則會覆寫 Android 資訊清單檔案中的橋接相關設定。
設定關閉 ID 以同步處理類似的通知
如果您用橋接模式功能停用橋接功能,系統就不會同步處理使用者裝置上的關閉通知行為。
但是,如果行動裝置和手錶都會建立類似的通知,建議您在使用者關閉任一裝置上的通知後,讓系統同時關閉兩邊的通知。
您可以在 NotificationCompat.WearableExtender
內設定全域專屬 ID,這樣一來,只要關閉一則通知,也會一併關閉配對手錶上具有相同 ID 的其他通知。
NotificationCompat.WearableExtender
類別內備有可讓您使用關閉 ID 的方法,請看以下範例:
fun setDismissalId(dismissalId: String): WearableExtender
fun getDismissalId(): String
如果想同步處理關閉行為,請用 setDismissalId()
方法。在每個通知呼叫 setDismissalId()
方法時,用字串形式傳遞全域專屬 ID。
使用者關閉通知時,系統會關閉手錶和手機上使用相同關閉 ID 的通知。如果想擷取關閉 ID,請用 getDismissalId()
以下範例為每個新通知指定全域專屬 ID,這樣既可同步處理關閉行為︰
val notification = NotificationCompat.Builder(context, channelId)
// Set other fields ...
.extend(
NotificationCompat.WearableExtender()
.setDismissalId("abc123")
)
.build()
注意:當手錶和 Android 手機配對時才能使用關閉 ID 達到此效果,如果手錶和 iPhone 配對則無法使用。
不橋接通知的情況
無法橋接下列類型的通知:
橋接通知的最佳做法
從穿戴式裝置推送或移除橋接通知都需要時間。在設計通知時,請務必避免由於這個延遲時間而發生預料之外的行為。以下指南可協助確保在非同步通知的情況下順利使用橋接通知:
-
在手機上取消通知時,系統可能需要一點時間才能取消手錶上對應的通知。在這段期間,使用者可能會透過該通知傳送其中一個待處理的意圖。因此,應用程式可從自己已取消的通知接收待處理意圖:在取消通知時,請保持通知的待處理意圖接收器有效。
-
請勿一次取消並重新觸發整個堆疊的通知。只修改或移除內容實際有所變動的通知。這樣做可以避免因更新穿戴式裝置而造成延遲,並降低應用程式對電池續航力的影響。
設計須知
Wear OS 通知有專屬的設計規範。詳情請參閱「Wear OS 設計規範」。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-26 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-26 (世界標準時間)。"],[],[],null,["# Bridging options for notifications\n\nBy default, notifications are bridged, or shared, from an app on a phone to any paired watches. If\nyou build a watch app and your app also exists on a paired phone, users might receive duplicate\nnotifications---one generated and bridged by the phone app and one generated\nby the watch app. Wear OS includes features to control how and when\nnotifications are bridged.\n\nAvoid duplicate notifications\n-----------------------------\n\n\nWhen you create notifications from an external source, such as from\n[Firebase Cloud Messaging](https://firebase.google.com/docs/cloud-messaging/), your\nmobile app and your wearable app can each display its own notifications on the watch. To avoid\nthis sort of duplication, programmatically disable bridging in your wearable app.\n\n### Use bridge tags\n\n\nIf you want to bridge some of the notifications created on your mobile app to the watch\nwhen your wearable app is installed, set bridge tags.\n\n\nSet a bridge tag on a notification by using the\n[setBridgeTag(String)](/reference/androidx/core/app/NotificationCompat.WearableExtender#setBridgeTag(java.lang.String))\nmethod, as shown in the following code sample:\n\n```kotlin\nval notification = NotificationCompat.Builder(context, channelId)\n // ... set other fields ...\n .extend(\n NotificationCompat.WearableExtender()\n .setBridgeTag(\"tagOne\")\n )\n .build()\n```\n\n### Disable bridging\n\nYou can disable bridging for some notifications or for all notifications.\nWe recommend that you selectively disable bridging.\n\n#### Disable bridging for *some* notifications\n\n\nYou can dynamically disable bridging and, optionally, permit some notifications\nthrough based on their tag. For example, to disable bridging for all notifications except those tagged as\n`tagOne`, `tagTwo`, or `tagThree`, use the\n[BridgingConfig](/reference/androidx/wear/phone/interactions/notifications/BridgingConfig)\nobject as shown in the following example: \n\n```kotlin\nBridgingManager.fromContext(context).setConfig(\n BridgingConfig.Builder(context, false)\n .addExcludedTags(listOf(\"tagOne\", \"tagTwo\", \"tagThree\"))\n .build()\n)\n```\n\n#### Disable bridging for *all* notifications (not recommended)\n\n\n**Note:** Disabling bridging for all notifications is not recommended, because\nthe bridging configuration set in the manifest takes effect as soon as a watch app is installed.\nThis can lead to notifications being lost if the user needs to open and set up the watch app\nbefore receiving notifications.\n\n\nTo prevent bridging of all notifications from a\nphone app, use the `\u003cmeta-data\u003e` entry in the manifest file of the watch app, as shown in the following example: \n\n```xml\n\u003capplication\u003e\n...\n \u003c!-- Beware, this can have unintended consqequences before the user is signed-in --\u003e\n \u003cmeta-data\n android:name=\"com.google.android.wearable.notificationBridgeMode\"\n android:value=\"NO_BRIDGING\" /\u003e\n...\n\u003c/application\u003e\n```\n\n\n**Note:** Specifying a bridging configuration at runtime overrides a bridging-related\nsetting in the Android manifest file.\n\n### Set a dismissal ID to sync similar notifications\n\n\nWhen you prevent bridging with the bridging mode feature, dismissals of notifications are not\nsynced across a user's devices.\n\n\nHowever, if similar notifications are created on both the mobile device and the watch, you want both\nnotifications to be dismissed when the user dismisses either one of them.\n\n\nIn the\n[NotificationCompat.WearableExtender](/reference/androidx/core/app/NotificationCompat.WearableExtender),\nyou can set a global unique ID so that when a notification dismisses, other notifications\nwith the same ID on paired watches are also dismissed.\n\n\nThe\n`NotificationCompat.WearableExtender`\nclass has methods that let you use dismissal IDs, as shown in the following example: \n\n```kotlin\nfun setDismissalId(dismissalId: String): WearableExtender\nfun getDismissalId(): String\n```\n\n\nTo sync a dismissal, use the\n[setDismissalId()](/reference/android/app/Notification.WearableExtender#setDismissalId(java.lang.String))\nmethod. For each notification, pass a globally unique ID as a string when you call the\n`setDismissalId()` method.\n\n\nWhen the notification dismisses, all other notifications with the same dismissal ID are\ndismissed on the watch and on the phone. To retrieve a dismissal ID, use\n`getDismissalId()`\n\n\nIn the following example, a globally unique ID is\nspecified for a new notification, so dismissals are synced: \n\n```kotlin\nval notification = NotificationCompat.Builder(context, channelId)\n // Set other fields ...\n .extend(\n NotificationCompat.WearableExtender()\n .setDismissalId(\"abc123\")\n )\n .build()\n```\n\n\n**Note:** Dismissal IDs work if a watch is paired to an Android phone, but not if a watch is\npaired to an iPhone.\n\nWhen notifications aren't bridged\n---------------------------------\n\n\nThe following types of notifications are not bridged:\n\n- Local-only notifications set using [Notification.Builder.setLocalOnly(boolean)](/reference/android/app/Notification.Builder#setLocalOnly(boolean)).\n- Ongoing notifications set using [Notification.Builder.setOngoing(boolean)](/reference/android/app/Notification.Builder#setOngoing(boolean)) or [Notification.FLAG_ONGOING_EVENT](/reference/android/app/Notification#FLAG_ONGOING_EVENT).\n- Non-clearable notifications set using [Notification.FLAG_NO_CLEAR](/reference/android/app/Notification#FLAG_NO_CLEAR).\n- Notifications where the counterpart wearable app has disabled notification bridging, as described previously.\n\nBest practices for bridged notifications\n----------------------------------------\n\n\nIt takes time to push or remove bridged notifications from a wearable\ndevice. As you design your notifications, make sure to avoid unexpected\nbehavior caused by this latency. The following guidelines help\nensure that your bridged notifications work with asynchronous notifications:\n\n- If you cancel a notification on the phone, it may take some time to cancel the corresponding notification on the watch. During this time, the user might send one of the pending intents on that notification. For this reason, continue to receive pending intents in your app from notifications it has canceled: when canceling notifications, keep those notifications' pending intent receivers valid.\n- Don't 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 reduces your app's impact on battery life.\n\n### Design considerations\n\n\nWear OS notifications have their own design guidelines. For more information,\nreview the [Wear OS Design Guidelines](/training/wearables/design)."]]