Эта страница переведена с помощью Cloud Translation API.

Расписание будильников

Сигналы тревоги (основанные на классе AlarmManager ) позволяют выполнять операции, привязанные ко времени, за пределами жизненного цикла приложения. Например, сигнал тревоги можно использовать для запуска длительной операции, например, для запуска службы раз в день для загрузки прогноза погоды.

Сигнализации имеют следующие характеристики:

Они позволяют вам активировать намерения в заданное время и/или с заданными интервалами.
Их можно использовать совместно с широковещательными приемниками для планирования заданий или WorkRequests для выполнения других операций.
Они работают вне вашего приложения, поэтому вы можете использовать их для запуска событий или действий, даже когда ваше приложение не запущено, и даже если само устройство находится в спящем режиме.
Они помогают минимизировать требования к ресурсам вашего приложения. Вы можете планировать операции, не полагаясь на таймеры или постоянно работающие службы.

Установите неточный будильник

Когда приложение устанавливает неточный будильник , система подаст его в определённый момент в будущем. Неточные будильники обеспечивают определённые гарантии относительно времени срабатывания, учитывая ограничения по экономии заряда батареи, такие как режим Doze .

Разработчики могут использовать следующие гарантии API для настройки времени доставки неточных сигналов тревоги.

Подать сигнал тревоги через определенное время

Если ваше приложение вызывает set() , setInexactRepeating() или setAndAllowWhileIdle() , будильник никогда не сработает раньше указанного времени срабатывания.

На устройствах с Android 12 (уровень API 31) и выше система активирует будильник в течение одного часа с указанного времени срабатывания, если не действуют какие-либо ограничения по экономии заряда батареи, такие как режим экономии заряда батареи или режим Doze .

Подать сигнал тревоги в течение определенного временного окна

Если ваше приложение вызывает setWindow() , будильник никогда не сработает раньше указанного времени срабатывания. Если не действуют ограничения, связанные с экономией заряда батареи, будильник сработает в течение указанного временного окна, начиная с указанного времени срабатывания.

Если ваше приложение предназначено для Android 12 или более поздних версий, система может отложить срабатывание неточного будильника с временным интервалом не менее чем на 10 минут. Поэтому значения параметра windowLengthMillis ниже 600000 ограничиваются значением 600000 .

Подавать повторяющийся сигнал тревоги примерно через равные промежутки времени

Если ваше приложение вызывает setInexactRepeating() , система вызывает несколько оповещений:

Первый будильник срабатывает в указанном временном окне, начиная с заданного времени срабатывания.
Последующие сигналы будильника обычно срабатывают по истечении указанного временного интервала. Промежуток времени между двумя последовательными срабатываниями будильника может варьироваться.

Установите точный будильник

Система активирует точный сигнал тревоги в определенный момент в будущем.

Большинство приложений могут планировать задачи и события, используя неточные сигналы для решения ряда распространённых задач . Если основная функциональность вашего приложения зависит от точного сигнала, например, для будильника или календаря, то можно использовать точный сигнал.

Случаи использования, когда точные сигналы тревоги могут не требоваться

В следующем списке показаны общие рабочие процессы, для которых может не потребоваться точный сигнал тревоги:

Планирование операций по времени в течение жизненного цикла вашего приложения: Класс Handler включает несколько полезных методов для обработки операций синхронизации, например, выполнения определённой работы каждые n секунд, пока приложение активно: postAtTime() и postDelayed() . Обратите внимание, что эти API полагаются на время безотказной работы системы , а не на реальное время .
Запланированная фоновая работа, такая как обновление приложения и загрузка журналов: WorkManager позволяет планировать периодические задачи, привязанные к времени . Вы можете указать интервал повторения и flexInterval (минимум 15 минут), чтобы точно определить время выполнения задачи.
Указанное пользователем действие, которое должно произойти по истечении определенного времени (даже если система находится в состоянии ожидания): Используйте неточный сигнал тревоги. В частности, вызовите setAndAllowWhileIdle() .
Указанное пользователем действие, которое должно произойти через определенное время: Используйте неточный будильник. В частности, вызовите set() .
Указанное пользователем действие, которое может произойти в течение указанного временного окна: Используйте неточный сигнал. В частности, вызовите setWindow() . Обратите внимание: если ваше приложение предназначено для Android 12 или более поздних версий, минимально допустимая продолжительность окна составляет 10 минут.

Способы установки точного будильника

