[[["容易理解","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-27 (世界標準時間)。"],[],[],null,["# Prepare your app for behavior changes in Wear OS 4\n\nWear OS 4 is based on Android 13 (API level 33), which is several versions\nhigher than the version on which Wear OS 3 is based, Android 11 (API level 30).\nSo when you prepare your Wear OS app for use on Wear OS 4, you need to handle\nthe system behavior changes that take effect for all apps in [Android 12](/about/versions/12/behavior-changes-all) and\n[Android 13](/about/versions/13/behavior-changes-all).\n\nYou can further improve your app's compatibility with this version of Wear OS by\n[targeting Android 13 (API level 33)](/training/wearables/versions/4/update-target-sdk).\n| **Note:** After you update your app, test your app's behavior on real devices.\n\nChanges to permissions\n----------------------\n\nThe following changes related to permissions are most likely to affect your\nWear OS app on a device that runs Wear OS 4 or higher.\n\n### Notification permission\n\n**Figure 1.** The system permissions dialog that asks users to let your Wear OS app post notifications. Users can choose between **Allow** and **Don't allow**.\n\nIn most cases, users must grant a [notification runtime permission](/develop/ui/views/notifications/notification-permission) for your\napp, including when your app posts notifications of [ongoing activities](/training/wearables/notifications/ongoing-activity). \n**Note:** The notification permission doesn't apply to [bridged notifications](/training/wearables/notifications/bridger), as well as [several\nspecific use cases that are exempt](/develop/ui/views/notifications/notification-permission#exemptions), such as those related to media sessions.\n\nWhen users install your app on a device that runs Wear OS 4 or higher, your\napp's notifications are off by default. Before you post a local notification or\nlaunch an ongoing activity, check whether your app is allowed to post\nnotifications by calling [`areNotificationsEnabled()`](/reference/android/app/NotificationManager#areNotificationsEnabled()). If this method\nreturns `true`, your app can show notifications. If your app doesn't have the\nproper permission, these notifications silently fail without any runtime\nexceptions being thrown.\n\nWhen you request the [`POST_NOTIFICATIONS`](/reference/android/Manifest.permission#POST_NOTIFICATIONS) permission in your app, users\nsee the system permissions dialog that appears in figure 1.\n\n### Background body sensors permission\n\nOn a device that runs Wear OS 4 or higher, users must grant your app permission\nto get information from common body sensors, such as heart rate, in the\nbackground.\n\nLearn more in the guide to\n[requesting background access to body sensor data](/health-and-fitness/guides/health-services/background-body-sensors).\n\n### Approximate location permission\n\nOn a device that runs Wear OS 4 or higher, users can request that your app\nretrieve only approximate location information, even when your app requests the\n[`ACCESS_FINE_LOCATION`](/reference/android/Manifest.permission#ACCESS_FINE_LOCATION) runtime permission.\n\nCheck that your app can still fulfill its key use cases, such as showing a\nrunning route, if the user grants only approximate location. In particular, when\nusing Health Services on Wear OS, take position errors into account.\n\nLearn more about how the [user can grant only approximate location](/training/location/permissions#approximate-request).\n\nChanges to app components and navigation\n----------------------------------------\n\nThe following changes related to app components and navigation are most likely\nto affect your Wear OS app on a device that runs Wear OS 4 or higher.\n\n### Intent filters block non-matching intents\n\nWhen your app sends an intent to an exported component of another app that\ntargets Android 13 or higher, that intent is delivered if and only if it matches\nan `\u003cintent-filter\u003e` element in the receiving app.\n\nLearn how to [match intents to other apps' intent filters](/guide/components/intents-filters#match-intent-filter).\n\n### Root launcher activity behavior\n\nA launcher activity is at the *root* of a task if it declares an intent filter\nthat includes both [`ACTION_MAIN`](/reference/android/content/Intent#ACTION_MAIN) and [`CATEGORY_LAUNCHER`](/reference/android/content/Intent#CATEGORY_LAUNCHER).\n\nIf the user navigates away from this sort of launcher activity to the previous\nscreen, the system doesn't finish the launcher activity. Instead, it places the\nlauncher activity in the background.\n\nLearn more about this change to [root launcher activities](/about/versions/12/behavior-changes-all#back-press) and the activity\nlifecycle.\n\n### App links verification\n\nThe system makes several changes to how Android App Links are verified. In\nparticular, the system [enforces a stricter intent filter syntax](/training/app-links/verify-android-applinks#add-intent-filters) for\ndemonstrating that URLs in a particular domain should open content directly in\nyour app. These changes improve the reliability of the app-linking experience,\nwhich provides more control to app developers and end users.\n\nTo test the reliability of your declarations,\n[manually invoke domain verification](/training/app-links/verify-android-applinks#manual-verification).\n\n### System alert window UI is removed\n\nWear OS 4 removes the system UI for granting the [`SYSTEM_ALERT_WINDOW`](/reference/android/Manifest.permission#SYSTEM_ALERT_WINDOW)\npermission. This UI is available on some devices that run Wear OS 3 and lower.\n\nIf you use [`ACTION_MANAGE_OVERLAY_PERMISSION`](/reference/android/provider/Settings#ACTION_MANAGE_OVERLAY_PERMISSION) to send users to a settings\npage, where they could display your app over other apps, update your app's\nlogic. For example, if you rely on system alert windows to show important\nmessages, use [notifications](/training/wearables/notifications) instead.\n\nChanges to power and data management\n------------------------------------\n\nThe following changes related to power and data management are most likely\nto affect your Wear OS app on a device that runs Wear OS 4.\n\n### Restricted App Standby Bucket\n\nThe system places your app in the [\"restricted\" App Standby Bucket](/topic/performance/appstandby#restricted-bucket) if it's\nnot used for an extended period of time, or if it invokes an excessive number of\nbroadcasts and bindings.\n\n### App hibernation\n\nIf the user doesn't interact with your app for a few months, the system places\nyour app in a [hibernation](/topic/performance/app-hibernation) state.\n\n### Backup \\& Restore\n\nStarting in Wear OS 4, if a specific Wear OS device supports cloud backup, users\ncan [back up their data to the cloud](/training/wearables/data/cloud-backup-restore) to transfer data off that device, and\nthey can restore data from the cloud to transfer data onto a new Wear OS device.\n\nRecommended for you\n-------------------\n\n- Note: link text is displayed when JavaScript is off\n- [Behavior changes: all apps](/about/versions/12/behavior-changes-all)\n- [Foreground services](/develop/background-work/services/foreground-services)\n- [Notification runtime permission](/develop/ui/views/notifications/notification-permission)"]]