使用者可在系統提出要求時「以及」在設定中拒絕個別權限，但對於因此而導致功能異常中斷的情況，仍可能感到不知所措。建議您監控拒絕授權的使用者人數 (例如使用 Google Analytics)，據此重構出不需使用該項權限的應用程式，或是提供更詳盡的說明，讓使用者瞭解為何需要此權限才能讓應用程式順利運作。此外，當使用者拒絕權限要求或在設定中關閉權限時，您必須確保應用程式能夠處理例外狀況。
[[["容易理解","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-21 (世界標準時間)。"],[],[],null,["# App permissions best practices\n\nPermission requests protect sensitive information available from a device and\nshould only be used when access to information is necessary for the\nfunctioning of your app. This document provides tips on ways you might be\nable to achieve the same (or better) functionality without requiring access\nto such information; it is not an exhaustive discussion of how permissions\nwork in the Android operating system.\n\n\nFor a more general look at Android permissions, please see [Permissions overview](/guide/topics/permissions/requesting). For details on how to work with permissions in your code,\nsee [Requesting app permissions](/training/permissions/requesting).\n\nPermissions in Android 6.0+\n---------------------------\n\n\nIn Android 6.0 (API level 23) and higher, apps can request permissions from\nthe user at runtime, rather than prior to installation. This allows apps to\nrequest permissions when the app actually requires the services or data\nprotected by the services. While this doesn't (necessarily) change overall app\nbehavior, it does create a few changes relevant to the way sensitive user data\nis handled:\n\n### Increased situational context\n\nUsers are prompted at runtime, in the context of your app, for permission to\naccess the functionality covered by those permission groups. Users are more\nsensitive to the context in which the permission is requested, and if there's a mismatch\nbetween what you are requesting and the purpose of your app, it's even\nmore important to provide detailed explanation to the user as to why you're\nrequesting the permission. Whenever possible, you should provide an\nexplanation of your request both at the time of the request and in a\nfollow-up dialog if the user denies the request.\n\nTo increase the likelihood of a permission request being accepted, only prompt\nwhen a specific feature is required. For instance, only prompt for microphone\naccess when a user clicks on the microphone button. Users are more likely to\nallow a permission that they are expecting.\n| **Note:** Don't overburden the user by requesting every permission at app startup. Be courteous of the user and only request permissions when they need access to a specific feature.\n\n### Greater flexibility in granting permissions\n\nUsers can deny access to individual permissions at the time they're requested\n*and* in settings, but they may still be surprised when functionality is\nbroken as a result. It's a good idea to monitor how many users are denying\npermissions (e.g. using Google Analytics) so that you can either refactor\nyour app to avoid depending on that permission or provide a better\nexplanation of why you need the permission for your app to work properly. You\nshould also make sure that your app handles exceptions when users\ndeny permission requests or toggle off permissions in settings.\n\n### Increased transactional burden\n\nUsers are asked to grant access for permission groups individually and not as a set. This\nmakes it extremely important to minimize the number of permissions you're\nrequesting. This increases the user-burden for granting permissions and therefore\nincreases the probability that at least one of the requests will be denied.\n\nPermissions that require becoming a default handler\n---------------------------------------------------\n\nSome apps depend on access to sensitive user information related to call logs\nand SMS messages. If you want to request the permissions specific to call logs\nand SMS messages and publish your app to the Play Store, you must prompt the\nuser to set your app as the *default handler* for a core system function before\nrequesting these runtime permissions.\n\nFor more information on default handlers, including guidance on showing a\ndefault handler prompt to users, [see the guide on permissions used only in\ndefault handlers](/guide/topics/permissions/default-handlers).\n\n[](/training/permissions/know_the_libraries_you're_working_with)\n\nKnow the libraries you're working with\n--------------------------------------\n\n\nSometimes permissions are required by the libraries you use in your app. For\nexample, ads and analytics libraries may require access to the\n`LOCATION` permissions group to implement the required\nfunctionality. But from the user's point of view, the permission request comes\nfrom your app, not the library.\n\n\nJust as users select apps that use fewer permissions for the same\nfunctionality, developers should review their libraries and select\nthird-party SDKs that aren't using unnecessary permissions. For example, if\nyou're using a library that provides location functionality, make sure you\naren't requesting the `FINE_LOCATION` permission unless you're\nusing location-based targeting functionality.\n\nLimit background access to location\n-----------------------------------\n\nWhen your app is running in the background, [access to\nlocation](/training/location/background) should be critical to the app's core\nfunctionality and show a clear benefit to users.\n\nTest for both permissions models\n--------------------------------\n\n\nIn Android 6.0 (API level 23) and higher, users grant and revoke app\npermissions at run time, instead of doing so when they install the app. As a\nresult, you'll have to test your app under a wider range of conditions. Prior\nto Android 6.0, you could reasonably assume that if your app is running at\nall, it has all the permissions it declares in the app manifest. Now, the user\ncan turn permissions on or off for *any* app, regardless of API level.\nYou should test to ensure your app functions correctly across various\npermission scenarios.\n\n\nThe following tips will help you find permissions-related code problems\non devices running API level 23 or higher:\n\n- Identify your app's current permissions and the related code paths.\n- Test user flows across permission-protected services and data.\n- Test with various combinations of granted or revoked permissions. For example, a camera app might list [CAMERA](/reference/android/Manifest.permission#CAMERA), [READ_CONTACTS](/reference/android/Manifest.permission#READ_CONTACTS), and [ACCESS_FINE_LOCATION](/reference/android/Manifest.permission#ACCESS_FINE_LOCATION) in its manifest. You should test the app with each of these permissions turned on and off, to make sure the app can handle all permission configurations gracefully.\n- Use the [adb](/tools/help/adb) tool to manage permissions from the command line:\n - List permissions and status by group: \n\n ```\n $ adb shell pm list permissions -d -g\n ```\n - Grant or revoke one or more permissions: \n\n ```\n $ adb shell pm [grant|revoke] \u003cpermission-name\u003e ...\n ```\n- Analyze your app for services that use permissions.\n\nAdditional resources\n--------------------\n\n- [Material Design guidelines for Android permissions](https://material.io/design/platform-guidance/android-permissions.html#usage)\n- [Android Marshmallow 6.0: Asking For Permission](https://www.youtube.com/watch?v=iZqDdvhTZj0): This video explains the Android runtime permission model and the right way to ask users for permissions.\n- [Explain why the app needs permissions](/training/permissions/requesting#explain)\n- [Best practices for unique identifiers](/training/articles/user-data-ids)"]]
