Android — Android NotificationManager+AlarmManager


Содержание

Android: как использовать AlarmManager

Мне нужно запустить блок кода через 20 минут после установки AlarmManager .

Может ли кто-нибудь показать мне пример кода о том, как использовать AlarmManager в Android?

Я играю с некоторым кодом в течение нескольких дней, и он просто не работает.

«Некоторые примеры кода» не так просто, когда дело доходит до AlarmManager .

Вот фрагмент, показывающий настройку AlarmManager :

В этом примере я использую setRepeating() . Если вам нужен сигнал с одним выстрелом, вы просто используете set() . Обязательно укажите время запуска будильника в той же временной базе, что и исходный параметр, в set() . В моем примере выше я использую AlarmManager.ELAPSED_REALTIME_WAKEUP , поэтому моя база времени SystemClock.elapsedRealtime() .

Есть несколько хороших примеров в коде примера Android.

Сначала вам нужен приемник, который может прослушивать ваш сигнал тревоги при его срабатывании. Добавьте в свой файл AndroidManifest.xml следующее:

Затем создайте следующий класс

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

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

Таким образом, у вас есть все в одном месте (не забудьте отредактировать AndroidManifest.xml )

Что вам нужно сделать, сначала создайте намерение, которое вам нужно запланировать. Затем получите ожидаемое действие этого намерения. Вы можете планировать мероприятия, услуги и трансляции. Чтобы запланировать действие, например MyActivity:

Отдайте этот ожидающий запрос alarmManager:

Теперь MyActivity будет запущен через 5 секунд после запуска приложения, независимо от того, остановите свое приложение или устройство в состоянии сна (из-за опции RTC_WAKEUP). Вы можете прочитать полный код примера Планирование действий, служб и трансляций #Android

Android Alarmmanager и уведомление

Следующий код не работает. Также попробуйте это вместо getapplicationcontext. Мне нужен намек:

И как я могу удалить уведомление после onclick?

ОБНОВЛЕНИЕ: Я решил ошибку. Но есть еще одна ошибка:

java android notifications alarmmanager

2 ответа

2 Решение user1756209 [2012-10-26 00:58:00]


Замените getSystemService на context.getSystemService!

0 jsmith [2012-10-23 18:03:00]

У BroadcastReceivers нет Контекста, поэтому вы не можете этого сделать.

Вы должны перенаправить намерение, которое вы получили в Службу или Деятельность, и этот класс может обработать уведомление.

Andro > Вопрос задан: 6 лет назад Последняя активность: 6 лет назад

Я пытаюсь создать приложение напоминания, которое выскакивает напоминание в строке состояния. Как я понимаю, Android NotificationManager — это стандартный инструмент, который используется для планирования уведомлений, однако BootService необходим для того, чтобы перепланировать уведомления, поскольку запланированные события не сохраняются при загрузке.

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

Проблема, с которой я сталкиваюсь, заключается в том, что напоминание работает правильно с первого раза, однако, похоже, оно перепланирует себя и снова появляется в случайное время по какой-то причине. Должен ли я запускать другое действие, а не то, которое устанавливает BootAlarmService?

ОБНОВИТЬ: Так что я думаю, что нашел некоторые подсказки с logcat. Судя по всему, Служба падает и перезапускается, что приводит к сбросу Уведомления. Есть идеи, почему это так?

ОБНОВЛЕНИЕ II: код изменен на рабочую модель

Программируем будильник или использование AlarmManager в Android

При разработке приложения порой бывает необходимо выполнять какие-то действия в будущем. Например, вы хотите создать будильник или периодически отправлять данные на свой сайт в строго определенное время. Для решения подобных задач в Android используется классAlarmManager, который позволяет выполнять код в требуемый момент времени, даже если ваше приложение не запущено. То-есть AlarmManager — аналог corn в Linux или планировщика задач Windows. Вы говорите, что такой-то кусок кода должен выполниться тогда-то и AlarmManager обеспечивает запуск кода. В англоязычный литературе таймер, который выполняет код в требуемый момент времени обозначается терминомalarm. Давайте в рамках данной статьи называть этот таймербудильником, чтобы отделить это понятие от таймера.

Несколько слов о классе AlarmManager