Ваше приложение может устанавливать точные сигналы тревоги одним из следующих методов. Эти методы упорядочены таким образом, что те, что находятся ближе к концу списка, предназначены для решения более срочных задач, но требуют больше системных ресурсов.

setExact()

Включить будильник в практически точное время в будущем, если только не будут задействованы другие меры по экономии заряда батареи.

Используйте этот метод для установки точных будильников, если только работа вашего приложения не критична ко времени для пользователя.

setExactAndAllowWhileIdle()

Активируйте будильник в практически точное время в будущем, даже если действуют меры по экономии заряда батареи.

setAlarmClock()

Активируйте сигнал тревоги в точное время в будущем. Поскольку эти сигналы хорошо видны пользователям, система никогда не корректирует время их доставки. Система определяет эти сигналы как наиболее важные и при необходимости переходит в режим энергосбережения для их доставки.

Потребление системных ресурсов

Когда система активирует сигналы тревоги, заданные вашим приложением, устройство потребляет значительное количество ресурсов, например, расходует заряд батареи, особенно если оно находится в режиме энергосбережения. Более того, система не может легко группировать эти запросы для более эффективного использования ресурсов.

Настоятельно рекомендуется по возможности создавать неточные сигналы тревоги . Для выполнения более длительной работы запланируйте её с помощью WorkManager или JobScheduler из BroadcastReceiver вашего сигнала тревоги. Чтобы выполнить работу, пока устройство находится в режиме сна, создайте неточные сигналы тревоги с помощью setAndAllowWhileIdle() и запустите задание из этого сигнала тревоги.

Укажите точное разрешение на сигнализацию

Если ваше приложение предназначено для Android 12 или более поздней версии, вам необходимо получить специальный доступ к приложению «Будильники и напоминания». Для этого объявите разрешение SCHEDULE_EXACT_ALARM в файле манифеста вашего приложения, как показано в следующем фрагменте кода:

<manifest ...>
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

Если ваше приложение предназначено для Android 13 (уровень API 33) или выше, у вас есть возможность объявить разрешение SCHEDULE_EXACT_ALARM или USE_EXACT_ALARM .

<manifest ...>
    <uses-permission android:name="android.permission.USE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

Хотя разрешения SCHEDULE_EXACT_ALARM и USE_EXACT_ALARM предоставляют одни и те же возможности, они предоставляются по-разному и поддерживают разные сценарии использования. Ваше приложение должно использовать точные оповещения и объявлять разрешение SCHEDULE_EXACT_ALARM или USE_EXACT_ALARM только в том случае, если функция, взаимодействующая с пользователем, в вашем приложении требует точных по времени действий.

USE_EXACT_ALARM

Предоставляется автоматически
Не может быть отозвано пользователем
В соответствии с предстоящей политикой Google Play
Ограниченные варианты использования

SCHEDULE_EXACT_ALARM

Предоставлено пользователем
Более широкий набор вариантов использования
Приложения должны подтвердить, что разрешение не было отозвано.

Разрешение SCHEDULE_EXACT_ALARM не предоставляется заранее для новых установок приложений, предназначенных для Android 13 (уровень API 33) и выше. Если пользователь переносит данные приложения на устройство под управлением Android 14 с помощью операции резервного копирования и восстановления, разрешение SCHEDULE_EXACT_ALARM будет отклонено на новом устройстве. Однако, если существующее приложение уже имеет это разрешение, оно будет предоставлено заранее при обновлении устройства до Android 14.

Примечание : если точный будильник установлен с помощью объекта OnAlarmListener , например с помощью API setExact , разрешение SCHEDULE_EXACT_ALARM не требуется.

Использование разрешения `SCHEDULE_EXACT_ALARM`

Unlike USE_EXACT_ALARM , the SCHEDULE_EXACT_ALARM permission must be granted by the user. Both the user and the system can revoke the SCHEDULE_EXACT_ALARM permission.

Чтобы проверить, предоставлено ли вашему приложению разрешение, вызовите функцию canScheduleExactAlarms() перед установкой точного будильника. При отзыве разрешения SCHEDULE_EXACT_ALARM для вашего приложения оно останавливается, а все будущие точные будильники отменяются. Это также означает, что значение, возвращаемое функцией canScheduleExactAlarms() остаётся действительным на протяжении всего жизненного цикла вашего приложения.

When the SCHEDULE_EXACT_ALARMS permission is granted to your app, the system sends it the ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast. Your app should implement a broadcast receiver that does the following:

