정확한 알람은 사용자가 의도한 알림이나 정확한 시간에 실행해야 하는 작업을 위한 것입니다.
앱이 정확한 알람을 예약할 수 있도록 Android 12에 도입된 권한인 SCHEDULE_EXACT_ALARM은 Android 13 이상을 타겟팅하는 새로 설치된 대부분의 앱에 더 이상 사전 부여되지 않습니다(기본적으로 거부됨으로 설정됨). 사용자가 백업 및 복원 작업을 통해 Android 14를 실행하는 기기로 앱 데이터를 전송하는 경우에도 권한은 계속 거부됩니다. 만약
이 권한은 기존 앱에 이미 있는 경우 기기에
Android 14로 업그레이드됩니다
다음 API를 통해 정확한 알람을 시작하려면 SCHEDULE_EXACT_ALARM 권한이 필요하며 권한이 없으면 SecurityException이 발생합니다.
캘린더 또는 알람 시계 앱은 앱이 더 이상 실행되지 않을 때 캘린더 리마인더, 기상 알람 또는 알림을 보내야 합니다. 이러한 앱은 USE_EXACT_ALARM 일반 권한을 요청할 수 있습니다. USE_EXACT_ALARM 권한은 설치 시 부여되며 이 권한이 있는 앱은 SCHEDULE_EXACT_ALARM 권한이 있는 앱과 마찬가지로 정확한 알람을 예약할 수 있습니다.
정확한 알람이 필요하지 않을 수 있는 사용 사례
이제 SCHEDULE_EXACT_ALARM 권한이 기본적으로 거부되고 권한 부여 프로세스에서 사용자가 추가 단계를 실행해야 하므로 개발자는 사용 사례를 평가하고 정확한 알람이 사용 사례에 여전히 필요한지 판단하는 것이 좋습니다.
다음 목록은 정확한 알람이 필요하지 않을 수 있는 일반적인 워크플로를 보여줍니다.
앱의 전체 기간 동안 반복되는 작업 예약
set() 메서드는 내일 오후 2시 또는 30분 후에 출발과 같이 작업에서 실시간 제약 조건을 염두에 두어야 할 때 유용합니다.
그 외의 경우에는 대신 postAtTime() 또는 postDelayed() 메서드를 사용하는 것이 좋습니다.
예약된 백그라운드 작업(예: 앱 업데이트 및 로그 업로드)
WorkManager는 시간에 민감한 주기적 작업을 예약하는 방법을 제공합니다.
반복 간격과 flexInterval(최소 15분)을 제공하여 작업의 세분화된 런타임을 정의할 수 있습니다.
사용자가 앱에 권한을 부여한 경우 앱은 정확한 알람을 설정할 수 있습니다. 사용자가 권한을 거부하면 권한으로 보호되는 정보 없이도 사용자에게 기능을 제공하도록 앱 환경의 성능을 단계적으로 저하합니다.
다음 코드 스니펫은 SCHEDULE_EXACT_ALARM 권한을 확인하는 방법을 보여줍니다.
valalarmManager:AlarmManager=context.getSystemService<AlarmManager>()!!when{// If permission is granted, proceed with scheduling exact alarms.alarmManager.canScheduleExactAlarms()->{alarmManager.setExact(...)}else->{// Ask users to go to exact alarm page in system settings.startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))}}
권한을 확인하고 onResume()에서 사용자의 결정을 처리하는 샘플 코드:
overridefunonResume(){…if(alarmManager.canScheduleExactAlarms()){// Set exact alarms.alarmManager.setExact(...)}else{// Permission not yet approved. Display user notice and revert to a fallback // approach.alarmManager.setWindow(...)}}
권한 거부 시 단계적으로 성능 저하
일부 사용자는 권한 부여를 거부합니다. 이 시나리오에서는 앱의 환경을 단계적으로 저하하면서도 사용 사례를 식별하여 가능한 최상의 대체 사용자 환경을 제공하기 위해 노력하는 것이 좋습니다.
이 변경사항을 테스트하려면 시스템 설정의 특수 앱 액세스 페이지에서 앱의 알람 및 리마인더 권한을 사용 중지하고(설정 > 앱 > 특수 앱 액세스 > 알람 및 리마인더) 앱의 동작을 관찰합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-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-07-27(UTC)"],[],[],null,["# Schedule exact alarms are denied by default\n\nExact alarms are meant for user-intentioned notifications or actions that need\nto happen at a precise time.\n\n[`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM), the permission introduced in Android 12 for apps to\nschedule exact alarms, is **no longer being pre-granted to most newly installed\napps targeting Android 13 and higher** (will be set to denied by default). If\nthe user transfers app data to a device running Android 14 through a\nbackup-and-restore operation, the permission will still be denied. If an\nexisting app already has this permission, it'll be pre-granted when the device\nupgrades to Android 14.\n\nThe [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM) permission is required to initiate exact alarms\nvia the following APIs or a `SecurityException` will be thrown:\n\n- [`setExact()`](/reference/android/app/AlarmManager#setExact(int,%20long,%20android.app.PendingIntent))\n- [`setExactAndAllowWhileIdle()`](/reference/android/app/AlarmManager#setExactAndAllowWhileIdle(int,%20long,%20android.app.PendingIntent))\n- [`setAlarmClock()`](/reference/android/app/AlarmManager#setAlarmClock(android.app.AlarmManager.AlarmClockInfo,%20android.app.PendingIntent))\n\n| **Note:** If the exact alarm is set using an [`OnAlarmListener`](/reference/android/app/AlarmManager.OnAlarmListener) object, like in the [`setExact`](/reference/android/app/AlarmManager#setExact(int,%20long,%20java.lang.String,%20android.app.AlarmManager.OnAlarmListener,%20android.os.Handler)) API, the `SCHEDULE_EXACT_ALARM` permission isn't required.\n\nExisting best-practices for the [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM) permission still\napply, including the following:\n\n- Check the permission with [`canScheduleExactAlarms()`](/reference/android/app/AlarmManager#canScheduleExactAlarms()) before scheduling exact alarms.\n- Set up your app to listen and properly react to the foreground broadcast [`AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED`](/reference/android/app/AlarmManager#ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED), which the system sends when the user grants the permission.\n\nAffected apps\n-------------\n\nIf a device is running Android 14 or higher, this change will affect a newly\ninstalled app that has the following characteristics:\n\n- Targets Android 13 (API level 33) or higher.\n- Declares the [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM) permission in the manifest.\n- Doesn't fall under an [exemption](#exemptions) or [pre-grant](#pre-grant) scenario.\n- **Isn't** a calendar or alarm clock app.\n\nCalendar and alarm clock apps should declare USE_EXACT_ALARM\n------------------------------------------------------------\n\n[Calendar or alarm clock apps](https://support.google.com/googleplay/android-developer/answer/12253906#exact_alarm_preview) need to send calendar reminders, wake-up\nalarms, or alerts when the app is no longer running. These apps can request the\n[`USE_EXACT_ALARM`](/reference/android/Manifest.permission#USE_EXACT_ALARM) normal permission. The `USE_EXACT_ALARM` permission will\nbe granted on install, and apps holding this permission will be able to schedule\nexact alarms just like apps with the [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM) permission.\n| **Note:** Apps will not be able to publish a version of their app with this permission in the manifest unless they qualify based on the [policy language](https://support.google.com/googleplay/android-developer/answer/12253906#exact_alarm_preview).\n\nUse cases that might not require exact alarms\n---------------------------------------------\n\nBecause the [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM) permission is now denied by default and\nthe permission grant process requires extra steps from users, developers are\nstrongly encouraged to evaluate their use cases and determine if exact alarms\nstill make sense for their use cases.\n\nThe following list shows common workflows that may not require an exact alarm:\n\nScheduling repeated work during the lifetime of your app\n: The [`set()`](/reference/android/app/AlarmManager#set(int,%20long,%20android.app.PendingIntent)) method is useful if the task needs to keep real-time\n constraints in mind, such as going off at 2:00 PM tomorrow or in 30 minutes.\n Otherwise, it's recommended to use the [`postAtTime()`](/reference/android/os/Handler#postAtTime(java.lang.Runnable,%20long)) or\n [`postDelayed()`](/reference/android/os/Handler#postDelayed(java.lang.Runnable,%20long)) methods instead.\n\nScheduled background work, such as updating your app and uploading logs\n: `WorkManager` provides a way to [schedule timing-sensitive periodic work](/topic/libraries/architecture/workmanager/how-to/define-work#flexible_run_intervals).\n You can provide a repeat interval and flexInterval (15 minutes minimum) to\n define granular runtime for the work.\n\nNeed alarm to go off at an approximate time while system is in idle state\n: Use an inexact alarm. Specifically, call [`setAndAllowWhileIdle()`](/reference/android/app/AlarmManager#setAndAllowWhileIdle(int,%20long,%20android.app.PendingIntent)).\n\nUser-specified action that should happen after a specific time\n: Use an inexact alarm. Specifically, call [`set()`](/reference/android/app/AlarmManager#set(int,%20long,%20android.app.PendingIntent)).\n\nUser-specified action that can happen within a time window\n: Use an inexact alarm. Specifically, call [`setWindow()`](/reference/android/app/AlarmManager#setWindow(int,%20long,%20long,%20android.app.PendingIntent)). Note that the\n smallest allowed window length is 10 minutes.\n\nMigration steps to continue using exact alarms\n----------------------------------------------\n\nAt a minimum, apps must check to see if they have the permission before\nscheduling exact alarms. If apps don't have the permission, they must request it\nfrom the user by invoking an intent.\n\nThis is the same as the standard workflow for [requesting a special\npermission](/training/permissions/requesting-special):\n\n1. Apps should call [`AlarmManager.canScheduleExactAlarms()`](/reference/android/app/AlarmManager#canScheduleExactAlarms()) to confirm that it has the appropriate permission.\n2. If the app doesn't have the permission, invoke an intent that includes the\n [`ACTION_REQUEST_SCHEDULE_EXACT_ALARM`](/reference/android/provider/Settings#ACTION_REQUEST_SCHEDULE_EXACT_ALARM), along with the app's package\n name, to ask users to grant the permission.\n\n [Check the user's decision](/reference/android/app/AlarmManager#set(int,%20long,%20android.app.PendingIntent)) in the [`onResume()`](/guide/components/activities/activity-lifecycle#onresume) method of your\n app.\n3. Listen for the\n [`AlarmManager.ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED`](/reference/android/app/AlarmManager#ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED)\n broadcasts that are sent if the user grants the permission.\n\n4. If the user granted the permission to your app, your app can set exact\n alarms. If the user denied the permission instead, [gracefully degrade your\n app experience](#gracefully-degrade) so that it provides functionality to\n the user without the information that's protected by that permission.\n\nThe following code snippet demonstrates how to check for the\n`SCHEDULE_EXACT_ALARM` permission: \n\n val alarmManager: AlarmManager = context.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 go to exact alarm page in system settings.\n startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))\n }\n }\n\nSample code to check the permission and handle the user's decisions in\n`onResume()`: \n\n override fun onResume() {\n ... \n if (alarmManager.canScheduleExactAlarms()) {\n // Set exact alarms.\n alarmManager.setExact(...)\n }\n else {\n // Permission not yet approved. Display user notice and revert to a fallback \n // approach.\n alarmManager.setWindow(...)\n }\n }\n\n### Gracefully degrade on permission denial\n\nSome users will refuse to grant the permission. In this scenario, we recommend\napps to gracefully degrade the experience and still strive to provide the best\npossible fallback user experience by identifying their [use cases](#use-cases).\n\nExemptions\n----------\n\nThe following types of apps are always allowed to call the [`setExact()`](/reference/android/app/AlarmManager#setExact(int,%20long,%20android.app.PendingIntent)) or\n[`setExactAndAllowWhileIdle()`](/reference/android/app/AlarmManager#setExactAndAllowWhileIdle(int,%20long,%20android.app.PendingIntent)) methods:\n\n- Apps signed with the platform certificate.\n- Privileged apps.\n- Apps that are on the power allowlist (if your app fits the requirements, you can [request this](/training/monitoring-device-state/doze-standby#exemption-cases) using the `ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS` intent action).\n\nPre-grants\n----------\n\n- Role holders of `SYSTEM_WELLBEING` will be pre-granted [`SCHEDULE_EXACT_ALARM`](/reference/android/Manifest.permission#SCHEDULE_EXACT_ALARM).\n\nTesting guidelines\n------------------\n\nTo test this change, disable the **Alarms \\& reminders** permission for your app\nfrom the **Special app access** page in system settings (**Settings \\\u003e Apps \\\u003e\nSpecial app access \\\u003e Alarms \\& reminders**) and observe the behavior of your app."]]