Фактически класс AlarmManager обеспечивает доступ к сервису планировки задач Android. Для получения объекта этого класса нужно вызвать методContext.getSystemService(Context.ALARM_SERVICE).AlarmManagerрегистрирует в системе интент и когда наступает обозначенное время, AlarmManager запускает этот интент. Если момент вызова приложение закрыто, то оно будет вновь запущено. AlarmManager нужно использовать только в случае, если код должен быть выполнен даже при закрытом приложении, во всех других случаях рекомендуется использовать классHandler.

Класс AlarmManager довольно прост. В нашем распоряжении шесть методов:

    vo >
    ЗдесьPendingIntent— класс, который представляет интент и связанное с его выполнением действие. Передавая PendingIntent другому приложению Вы тем самым даете ему право запускать кусок кода из своей программы.

В качестве типа будильника (параметрtype) может быть передано одно из значений ELAPSED_REALTIME, ELAPSED_REALTIME_WAKEUP, RTC и RTC_WAKEUP. ELAPSED_REALTIME и ELAPSED_REALTIME_WAKEUP — время задается с момента загрузки устройства, а RTC и RTC_WAKEUP — системное время в UTC. Для ELAPSED_REALTIME и RTC если устройство находится в спящем режиме в момент срабатывания будильника, то связанный с ним интент будет вызван позже, когда пользователь выведет устройство из спящего режима. Для ELAPSED_REALTIME_WAKEUP и RTC_WAKEUP если устройство находится в спящем режиме, оно немедленно пробуждается и вызывается интент.

Программируем приложение-будильник для Andro >Давайте в качестве примера разработаем приложение — будильник. При запуске программы пользователю будет показано окно с тремя кнопками. С их помощью пользователь сможет: установить будильник, который срабатывает один раз; будильник, который будет срабатывать периодически; а также удалить ранее установленные будильники.

Создадим новый проект в макет шаблона добавим три кнопки

КнопкаbtStartустанавливает повторяющийся будильник, кнопкаbtCancel— отменяет его. КнопкаbtOneTime— создает не повторяющийся будильник. Прямо в шаблоне мы указали методы, которые будут вызываться при нажатии на кнопки: startRepeatingTimer, cancelRepeatingTimer и onetimeTimer соответственно. Код этих методов будут приведен в классе Activity.

Для работы сAlarmManagerнапишем отдельный класс. В качестве базового класса используем BroadcastReciever. Наш класс будет управлять зарегистрированным с помощью AlarmManager интентом. Мы переопределим методonReceive(), который будет вызываться после получения интента. Внутри метод onReceive() мы должны попытаться получить связанные с интентом параметры. В своей программе мы будем использовать один параметр ONE_TIME, который позволяет определить, относится ли интент к однократно срабатывающему будильнику или нет. После того, как значение ONE_TIME получено, пользователю показывается соответствующее сообщение.

Также в этом классе определим методы setAlarm(), cancelAlarm() и onetimeTimer(). Конечно эти методы можно было определить и в другом месте, мы включили их в данный класс из соображения простоты примера.


  • Метод setAlarm() устанавливает повторяющийся будильник с помощью метода setRepeating(). Этому методу требуется четыре параметра: тип будильника, время запуска (устанавливаем текущий момент), интервал в миллисекундах, интент, который будет вызываться при срабатывании будильника.
  • Метод cancelAlarm() отменяет зарегистрированный ранее будильник с помощью вызова метода cancel(), которому перезается в качестве параметра интент. При совпадении этого параметра с зарегистрированным ранее интентом, произойдет удаление будильника.
  • Метод onetimeTimer() создает будильник, который срабатывает один раз. Делается с помощью метода set(), которому передается три параметра: тип будильника, время запуска, вызываемый интент.

Ниже приводится файл манифеста. Обратите внимание, для корректной работы программе необходимо дать разрешениеWAKE_LOCK, поскольку мы используем блокировку потока в методе onReceive(). Также тут мы регистрируем AlarmManagerBroadcastReceiver, как получатель широковещательных сообщений

Теперь давайте напишем класс, в котором реализуем обработчики кнопок. Здесь мы создадим экземпляр описанного выше класса AlarmManagerBroadcastReciever и будем вызывать методы setAlarm(), cancelAlarm() и setOnetime().

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

