6

I have a broadcastreceiver called by an Alarm (scheduled with AlarmManager). In this receiver I'm only querying a register from the database, and launching a notification. I readed that a wake lock is needed when a service or an activity is started from a broadcast receiver, but, do I need a wake lock if I only want to show a notificacion (in the notification panel)?

Sergio Viudes
  • 2,714
  • 5
  • 26
  • 44

2 Answers2

17

In this receiver I'm only querying a register from the database, and launching a notification.

Do not do database I/O on the main application thread.

I readed that a wake lock is needed when a service or an activity is started from a broadcast receiver, but, do I need a wake lock if I only want to show a notificacion (in the notification panel)?

In general, no, you would not need a WakeLock from a BroadcastReceiver, even one that is invoked via a _WAKEUP alarm. AlarmManager guarantees in this case that it will keep the device awake using its own WakeLock.

However, again, in this case, you really should not be doing database I/O on the main application thread, and onReceive() is called on the main application thread. The proper pattern here is that you move your "querying a register from the database, and launching a notification" to an IntentService, started by your BroadcastReceiver, so that the work is done on a background thread. This will require a WakeLock, as you are now doing work outside of onReceive(). I have a WakefulIntentService that manages the WakeLock for you, if you wish to use it.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks! You answered all my questions about it :) I'll take a look at your WakefulIntentService to do all the work in an IntentService, and using a WakeLock. – Sergio Viudes Mar 20 '13 at 13:07
  • correct me if i'm wrong, but i think there is a chance that the device goes back to sleep while the BroadCastReceiver's onReceive() has finished, but your WakefulIntentService isn't started yet or hasn't acquired a wakelock yet, therefore i'd suggest to simply use a WakefulBroadcastReceiver (was added to the support library after the accepted answer): http://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html – Suau Jul 27 '13 at 18:57
  • @Su-AuHwang: "correct me if i'm wrong" -- you are wrong. `WakefulIntentService` is specifically designed for this scenario. "therefore i'd suggest to simply use a WakefulBroadcastReceiver" -- there are pros and cons for each approach; there is nothing intrinsically wrong with either of them. – CommonsWare Jul 27 '13 at 19:10
  • @CommonsWare, shouldnt WAKE_LOCK be required in every case when i start a service? Why only in some special cases? The CPU can go to sleep in any case. – Diffy May 12 '15 at 13:51
  • @Diffy: "shouldnt WAKE_LOCK be required in every case when i start a service?" -- only if you need the CPU to stay awake. "The CPU can go to sleep in any case" -- correct. Not every service needs the CPU to stay awake. And since keeping the CPU awake drains the battery, causing users to consider attacking offending developers with torches and pitchforks, we only use a `WakeLock` when **absolutely required**. – CommonsWare May 12 '15 at 14:11
  • @CommonsWare, how can a task run without using CPU. For example, downloading anything in service, or playing a song in the background? Everything will require CPU. – Diffy May 12 '15 at 14:44
  • @Diffy: "Everything will require CPU" -- of course not. There are any number of situations where a service is needed, but the work does not need to be performed continuously. `InputMethodService`, `AccessibilityService`, `PrintService`, `RemoteViewsService`, `SpellCheckerService`, `TextToSpeechService`, etc. do not need to keep the CPU on all the time. In some cases, the framework will manage the `WakeLock` for you (e.g., `JobService`). If you have further concerns in this are, ask a fresh Stack Overflow question. – CommonsWare May 12 '15 at 14:51
  • @CommonsWare in your implementation here https://goo.gl/6LCZSM , especially the OnAlarmReceiver class , you have extended a plain BroadcastReceiver instead of a Wakeful one. I also see that your WakefulIntentService.java class manually acquires and releases the lock from the PowerManager. lets say instead of this, I make a BroadcastReciever that extends from the Wakeful one without all the PowerManager boilerplate code, would that be equivalent to your implementation? Ever since I saw your implementation answer at a couple of places on stackoverflow :) I was wondering if they are same – PirateApp Nov 27 '15 at 08:47
  • @PirateApp: "you have extended a plain BroadcastReceiver instead of a Wakeful one" -- correct. First, that demo predates `WakefulBroadcastReceiver`. Second, you either use `WakefulBroadcastReceiver` *or* `WakefulIntentService`, not both. "would that be equivalent to your implementation?" -- `WakefulBroadcastReceiver` and `WakefulIntentService` are designed to address the same problem, if that's what you mean. – CommonsWare Nov 27 '15 at 13:05
  • @CommonsWare thanks for the clarification Mr Mark Murphy :) I have read your books, you truly are a colossal programmer – PirateApp Nov 30 '15 at 02:55
-1

Yes, it is necessary. I remember that in the Kernel level, the CPU will be kept running for about 5 seconds. So if you cannot finishing send your notification within 5 seconds, you have to grasp a wake lock. And release it after you finished your work.

Robin
  • 10,052
  • 6
  • 31
  • 52