Подтверждает, что у вашего приложения всё ещё есть специальный доступ. Для этого вызовите canScheduleExactAlarms() . Эта проверка защищает ваше приложение от ситуации, когда пользователь предоставляет приложению разрешение, а затем практически сразу же отзывает его.
Перепланирует любые необходимые вашему приложению оповещения в зависимости от его текущего состояния. Эта логика должна быть аналогична той, которую ваше приложение выполняет при получении сообщения ACTION_BOOT_COMPLETED .

Попросите пользователей предоставить разрешение `SCHEDULE_EXACT_ALARM`

Эта опция называется «Разрешить установку будильников и напоминаний». — **Рисунок 1.** Специальная страница доступа к приложению «Будильник и напоминания» в настройках системы, где пользователи могут разрешить вашему приложению устанавливать точные будильники.

При необходимости вы можете направить пользователей на экран «Будильник или напоминания» в настройках системы, как показано на рисунке 1. Для этого выполните следующие действия:

В пользовательском интерфейсе вашего приложения объясните пользователю, почему вашему приложению необходимо планировать точные будильники.
Вызовите намерение, которое включает действие намерения ACTION_REQUEST_SCHEDULE_EXACT_ALARM .

Установить повторяющийся будильник

Повторяющиеся сигналы тревоги позволяют системе уведомлять ваше приложение по повторяющемуся графику.

Неправильно настроенный будильник может привести к разрядке батареи и существенной нагрузке на серверы. Поэтому в Android 4.4 (уровень API 19) и выше все повторяющиеся будильники являются неточными .

Повторяющийся сигнал тревоги имеет следующие характеристики:

Тип сигнала тревоги. Подробнее см. в разделе «Выбор типа сигнала тревоги» .
Время срабатывания. Если указанное вами время срабатывания уже прошло, будильник сработает немедленно.
Интервал срабатывания будильника. Например, раз в день, каждый час или каждые 5 минут.
Ожидаемое намерение, которое срабатывает при срабатывании будильника. При установке второго будильника с тем же ожидаемым намерением оно заменяет исходный будильник.

Чтобы отменить PendingIntent() , передайте FLAG_NO_CREATE в PendingIntent.getService() чтобы получить экземпляр намерения (если он существует), а затем передайте это намерение в AlarmManager.cancel()

Котлин

val alarmManager =
    context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager
val pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE)
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent)
}

Ява

AlarmManager alarmManager =
    (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE);
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent);
}

Выберите тип будильника

Одним из первых факторов, которые следует учитывать при использовании повторяющегося будильника, является его тип.

Существует два основных типа часов для будильников: «прошедшее реальное время» и «часы реального времени» (RTC). В качестве точки отсчёта для прошедшего реального времени используется «время с момента загрузки системы», а для часов реального времени — время UTC (по Гринвичу). Это означает, что прошедшее реальное время подходит для установки будильника на основе текущего времени (например, для будильника, срабатывающего каждые 30 секунд), поскольку оно не зависит от часового пояса или региональных настроек. Часы реального времени лучше подходят для будильников, зависящих от текущих региональных настроек.

У обоих типов будильников есть версия «пробуждения», которая активирует процессор устройства при выключенном экране. Это гарантирует срабатывание будильника в запланированное время. Это полезно, если ваше приложение зависит от времени. Например, если у него ограниченное время для выполнения определённой операции. Если вы не используете версию «пробуждения» для вашего типа будильника, все повторяющиеся будильники сработают, когда устройство снова проснётся.

Если вам нужно, чтобы будильник срабатывал с определённым интервалом (например, каждые полчаса), используйте один из вариантов срабатывания в режиме реального времени. В целом, это лучший выбор.

Если вам нужно, чтобы будильник срабатывал в определённое время суток, выберите один из типов будильника, основанных на реальном времени. Однако учтите, что такой подход может иметь некоторые недостатки. Приложение может быть некорректно адаптировано для других локалей, а изменение пользователем настроек времени на устройстве может привести к непредсказуемому поведению приложения. Использование будильника, основанного на реальном времени, также плохо масштабируется, как обсуждалось выше. Мы рекомендуем использовать будильник с прошедшим временем, если это возможно.

Вот список типов:

ELAPSED_REALTIME : активирует ожидающее намерение на основе времени, прошедшего с момента загрузки устройства, но не пробуждает его. Прошедшее время включает в себя всё время, в течение которого устройство находилось в спящем режиме.
ELAPSED_REALTIME_WAKEUP : Пробуждает устройство и запускает ожидающее намерение по истечении указанного времени с момента загрузки устройства.
RTC : запускает ожидающее намерение в указанное время, но не пробуждает устройство.
RTC_WAKEUP : Пробуждает устройство для выполнения ожидающего намерения в указанное время.