Scheduling Notifications on Android with WorkManager

A simpler guide to get you up to speed

EDIT: This story has been updated to be compatible with Work 2.1.0-alpha01 .

As I promised in my previous post, I’m back with a quick, no-nonsense guide to scheduling notifications on Android. If you haven’t, I strongly recommend you read the previous article before going into this one:

Scheduling notifications is a strange territory, and over the years there have been a number of tools that people used for it, such as AlarmManager , JobScheduler , Firebase JobDispatcher (for backwards compatibility), etc. They all mostly work, but they have certain issues and limitations, such as having notifications stop when the app is force closed or the device is restarted.

To resolve this mess, Google has released the WorkManager as part of their Architecture Components, and it’s super enjoyable to use! In this article I’ll show you a simple way of using it.

The absolute first thing you need to do is to add the Work Architecture component to your build.gradle as per these instructions:

There are three main steps to scheduling a notification:

1. Building the Worker >The first step is to extend the Worker >doWork() method of the Worker >Result .

In my example, we’re triggering a method that simply shows a notification, as per my previous gu >Result. success() .

2. Building the Work Request

The second step is to build the work request that will get passed to the WorkManager in the next step. We do this by using a OneTimeWorkRequest since we only need to trigger the notification once. Alternatively, we could use a PeriodicWorkRequest for recurring work.

In order to do this, we call the OneTimeWorkRequest.Builder and pass it the name of the custom >Constraints to prevent the work from running if the battery or storage are low, and so on.

We have used setInitialDelay to ensure the notification is triggered on the day of the event rather than immediately. This delay is calculated by a separate method which returns the amount of milliseconds between now and when the notification should trigger (at noon on the date of the event). Please note that this delay is not always accurate! Due to how modern Android works, your work can be delayed by a number of factors, so be aware of this for very time sensitive purposes.

We have used setInputData to pass the event >Data object as shown above.

Finally, we have used addTag to set a tag for this work type in order to be able to call WorkManager. getInstance().cancelAllWorkByTag (workTag); to remove all work of this type from the queue in order to prevent duplicates. Another way of doing this will be explained at the next step.

3. Enqueueing the Work Request


Now that we’ve created everything we need to schedule the work, we can just ask the WorkManager to queue it to the list of active tasks from the system:

At this point, the WorkManager will add the work to its queue, then determine when it can run and do the work as specified in the first step. And there you go, your notifications will now trigger on time, regardless of device restarts, app force closes, and without using a bulky service.

Please note that as of Work 2.1.0-alpha01 we need to use WorkManager.getInstance(context) instead of WorkManager.getInstance() , which is deprecated.

I also recommend reading Google’s gu >WorkManager :

AlarmManager некорректно работает на китайфонах, как решить данную проблему?

Нужно сделать неубиваемый сервис.

1. Создаешь сервис, который будет запускать AlarmManager
1.1 Класс сервиса:

1.2 Создаешь Receiver, на который будет ссылаться AlarmManager после выполнения:

1.3 Регистрируем Service и Receiver в Manifest:

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

Andro >

Я хотел бы реализовать отправку уведомлений пользователям с сервера с помощью AlarmManager в то время, когда пользователь предварительно настроил ранее. Код выглядит следующим образом:

Основная деятельность:

ParseService:

AlarmBroadcastManager

Manifest:

Вопрос:

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

Однако, если приложение вручную удаляется из недавнего списка задач, alarmManager и, следовательно, уведомление отменяется, и уведомление не получает.

У меня есть googled, и большинство решений должно вернуть START_STICKY в onStartCommand , чтобы зарегистрироваться в Manifest, но я пробовал без успеха.

Не могли бы вы помочь выяснить, в чем проблема? Почему уведомление не может быть перезагружено после того, как приложение вручную удалено из недавнего списка задач? Есть ли такой пример, что этот ParseService работает в заранее установленное время пользователя?


  • Вам необходимо сохранить зарегистрированные аварийные сигналы в локальной базе данных
  • Затем создайте получателя с завершенной загрузкой
    • В этом приемнике загрузите все аварийные сигналы и зарегистрируйте их снова
  • В классе AlarmBroadcastReceiver удалите этот сигнал тревоги из db

