[[["容易理解","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-08-27 (世界標準時間)。"],[],[],null,["keywords: wear, permissions, collection_guideslandingwear\nimage_path: images/training/wear/multiple_permissions.png\n\nRequesting permissions on Wear OS is similar to requesting permissions in\nmobile apps, with a couple of additional use cases. This document assumes you\nunderstand how Android permissions work. If you don't, review how [permissions\nwork on Android](/guide/topics/permissions/overview).\n\nJust like in a mobile app, the user must grant permissions to a Wear app for\naccess to certain functionality. In your Wear apps, [provide meaningful\nfunctionality](/training/permissions/evaluating) without requesting any\npermissions.\n| **Note:** A Wear app can't assume the permissions granted in a phone app. For example, if a user grants a phone app the permission to use location data, the user must grant the Wear app the same permission before the Wear app can access the data.\n\nPermission scenarios\n\nThere are several scenarios you might encounter when requesting\n[dangerous permissions](/guide/topics/permissions/requesting#normal-dangerous)\non Wear OS:\n\n- The Wear app requests permissions for an app running on the wearable\n device.\n\n- The Wear app requests permissions for an app running on the phone.\n\n- The phone app requests permissions for an app running on the wearable\n device.\n\n- The phone app requests multiple permissions that can be used only while the\n wearable device is connected.\n\nTo see all these scenarios in a working app, review the\n[ExerciseSampleCompose](https://github.com/android/health-samples/tree/main/health-services/ExerciseSampleCompose)\nsample on GitHub.\n\nThe following sections explain each of these scenarios. For more detailed\ninformation about requesting permissions, see the [Permission-request\npatterns](#requesting) section.\n\nWear app requests wearable permission\n\nWhen the Wear app requests a permission for an app running on the wearable\ndevice, the system displays a dialog to prompt the user for that permission.\nIn your app, request permissions only when it is clear to the user why the\npermissions are needed to perform a given operation.\n\nReview the [permission principles](/training/permissions/requesting#principles)\nto make sure you provide the best experience for your users, and remember\nto check\n[`shouldShowRequestPermissionRationale()`](/reference/androidx/core/app/ActivityCompat#shouldShowRequestPermissionRationale(android.app.Activity,%20java.lang.String))\nand [provide additional information](/training/permissions/requesting#explain)\nas needed.\n\nIf an app or watch face requires more than one permission at a time, permission\nrequests appear one after the other.\n**Figure 1.** Permission screens appearing in succession. **Note:** Wear OS automatically syncs Calendar, Contact, and Location data to the Wear device. This scenario is applicable when Wear requests this data.\n\nWear app requests phone permission\n\nWhen the Wear app requests a phone permission---for example, a wearable app wants\naccess to photos or other sensitive data on the mobile version of the app---the\nWear app must send the user to the phone to accept the permission. There, the\nphone app can provide additional information to the user, using an activity.\nIn the activity, include two buttons: one for granting the permission and one\nfor denying it.\n**Figure 2.** Send the user to the phone to grant permission.\n\nPhone app requests wearable permission\n\nIf the user is in a phone app and the app requires a wearable permission---for\nexample, to preload music in case the phone gets disconnected---the phone app\nsends the user to the wearable device to accept the permission. The wearable\nversion of the app uses the\n[`requestPermissions()`](/reference/androidx/core/app/ActivityCompat#requestPermissions(android.app.Activity,%20java.lang.String%5B%5D,%20int))\nmethod to trigger the system permissions dialog.\n**Figure 3.** Send the user to the wearable to grant permission.\n\nPhone app requests multiple permissions at once **Figure 4.** A permissions dialog that uses a companion device profile to request multiple permissions in a single request.\n\nPartner apps on Android 12 (API level 31) and higher can use companion device\nprofiles when connecting to a watch. Using a profile simplifies the enrollment\nprocess by bundling the granting of a device-type-specific set of permissions\ninto one step.\n\nThe bundled permissions are granted to the companion app once the device\nconnects, and last only while the device is associated. Deleting the app or\nremoving the association removes the permissions. For details, see\n[`AssociationRequest.Builder.setDeviceProfile()`](/reference/android/companion/AssociationRequest.Builder#setDeviceProfile(java.lang.String)).\n\n\n| **Note:** To use companion device profiles, your devices must be connected using [`CompanionDeviceManager`](/reference/android/companion/CompanionDeviceManager). If your app is not already using `CompanionDeviceManager`, see [Companion device pairing](/guide/topics/connectivity/companion-device-pairing) to get started.\n\nPermission-request patterns\n\nThere are different patterns for requesting permissions from users. In order of\npriority, they are:\n\n- Ask in context when the permission is obviously necessary for a\n specific functionality but isn't necessary for the app as a whole to run.\n\n- Educate in context when the reason for requesting the permission isn't\n obvious and the permission isn't necessary for the app as a whole to run.\n\nThese patterns are explained in the following sections.\n\nAsk in context\n\nRequest permissions when it is clear to the user why the permission is needed\nto perform a given operation. Users are more likely to grant a permission when\nthey understand its connection to the feature they want to use.\n\nFor example, an app might require the user's location to show nearby places\nof interest. When the user taps to search for nearby places, the app can\nimmediately request the location permission because there is a clear\nrelationship between searching for nearby places and the need for the location\npermission. The obviousness of this relationship makes it unnecessary for the\napp to display additional education screens.\n**Figure 5.** Ask for a permission in context.\n\nEducate in context\n\nFigure 6 shows an example of in-context education. The app doesn't require\npermissions to start the timer, but an inline educational cue shows\nthat part of the activity---location detection---is locked. When the user taps the\ncue, a permission-request screen appears, letting the user unlock location\ndetection.\n\nUse the\n[`shouldShowRequestPermissionRationale()`](/reference/androidx/core/app/ActivityCompat#shouldShowRequestPermissionRationale(android.app.Activity,%20java.lang.String))\nmethod to help your app decide whether to provide more information. For\nadditional details, see [Request app\npermissions](/training/permissions/requesting#explain). Alternatively, you\ncan examine how the speaker sample application on GitHub handles [showing\ninformation](https://github.com/android/wear-os-samples/blob/main/WearSpeakerSample/wear/src/main/java/com/example/android/wearable/speaker/SpeakerApp.kt#L117).\n**Figure 6.** Educate in context.\n\nHandle rejection\n\nIf the user denies a requested permission that isn't critical to an intended\nactivity, don't block them from continuing the activity. If certain parts of\nthe activity are disabled by the denied permission, provide visual, actionable\nfeedback.\n\nFigure 7 shows the use of a lock icon to indicate that a feature is locked\nbecause the user didn't grant permission to use it.\n**Figure 7.** Lock icon showing that a feature is locked because of denied permission.\n\nWhen a previously denied wearable permission dialog appears a second time, it\nincludes a **Deny, don't show again** option. If the user chooses this option,\nthen the only way for them to grant this permission in the future is to go into\nthe wearable's Settings app.\n**Figure 8.** The user can access a permission request that has previously been denied twice through Settings.\n\nLearn more about how to [handle permission denial](/training/permissions/requesting#handle-denial).\n\nPermissions for services\n\nOnly an activity can call the\n[`requestPermissions()`](/reference/androidx/core/app/ActivityCompat#requestPermissions(android.app.Activity,%20java.lang.String%5B%5D,%20int))\nmethod, so if the user interacts with your app using a service---for example,\nthrough a watch face---the service must open an activity before requesting the\npermission. In this activity, provide additional education on why the\npermission is needed.\n\nIn general, don't request permissions for a watch face. Instead, implement\na [complication](/training/wearables/watch-faces/complications) and let the user\nchoose which data to display through the complication.\n\nSettings\n\nA user can change a Wear app's permissions in Settings at any time. When the\nuser tries to do something that requires a permission, first call the\n[`checkSelfPermission()`](/reference/androidx/core/content/ContextCompat#checkSelfPermission(android.content.Context,%20java.lang.String))\nmethod to see whether the app has permission to perform the operation.\n\nPerform this check even if the user has previously\ngranted the permission, because the user might have subsequently revoked it.\n**Figure 9.** The user can change permissions using the Settings app.\n\nRecommended for you\n\n- Note: link text is displayed when JavaScript is off\n- [Request runtime permissions](/training/permissions/requesting)\n- [Bluetooth permissions](/develop/connectivity/bluetooth/bt-permissions)\n- [Communicate in the background](/develop/connectivity/bluetooth/ble/background)"]]