Примеры истекших сигналов тревоги в реальном времени

Вот несколько примеров использования ELAPSED_REALTIME_WAKEUP

Включите устройство, чтобы будильник сработал через 30 минут, а затем каждые 30 минут:

Котлин

// Hopefully your alarm will have a lower frequency than this!
alarmMgr?.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR,
        alarmIntent
)

Ява

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

Разбудите устройство, чтобы подать однократный (неповторяющийся) сигнал через одну минуту:

Котлин

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

alarmMgr?.set(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + 60 * 1000,
        alarmIntent
)

Ява

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

Примеры будильников в реальном времени

Вот несколько примеров использования RTC_WAKEUP .

Включите устройство, чтобы оно сработало примерно в 14:00, и повторяйте это один раз в день в одно и то же время:

Котлин

// Set the alarm to start at approximately 2:00 p.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 14)
}

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr?.setInexactRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        AlarmManager.INTERVAL_DAY,
        alarmIntent
)

Ява

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

Включите устройство, чтобы будильник сработал ровно в 8:30 утра и каждые 20 минут после этого:

Котлин

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

// Set the alarm to start at 8:30 a.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 8)
    set(Calendar.MINUTE, 30)
}

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr?.setRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        1000 * 60 * 20,
        alarmIntent
)

Ява

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);

Решите, насколько точным должен быть ваш будильник

As previously described, choosing the alarm type is often the first step in creating an alarm. A further distinction is how precise you need your alarm to be. For most apps, setInexactRepeating() is the right choice. When you use this method, Android synchronizes multiple inexact repeating alarms and fires them at the same time. This reduces the drain on the battery.

По возможности избегайте использования точных будильников. Однако в редких приложениях с жёсткими требованиями к времени вы можете установить точный будильник , вызвав setRepeating() .

С помощью setInexactRepeating() нельзя задать произвольный интервал, как с помощью setRepeating() . Необходимо использовать одну из констант интервала, например INTERVAL_FIFTEEN_MINUTES , INTERVAL_DAY и т. д. Полный список см. в разделе AlarmManager .

Отменить будильник

В зависимости от вашего приложения вам может потребоваться возможность отмены будильника. Чтобы отменить будильник, вызовите метод cancel() в диспетчере будильников, передав ему PendingIntent , который вы больше не хотите активировать. Например:

Котлин

// If the alarm has been set, cancel it.
alarmMgr?.cancel(alarmIntent)

Ява

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}

Включить будильник при перезапуске устройства

По умолчанию все оповещения отменяются при выключении устройства. Чтобы избежать этого, вы можете настроить приложение так, чтобы оно автоматически перезапускало повторяющийся будильник при перезагрузке устройства пользователем. Это гарантирует, что AlarmManager продолжит выполнять свою задачу, и пользователю не придётся вручную перезапускать будильник.

Вот шаги:

Установите разрешение RECEIVE_BOOT_COMPLETED в манифесте вашего приложения. Это позволит вашему приложению получать ACTION_BOOT_COMPLETED , который транслируется после завершения загрузки системы (это работает только в том случае, если приложение уже было запущено пользователем хотя бы один раз):
```
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
```

Реализуйте BroadcastReceiver для приема трансляции:

Котлин

class SampleBootReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == "android.intent.action.BOOT_COMPLETED") {
            // Set the alarm here.
        }
    }
}

Ява

public class SampleBootReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {
        if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
            // Set the alarm here.
        }
    }
}

Добавьте приемник в файл манифеста вашего приложения с фильтром намерений, который фильтрует действие ACTION_BOOT_COMPLETED :
```
<receiver android:name=".SampleBootReceiver"
        android:enabled="false">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED"></action>
    </intent-filter>
</receiver>
```
Обратите внимание, что в манифесте для приёмника загрузки задано значение android:enabled="false" . Это означает, что приёмник не будет вызываться, если приложение явно не включит его. Это предотвращает ненужный вызов приёмника загрузки. Вы можете включить приёмник (например, если пользователь устанавливает будильник) следующим образом:
Котлин
val receiver = ComponentName(context, SampleBootReceiver::class.java) context.packageManager.setComponentEnabledSetting( receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP )
Ява
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class); PackageManager pm = context.getPackageManager(); pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP);
После включения приёмника таким образом он останется включённым, даже если пользователь перезагрузит устройство. Другими словами, программное включение приёмника переопределяет настройку манифеста даже при перезагрузке. Приёмник останется включённым до тех пор, пока ваше приложение не отключит его. Вы можете отключить приёмник (например, если пользователь отменит будильник) следующим образом:
Котлин
val receiver = ComponentName(context, SampleBootReceiver::class.java) context.packageManager.setComponentEnabledSetting( receiver, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP )
Ява
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class); PackageManager pm = context.getPackageManager(); pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP);