Вместо AlarmManager вы должны использовать GcmListenerService это будет уведомлять, даже ваше приложение будет удалено из диспетчера задач, GcmListenerService

Как показано ниже для тестирования. Добавление 30 секунд в текущее время и установка тревоги. В то же время убить приложение из недавней задачи для тестирования.

Вы можете запустить службу из PendingIntent. Это решит проблему, если пользователь очистит приложение от недавней задачи.

Как указано Hossam Alaa по ссылке, вы можете сделать это для загрузки. Также вам не нужен AsyncTask в IntentService. Он имеет рабочий поток.

Пример ParseService (Модифицируйте в соответствии с вашими потребностями, в настоящее время он будет ждать 5000 мс и инициировать уведомление).

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

Но я не уверен, что ваш манифест настроен правильно: будильник отправляет трансляцию в «AlarmBroadcastReceiver.class», и он будет реагировать, если приложение будет жить в определенный момент.

Я предлагаю транслировать настраиваемое действие с предупреждением и регистрировать его в приемнике.

Добавьте к получателю в манифест:

И используйте другое намерение для тревоги, например:

Andro > Anupam Chugh — 4 Comments

In this tutorial, we’ll be discussing AlarmManager and Broadcast Receiver and see how to trigger a Background Service using them in our Android Application.

Table of Contents

AlarmManager Broadcast Receiver Service

An AlarmManager is used to trigger some code at a specific time. It uses the Android SDK’s alarm service and runs independently of the application’s lifecycle.

To start an Alarm Manager you need to first get the instance from the System. Then pass the PendingIntent which would get executed at a future time that you specify.

There are different types of Alarm Manager that can be invoked:


  • setInExactAndRepeating – This doesn’t trigger the alarm at the exact time.
  • setExact – Setting an alarm manager using this ensures that the OS triggers the alarm at almost the exact time.
  • setExactAndAllowWhileIdle – This method came up with Android M. These types of alarms are allowed to get executed even in low power modes.

You need to be careful while using the Alarm Manager since they can consume battery if not handled properly.
Normally, an alarm manager cannot repeat before a minute. Also in low power mode, the duration can increase to up to 15 minutes.

Broadcast Receivers listen to system-wide and application events.
In order to trigger a Broadcast Receiver when the system is rebooted, you need to call ACTION_BOOT_COMPLETED .

In the following section, we’ll be showing how to use an Alarm Manager to trigger a Broadcast Receiver which ultimately calls a background service.

Project Structure

Android Alarm Broadcast Service Project

You need to register your Broadcast Receiver and Service in the AndroidManifest.xml as shown below:

In order to ensure that the Broadcast Receiver gets triggered properly on reboot in Android N and above, you need to set the directBootAware to be true and LOCKED_BOOT_COMPLETED

The code for the activity_main.xml layout is given below:

The code for the MainActivity.java is given below:

The code for the MyBroadcastReceiver.java file is given below:

We trigger the Service when the phone is rebooted. Inside the Service, we start a repeating alarm.
The code for the MyService.java class is given below:

The output of the above application in action is given below:

Android Alarm Broadcast Service Output

That brings an end to this tutorial. You can download the project from the link below:

Android — Android NotificationManager+AlarmManager

AlarmManager is a class in Android which is used access device alarm service. This allow your application to execute certain piece of code on a given scheduled time. This can run outside the lifetime of your application.

Once alarm is scheduled, it will invoke even when your application is not running or even your device is in sleep.

An alarm can wake your device, but this consumes more battery. So you have to be careful while scheduling an alarm task which executes more frequently.

There are two ways to register Android broadcastreceiver.

One is static way in which the broadcast receiver is registered in an android application via AndroidManifest.xml file.


Another way of registering the broadcast receiver is dynamic, which is done using Context.registerReceiver() method. Dynamically registered broadcast receivers can be unregistered using Context.unregisterReceiver() method.

Here is a sample of Alarm manager which perform action of alarm and show notification of alarm.

1. Create an Android project

2. My activity_main.xml file

PendingIntent -: A PendingIntent specifies an action to take in the future. It lets you pass a future Intent to another application and allow that application to execute that Intent as if it had the same permissions as your application, whether or not your application is still around when the Intent is eventually invoked. It is a token that you give to a foreign application which allows the foreign application to use your application’s permissions to execute a predefined piece of code

