앱의 특정 작업이 특정 특별 권한과 연결되도록 앱의 UX를 설계합니다. 앱이 비공개 사용자 데이터에 액세스하도록 권한을 부여해야 할 수도 있는 작업을 사용자에게 알립니다.
특정 비공개 사용자 데이터에 액세스해야 하는 앱의 작업을 사용자가 호출할 때까지 기다립니다. 이때 앱은 데이터에 액세스하는 데 필요한 특별 권한을 요청할 수 있습니다.
사용자가 이미 앱에 필요한 특별 권한을 부여했는지 확인합니다. 그렇게 하려면 각 권한의 맞춤 검사 함수를 사용합니다. 부여했다면 앱에서 비공개 사용자 데이터에 액세스할 수 있습니다. 부여하지 않았다면 다음 단계로 이동합니다. 참고: 권한이 필요한 작업을 실행할 때마다 권한이 있는지 확인해야 합니다.
UI 요소에 사용자가 특별 권한을 부여하면 앱이 어떤 데이터에 액세스하는지 그리고 앱이 사용자에게 어떤 이점을 제공할 수 있는지 명확하게 설명하는 근거를 제시합니다. 또한 앱이 권한 부여를 위해 사용자를 시스템 설정으로 이동시키므로, 사용자가 권한을 부여할 수 있는 방법을 설명하는 간단한 안내도 포함합니다. 근거 UI는 사용자가 권한 부여를 거부할 수 있는 명확한 옵션을 제공해야 합니다. 사용자가 근거를 확인한 후 다음 단계를 진행합니다.
앱에서 비공개 사용자 데이터에 액세스하는 데 필요한 특별 권한을 요청합니다. 여기에는 시스템 설정 내에서 사용자가 권한을 부여할 수 있는 해당 페이지로 연결되는 인텐트가 포함될 수 있습니다. 런타임 권한과 달리 팝업 권한 대화상자가 없습니다.
사용자의 응답(사용자가 특별 권한을 부여하도록 선택했는지 아니면 거부하도록 선택했는지)을 onResume() 메서드에서 확인합니다.
사용자가 앱에 권한을 부여하면 비공개 사용자 데이터에 액세스할 수 있습니다. 사용자가 권한을 거부하면 권한으로 보호되는 정보 없이도 사용자에게 기능을 제공하도록 앱 환경의 성능을 단계적으로 저하합니다.
그림 2. Android에서 특별 권한을 선언하고 요청하기 위한 워크플로
특별 권한 요청
런타임 권한과 달리 사용자는 시스템 설정의 특수 앱 액세스 페이지에서 특별 권한을 부여해야 합니다. 앱은 인텐트를 사용하여 사용자를 이 페이지로 이동시킬 수 있습니다. 인텐트는 앱을 일시중지하고 지정된 특별 권한에 상응하는 설정 페이지를 실행합니다.
사용자가 앱으로 돌아온 후 앱은 onResume() 함수에서 권한이 부여되었는지 확인할 수 있습니다.
valalarmManager=getSystemService<AlarmManager>()!!when{// if permission is granted, proceed with scheduling exact alarms…alarmManager.canScheduleExactAlarms()->{alarmManager.setExact(...)}else->{// ask users to grant the permission in the corresponding settings pagestartActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))}}
다음은 onResume()에서 권한을 확인하고 사용자 결정을 처리하는 샘플 코드입니다.
overridefunonResume(){// ...if(alarmManager.canScheduleExactAlarms()){// proceed with the action (setting exact alarms)alarmManager.setExact(...)}else{// permission not yet approved. Display user notice and gracefully degradeyourappexperience.alarmManager.setWindow(...)}}
런타임 권한과 마찬가지로 앱은 사용자가 권한이 필요한 특정 작업을 요청할 때 컨텍스트 내에서 특별 권한을 요청해야 합니다. 예를 들어 사용자가 특정 시간에 전송될 이메일을 예약할 때까지 SCHEDULE_EXACT_ALARMS 권한 요청을 대기합니다.
요청 설명
시스템 설정으로 리디렉션하기 전에 이유를 제공합니다. 사용자가 특별 권한을 부여하기 위해 일시적으로 앱을 나가므로, 시스템 설정의 특수 앱 액세스 페이지로 인텐트를 실행하기 전에 인앱 UI를 표시합니다. 이 UI는 앱에 권한이 필요한 이유와 사용자가 설정 페이지에서 권한을 부여하는 방법을 명확하게 설명해야 합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-27(UTC)
[[["이해하기 쉬움","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(UTC)"],[],[],null,["A *special permission* guards access to system resources that are particularly\nsensitive or not directly related to user privacy. These permissions are\ndifferent than [install-time\npermissions](/guide/topics/permissions/overview#install-time) and [runtime\npermissions](/guide/topics/permissions/overview#runtime). \n**Figure 1.** The **Special app access** screen in system settings.\n\nSome examples of special permissions include:\n\n- Scheduling exact alarms.\n- Displaying and drawing over other apps.\n- Accessing all storage data.\n\nApps that declare a special permission are shown in the **Special app access**\npage in system settings (figure 1). To grant a special permission to the app, a\nuser must navigate to this page: **Settings \\\u003e Apps \\\u003e Special app access**.\n| **Note:** Special permissions should be only used in specific use cases, and there may be policy implications to adding them in your app,\n\nWorkflow\n\nTo request a special permission, do the following:\n\n1. In your app's manifest file, [declare the special\n permissions](/training/permissions/declaring) that your app might need to request.\n2. Design your app's UX so that specific actions in your app are associated with specific special permissions. Let users know which actions might require them to grant permission for your app to access private user data.\n3. [Wait for the user](/training/permissions/requesting#principles) to invoke the task or action in your app that requires access to specific private user data. At that time, your app can request the special permission that's required for accessing that data.\n4. Check whether the user has already granted the special permission that your app requires. To do so, use each permission's [custom checking\n function](#check-method). If granted, your app can access the private user data. If not, continue to the next step. Note: You must check whether you have the permission every time you perform an operation that requires that permission.\n5. [Present a rationale](#explain) to the user in a UI element that clearly explains what data your app is trying to access and what benefits the app can provide to the user if they grant the special permission. In addition, since your app sends users to system settings to grant the permission, also include brief instructions that explain how users can grant the permission there. The rationale UI should provide a clear option for the user to opt-out of granting the permission. After the user acknowledges the rationale, continue to the next step.\n6. [Request the special permission](#request) that your app requires to access the private user data. This likely involves an intent to the corresponding page in system settings where the user can grant the permission. Unlike [runtime permissions](/guide/topics/permissions/overview#runtime), there is no popup permission dialog.\n7. Check the user's response -- whether they chose to grant or deny the special permission -- in the `onResume()` method.\n8. If the user granted the permission to your app, you can access the private user data. If the user denied the permission instead, [gracefully degrade\n your app experience](/training/permissions/requesting#handle-denial) so that it provides functionality to the user without the information that's protected by that permission.\n\n**Figure 2.** Workflow for declaring and requesting special permissions on Android.\n\nRequest special permissions\n\nUnlike [runtime permissions](/guide/topics/permissions/overview#runtime), the\nuser must grant special permissions from the **Special App Access** page in\nsystem settings. Apps can send users there using an intent, which pauses the app\nand launches the corresponding settings page for a given special permission.\nAfter the user returns to the app, the app can check if the permission has been\ngranted in the `onResume()` function.\n\nThe following sample code shows how to request the\n[`SCHEDULE_EXACT_ALARMS`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM)\nspecial permission from users: \n\n val alarmManager = getSystemService\u003cAlarmManager\u003e()!!\n when {\n // if permission is granted, proceed with scheduling exact alarms...\n alarmManager.canScheduleExactAlarms() -\u003e {\n alarmManager.setExact(...)\n }\n else -\u003e {\n // ask users to grant the permission in the corresponding settings page\n startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))\n }\n }\n\nSample code to check the permission and handle user decisions in `onResume()`: \n\n override fun onResume() {\n // ...\n\n if (alarmManager.canScheduleExactAlarms()) {\n // proceed with the action (setting exact alarms)\n alarmManager.setExact(...)\n }\n else {\n // permission not yet approved. Display user notice and gracefully degrade\n your app experience.\n alarmManager.setWindow(...)\n }\n }\n\nBest practices and tips\n\nThe following sections provide some best practices and considerations when\nrequesting special permissions.\n\nEach permission has its own check method\n\nSpecial permissions operate differently than [runtime\npermissions](/training/permissions/requesting#request-permission). Instead,\nrefer to the [permissions API reference\npage](/reference/android/Manifest.permission) and use the custom access check\nfunctions for each special permission. Examples include\n[`AlarmManager#canScheduleExactAlarms()`](/reference/android/app/AlarmManager#canScheduleExactAlarms())\nfor the\n[`SCHEDULE_EXACT_ALARMS`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM)\npermission and\n[`Environment#isExternalStorageManager()`](/reference/android/os/Environment#isExternalStorageManager())\nfor the\n[`MANAGE_EXTERNAL_STORAGE`](/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE)\npermission.\n\nRequest in-context\n\nSimilar to runtime permissions, apps should request special permissions\nin-context when the user requests a specific action that requires the\npermission. For example, wait to request the `SCHEDULE_EXACT_ALARMS` permission\nuntil the user schedules an email to be sent at a specific time.\n\nExplain the request\n\nProvide a rationale before redirecting to system settings. Since users leave the\napp temporarily to grant special permissions, show an in-app UI before you\nlaunch the intent to the **Special App Access** page in system settings. This UI\nshould clearly explain why the app needs the permission and how the user should\ngrant it on the settings page."]]