Вызов будильников, пока устройство находится в спящем режиме

Устройства под управлением Android 6.0 (API уровня 23) поддерживают режим Doze , который помогает продлить время работы устройства от аккумулятора. Будильники не срабатывают, когда устройство находится в режиме Doze . Все запланированные будильники откладываются до выхода устройства из режима Doze. Если вам нужно завершить работу, даже когда устройство не используется, доступны несколько вариантов:

Установите точный будильник .
Используйте API WorkManager, предназначенный для выполнения фоновой работы. Вы можете указать системе, что она должна ускорить вашу работу, чтобы завершить её как можно скорее. Подробнее см. в статье «Планирование задач с помощью WorkManager».

Лучшие практики

Каждый ваш выбор при настройке повторяющегося будильника может повлиять на то, как ваше приложение использует (или злоупотребляет) системные ресурсы. Например, представьте себе популярное приложение, синхронизирующееся с сервером. Если синхронизация основана на времени, и каждый экземпляр приложения синхронизируется в 23:00, нагрузка на сервер может привести к высокой задержке или даже к отказу в обслуживании. Следуйте этим рекомендациям по использованию будильников:

Добавьте случайность (джиттер) к любым сетевым запросам, которые срабатывают в результате повторяющегося сигнала тревоги:
- Выполняйте любые локальные работы при срабатывании тревоги. «Локальная работа» означает всё, что не затрагивает сервер и не требует данных с сервера.
- В то же время запланируйте срабатывание будильника, содержащего сетевые запросы, на некоторый случайный период времени.
Сведите частоту срабатывания будильника к минимуму.
Не выводите устройство из спящего режима без необходимости (это поведение определяется типом будильника, как описано в разделе Выбор типа будильника ).
Не устанавливайте время срабатывания будильника точнее, чем необходимо.
Используйте setInexactRepeating() вместо setRepeating() . При использовании setInexactRepeating() Android синхронизирует повторяющиеся сигналы будильника из нескольких приложений и активирует их одновременно. Это сокращает общее количество пробуждений устройства системой, тем самым уменьшая расход заряда батареи. Начиная с Android 4.4 (API уровня 19), все повторяющиеся сигналы будильника являются неточными . Обратите внимание, что, хотя setInexactRepeating() и является улучшением по сравнению с setRepeating() , он всё ещё может перегрузить сервер, если все экземпляры приложения обращаются к нему примерно в одно и то же время. Поэтому для сетевых запросов добавьте некоторую случайность в сигналы будильника, как обсуждалось ранее.
По возможности не устанавливайте будильник в зависимости от времени суток.
Повторяющиеся сигналы тревоги, основанные на точном времени срабатывания, плохо масштабируются. По возможности используйте ELAPSED_REALTIME . Различные типы сигналов тревоги более подробно описаны в следующем разделе.

Расписание будильников

Установите неточный будильник

Подать сигнал тревоги через определенное время

Подать сигнал тревоги в течение определенного временного окна

Подавать повторяющийся сигнал тревоги примерно через равные промежутки времени

Установите точный будильник

Случаи использования, когда точные сигналы тревоги могут не требоваться

Способы установки точного будильника

Потребление системных ресурсов

Укажите точное разрешение на сигнализацию

Использование разрешения SCHEDULE_EXACT_ALARM

Попросите пользователей предоставить разрешение SCHEDULE_EXACT_ALARM

Установить повторяющийся будильник

Котлин

Ява

Выберите тип будильника

Примеры истекших сигналов тревоги в реальном времени

Котлин

Ява

Котлин

Ява

Примеры будильников в реальном времени

Котлин

Ява

Котлин

Ява

Решите, насколько точным должен быть ваш будильник

Отменить будильник

Котлин

Ява

Включить будильник при перезапуске устройства

Котлин

Ява

Котлин

Ява

Котлин

Ява

Вызов будильников, пока устройство находится в спящем режиме

Лучшие практики

Использование разрешения `SCHEDULE_EXACT_ALARM`

Попросите пользователей предоставить разрешение `SCHEDULE_EXACT_ALARM`