4. Create an AlarmReceiver class and this class extended by WakefulBroadcastReceiver class and you can also use BroadcastReceiver instead of WakefulBroadcastReceiver. This class takes care of creating and managing a partial wake lock for you; you must request the WAKE_LOCK permission to use it.

Add following code in AlarmReceiver class

Android — Android NotificationManager+AlarmManager

Scheduling and repeating alarms are generally used as a local reminder to notify user about some event.

Android provides AlarmManager to create and schedule alarms. AlarmManager class provides access to the system alarm service. This allow you to schedule your application to be run at some point in the future. When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running.

AlarmManager runs outside the lifetime of your application. Once an alarm is scheduled, it will invoke even when your application is not running or in sleep mode.

An scheduled alarm will execute unless it is stopped explicitly by calling cancel() method, or until device reboots. This means, you need to re-schedule them explicitly when device boot completes.

Alarms offer the following features:

  • Schedule alarms for a set time or interval.
  • Maintained by the OS, not your application, so alarms are triggered even if your application is not running, or the device is asleep.
  • Can be used to trigger periodic tasks (such as an hourly news update), even if your application is not running.
  • Your app does not use resources (such as timers or background services), since the OS manages the scheduling.

Alarms are not the best solution if you need a simple delay while your application is running, for example, a short delay for a UI event. For short delays, it’s easier and more efficient to use the postAtTime() and postDelayed() methods of a Handler.

Alarm have three properties, as follows:

  • Alarm type (see in the following list).
  • Trigger time (if the time has already passed, the alarm is triggered immediately).
  • Pending Intent.

A repeating alarm has the same three properties, plus an Interval:

  • Alarm type (see in the following list).
  • Trigger time (if the time has already passed, it triggers immediately).
  • Interval.
  • Pending Intent.


There are four alarm types:

  • RTC (Real Time Clock). The alarm times are referenced to UTC time. This does not wake the device. Fires the pending intent at a specified time. If the device is asleep, it will not be delivered until the next time the device wakes up.
  • RTC_WAKEUP. The alarm times are referenced to UTC time and will wake the device to trigger if it is asleep. Fires the pending intent at a specified time, waking up the device if asleep.
  • ELAPSED_REALTIME. This is based on the time elapsed since the device boot. This does not wake the device. It is better for time interval alarms-such as every 30 minutes. Fires the pending intent after the specified length of time since device boot. If the device is asleep, it fires when the device is next awake.
  • ELAPSED_REALTIME_WAKEUP. This is based on the time elapsed since the device boot. This wakes the device if it is sleeping. Fires the pending intent after the specified length of time since device boot. It wakes up the device if it is asleep.

RTC is most commonly used for setting alarm service in Android.

If you choose a wake-up alarm type, Android will wake the device from sleep but will not keep the device awake for you. You must obtain a WakeLock from PowerManager while doing your background work from a wake-up event. Otherwise, Android is likely to put the device back to sleep quickly, which will halt what you may be doing.

Thera are some methods which are used to schedule alarms. These methods are based on exact, inexact time of execution and repeating or single execution.

  • set(int type, long triggerAtMillis, PendingIntent operation). Schedules the alarm and if there is already an alarm by the intent then previous one will be canceled. It allows executing only one time.
  • setExact(int type, long triggerAtMillis, PendingIntent operation). It behaves same as set() but it does not allow OS to adjust time. The alarm will fire on exact time.
  • setRepeating(int type, long triggerAtMillis, long intervalMillis, PendingIntent operation). It behaves same as set() but repeats for the given interval of time.
  • setInexactRepeating(int type, long triggerAtMillis, long intervalMillis, PendingIntent operation). Same as setRepeating() but the executing time will not be exact.
  • setWindow(int type, long windowStartMillis, long windowLengthMillis, PendingIntent operation). Executes within a given window of time and works same as set() . It can be used for strict ordering of execution in case of multiple alarms.

After android API 19 (KitKat) all the alarms are inexact, this is done to save battery life and disable multiple wakeups. By doing so all the alarms are bundled to its near about time and triggered at once. There are new APIs to support applications which need strict delivery guarantees; see setWindow() and setExact() . Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

