تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تكون المنبّهات الدقيقة مخصّصة للإشعارات أو الإجراءات التي يريدها المستخدم والتي يجب
أن تحدث في وقت محدد.
SCHEDULE_EXACT_ALARM، وهو الإذن الذي تم تقديمه في الإصدار 12 من نظام التشغيل Android للتطبيقات
جدولة المنبّهات المحددة الوقت، لم يعد يتم منحها مسبقًا إلى الأجهزة التي تم تثبيتها حديثًا
التطبيقات التي تستهدف الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث (سيتم ضبطها على "مرفوضة" تلقائيًا) في حال حذف
نقل المستخدم بيانات التطبيق إلى جهاز يعمل بنظام التشغيل Android 14 من خلال
عملية النسخ الاحتياطي والاستعادة، فسيظل الإذن مرفوضًا. إذا كانت
لدى التطبيق الحالي هذا الإذن، وسيتم منحه مسبقًا عندما يكون الجهاز
الترقيات إلى Android 14
يجب الحصول على إذن SCHEDULE_EXACT_ALARM لبدء المنبّهات المحدَّدة الوقت
من خلال واجهات برمجة التطبيقات التالية، وإلا سيتم طرح SecurityException:
يجب أن تشير تطبيقات التقويم والمنبّهات إلى استخدام الإذن USE_EXACT_ALARM.
يجب أن ترسل تطبيقات التقويم أو المنبّهات تذكيرات التقويم أو المنبّهات للاستيقاظ
أو التنبيهات عندما لا يكون التطبيق قيد التشغيل. يمكن لهذه التطبيقات طلب الإذن العادي
USE_EXACT_ALARM. سيتم منح إذن USE_EXACT_ALARM
عند التثبيت، وستتمكّن التطبيقات التي تمتلك هذا الإذن من جدولة
إنذارات دقيقة تمامًا مثل التطبيقات التي تمتلك إذن SCHEDULE_EXACT_ALARM.
حالات الاستخدام التي قد لا تتطلّب منبّهات محدَّدة الوقت
نظرًا لأنه تم رفض إذن SCHEDULE_EXACT_ALARM تلقائيًا الآن
تتطلب عملية منح الأذونات خطوات إضافية من المستخدمين، فإن المطورين
ننصح بشدة بتقييم حالات الاستخدام وتحديد ما إذا كانت المنبّهات المحدَّدة الوقت
منطقية لحالات الاستخدام الخاصة بها.
تعرض القائمة التالية سير العمل الشائع الذي قد لا يتطلّب منبّهًا محدَّدًا:
جدولة مهام متكررة خلال مدة استخدام تطبيقك
تكون طريقة set() مفيدة إذا كانت المهمة تتطلّب مراعاة قيود الوقت الفعلي، مثل إيقافها في الساعة 2:00 بعد الظهر غدًا أو بعد 30 دقيقة.
بخلاف ذلك، ننصحك باستخدام postAtTime() أو
postDelayed() طريقة بدلاً من ذلك.
الأعمال التي تم إجراؤها في الخلفية، مثل تحديث التطبيق وتحميل السجلّات
إجراء يحدّده المستخدم من المفترض أن يحدث بعد وقت محدّد
يُرجى استخدام منبّه غير محدَّد. يُرجى الاتصال بالرقم set().
إجراء يحدده المستخدم ويمكن أن يحدث في فترة زمنية
استخدام منبّه غير دقيق على وجه التحديد، الاتصال بـ setWindow(). يُرجى العِلم أنّ
أقصر مدة مسموح بها هي 10 دقائق.
خطوات نقل البيانات لمواصلة استخدام المنبّهات المحدَّدة الوقت
على التطبيقات التحقّق على الأقل ممّا إذا كانت تملك الإذن قبل
جدولة المنبّهات المحدَّدة الوقت. إذا لم تكن التطبيقات تملك الإذن، عليها أن تطلبه
من المستخدم من خلال استدعاء نية.
إذا لم يكن لدى التطبيق الإذن، يمكنك استدعاء نية تتضمّن ACTION_REQUEST_SCHEDULE_EXACT_ALARM، بالإضافة إلى اسم حِزمة التطبيق، لطلب منح الإذن من المستخدمين.
إذا منح المستخدم الإذن لتطبيقك، يمكنه ضبط إعدادات
المنبّهات. إذا رفض المستخدم الإذن، يمكنك تقليل وظائف
تطبيقك بشكل سلس حتى يقدّم وظائف
للمستخدم بدون المعلومات المحمية بهذا الإذن.
يوضح مقتطف الرمز التالي كيفية التحقق من
إذن 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(...)}}
خفض الترتيب بشكل تدريجي عند رفض الإذن
سيرفض بعض المستخدمين منح الإذن. في هذا السيناريو، نوصي
تعمل على خفض مستوى التجربة بشكل سلس ومواصلة السعي لتقديم أفضل
تجربة المستخدم الاحتياطية المحتملة من خلال تحديد حالات الاستخدام لديه.
التطبيقات المدرَجة في القائمة المسموح بها للتطبيقات التي تتطلب إذن الوصول إلى الموارد العالية (إذا كان تطبيقك يستوفي المتطلبات، يمكنك
طلب ذلك باستخدام
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS إجراء النية).
لاختبار هذا التغيير، قم بإيقاف تشغيل المنبّهات إذن التذكيرات في تطبيقك
من صفحة أذونات خاصة للتطبيقات في إعدادات النظام (الإعدادات > التطبيقات >
أذونات خاصة للتطبيقات > المنبّهات تذكيرات) ومراقبة سلوك تطبيقك.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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,["# 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."]]