The following recipe will demonstrate how to create alarms with AlarmManager .

Setting an alarm requires a Pending Intent, which Android sends when the alarm is triggered. This intent can point to any system component, such as a BroadcastReceiver or Service , that can be executed when the alarm triggers. Therefore, we need to set up a Broadcast Receiving to capture the alarm intent. Our UI will consist of just a simple button to set the alarm. To start, open the Android Studio and follow these steps:

Open activity_main.xml and add the following button:

Create a new Java class called AlarmBroadcastReceiver using the following code:

Open ActivityMain.java and add the method for the button click:

Creating the alarm is done with this line of code:

Here’s the method signature:

To set the alarm, we create a Pending Intent with our previously defined alarm action:

This is an arbitrary string and could be anything we want, but it needs to be unique, so we prepend our package name. We check for this action in the Broadcast Receiver’s onReceive() callback.

If you click the Set Alarm button and wait for two minutes, you will see the Toast when the alarm triggers. If you are too impatient to wait and click the Set Alarm button again before the first alarm is triggered, you wouldn’t get two alarms. Instead, the OS will replace the first alarm with the new alarm, since they both use the same Pending Intent. If you need multiple alarms, you need to create different Pending Intents, such as using different Actions.

If you want to cancel the alarm, call the cancel() method by passing the same Pending Intent you have used to create the alarm. If we continue with our recipe, this is how it would look:

If you want to create a repeating alarm, use the setRepeating() method. The signature is similar to the set() method, but with an interval . This is shown as follows:

For the Interval , you can specify the interval time in milliseconds or use one of the predefined AlarmManager constants:


  • INTERVAL_DAY
  • INTERVAL_FIFTEEN_MINUTES
  • INTERVAL_HALF_DAY
  • INTERVAL_HALF_HOUR
  • INTERVAL_HOUR

Let’s write a very basic service that will simply display the current time as a Toast every time it is triggered.

That service must be registered in the AndroidManifest.xml with a tag. Otherwise, AlarmManager which is external to your application will not be aware of how to trigger it.

Below is layout to control our AlarmService .

Following is the Activity to register/unregister alarm.

As of Android 5.1 (API version 22) there is a minimum period of 1 minute for repeating alarms. If you need to do work within one minute, just set the alarm directly, then set the next one from that alarm’s handler, etc. If you need to do work within 5 seconds (for example), post it to a Handler instead of using the AlarmManager .

The sample activity presents two buttons: one to begin firing regular alarms, and the other to cancel them. The operation to trigger is referenced by a PendingIntent , which will be used to both set and cancel the alarms. We create an intent referencing the service directly, and then we wrap that intent inside a PendingIntent obtained with getService() .

The alarm in the example is registered to trigger 1 minute after the button is pressed, and then every 1 minute after that. Every 1 minute, a Toast will come onscreen with the current time value, even if the application is no longer running or in front of the user. When the user displays the activity and presses the Stop button, any pending alarms matching our PendingIntent are immediately canceled and will stop the flow of Toast s.

What if we wanted to schedule an alarm to occur at a specific time? Perhaps exactly at 14:00? Setting AlarmManager with some slightly different parameters could accomplish this.

This example uses an alarm that is referenced to real time. A determination is made whether the next occurrence of 14:00 will be today or tomorrow, and that value is returned as the trigger time for the alarm.

Starting in Android 4.4, the AlarmManager defaults all alarms to be inexact, meaning there is a small window within which they will trigger. Along with this new behavior, the setExact() API method was added to allow developers to declare that the following alarm cannot fall within an inexact window. Prior to 4.4, simply calling set() with the appropriate start time was sufficient.

Setting alarms in Android API Level 23 and above

If our application targets an API level below 19 (KitKat), scheduled alarms will run exactly at the alarm time. For applications targeting KitKat or later, the schedule is considered inexact and the system may re-order or group alarms to minimize wake-ups and save battery.

After API Level 23, the Android Development team went a little further and Doze mode was introduced on the Android System to reduce battery consumption when the device is unplugged from the power adapter, motionless, and not used by the user for a long period of time.

The Doze system will try to decrease the device’s wake-up frequency deferring background jobs, network updates, syncs, and our precious alarm until the device exits Doze mode or a recurring maintenance window runs to execute pending jobs, certain alarms, or synchronization with the network. After the maintenance window finishes, the device would enter Doze mode again if it was not used in the meantime:

Doze mode is likely to impact your application and will defer your alarms until a maintenance window comes in, unless you use the methods setAndAllowWhileIdle() and setExactAndAllowWhileIdle() to allow the execution of your alarms in a deep idle state.

Moreover, the number of times that the Doze Mode maintenance window runs will be less frequent in cases of long-term inactivity, so the impact of this new mechanism on our scheduling will increase, hence causing more unpredictable jitters at the alarm time.

During the doze mode the applications are also not allowed to access the network, the WakeLocks are ignored and Wi-Fi scans are not executed.

If we need precision scheduling and you are targeting Marshmallow or later, we shall use the new setExactAndAllowWhileIdle() method introduced at API level 23:

The Android system has protection that prevents abuse for exact alarms that fire off too frequently. AlarmManager only wakes up the device and dispatches one alarm per minute, and in low power mode it can be as low as one every 15 mins.

If your application targets a version between KitKat (API Level 19) and Marshmallow (API Level 23), the setExact method is enough for timing precision:


But we’ll need to check that the methods exist before we try to call it; otherwise, our app will crash when run under earlier API levels. Lets sketch out our new exact alarm code:

This will deliver our alarm at exactly the specified time on all platforms.

Don’t forget that you should only use exact scheduling when you really need it, for example, to deliver alerts to the user at a specific time. For most other cases, allowing the system to adjust our schedule a little to preserve battery life is usually acceptable.

Android Marshmallow API Level 23 also comes with the setAndAllowWhileIdle function, which allows us to create an alarm to sound in Doze mode, but with less exactness compared to setExactAndAllowWhileIdle() .

The system will try to batch these kinds of alarm across the entire system, minimizing the number of times the device wakes up, and hence reducing the energy consumption of the system. Here is the code to create an alarm that triggers, even in Doze mode, 10 hours from now:

In order to test your application’s behavior in doze mode, the Android SDK team added some new commands to the dumpsys tool to manually change the device’s power state from the command line.

It is also important to remember that Doze mode requires that your device is unplugged from the charger. To force the device to a state where it is disconnected from the charger, we should run the following command on a command line with access to SDK Tools:

Then, to enter idle mode, we should turn off the screen and run the following commands:

After the device is put in idle mode, we can enable the maintenance window by running the following command:

If we run the same step again the device goes back to an idle state; however, if we want to go back to an active state, we should run the next command:

With these handy commands we are able to verify that the alarm sounds even in deep idle states.

Re-starting Alarm Service on device reboot

As discussed earlier, once an alarm service is started, it execute until it is explicitly stopped or until device reboots. This means that, if your device is restarted then your alarm is stopped. To avoid such situation, you have to restart your alarm service as soon as device boot completes. Below code snippet will help you to start alarm service once device reboots.

To start your alarm on device reboot, you have to register your above declared DeviceBootReciever class in your application manifest. This also need android.permission.RECEIVE_BOOT_COMPLETED .

How to check that alarm has been scheduled already or not?

Create an equivalent PendingIntent which you used with setRepeating() with PendingIntent.FLAG_NO_CREATE flag.

Intent intent = new Intent(context, W >

While using PendingIntent.FLAG_NO_CREATE , if the described PendingIntent does not already exists, it simply return null .

How to get WakeLock

WAKE_LOCK permission is required because the wake lock is being used while processing in onReceive() method present in BroadcastReceiver class.

Example of WakeLock for BroadcastReceiver .

List all alarms in device

You can know the alarm has been set and when are they going to alarmed and interval. Also how many times this alarm has been invoked.

AlarmManager is a great candidate for scheduling if an application needs to perform a local event at an exact time or inexact interval. Alarm clock or reminder applications are great examples for AlarmManager usage. However, the documentation discourages using AlarmManager for scheduling network-related tasks. For this tasks you can use JobScheduler which is an API for scheduling various types of jobs against the framework that will be executed in your application’s own process.

Цукерберг рекомендует:  Продвижение - Подработка в SEO
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих