I am trying to receive a date change event but suppose the cpu is off will the system send the broadcast and will i be able to receive the broadcast in WakefulBroadcastReceiver and do the work?
The CPU is never totally off. And WakefulBroadcastReciever will just ensure that when an intent is received, the device stays awake until the operation performed in the receiver is finished.
From the documentation of WakefulBroadcastReceiver:
Helper for the common pattern of implementing a BroadcastReceiver that
receives a device wakeup event and then passes the work off to a
Service, while ensuring that the device does not go back to sleep
during the transition.
So it receives a device wakeup event, but doesn't trigger it.
It is the responsibility of the sender to ensure that the broadcast is received properly. You can use AlarmManager for this purpose. Here is a tutorial.
Related
I'm developing an app that needs to receive GCM notifications (and send info to the server) at any time, so the device should keep awake to receive it, even when screen is turned off for a long period.
I'm using a WakefulBroadcastReceiver, which should ensure the device holds a wake lock to receive the Notifications at any time (as I could understand, if I'm mistaken, please correct me)
But I'm not calling an Intent Service (as instructed in the docs), instead I'm performing the work in the very Broadcast Receiver onReceive method:
public class GCMReceive extends WakefulBroadcastReceiver {
#Override
public void onReceive(final Context context, Intent intent) {
/* Do my work */
}
}
It works fine, except when the device is inactive for a long time, then it stops receiving the notifications. Am I missing something here? Does the WakefulBroadcastReceiver requires the Intent service in order to hold a wake lock correctly?
instead I'm performing the work in the very Broadcast Receiver onReceive method
You are welcome to use a regular BroadcastReceiver, then. WakefulBroadcastReceiver is doing you no good. However, unless that work is less than a few milliseconds, you really should have an IntentService do the work.
Does the WakefulBroadcastReceiver requires the Intent service in order to hold a wake lock correctly?
WakefulBroadcastReceiver does not acquire the WakeLock until you call startWakefulService().
so the device should keep awake to receive it
No, your device may be sleeping when it receives the notification.
WakefulBroadcastReceiver, which should ensure the device holds a wake
lock to receive the Notifications at any time
No, WakefulBroadcastReceiver is not created for that purpose actually you misunderstand it. Your CPU falls sleep after being idle for a while. when a notification receives, it wakes up and runs onRecieve method of your BroadcastReceiver. Now consider you want to do a lot of work in onRecieve method, because it is running on the main thread you will get ANR error, so people usually creating an intentService and do their works on a worker thread which the service provides by default. Now you are doing a lot of work on a worker thread, so there is a possibility that the CPU goes sleep because you do not create any lock on the CPU, so you have to take a lock and make the CPU keep awake. In order to do that and in order to make it easy for developers android team create WakefulBroadcastReceiver.
then it stops receiving the notifications.
you have made some mistakes, because receiving notifications dose not despond on the state of CPU.(If you define the receiver in your manifest).
I am working with Android API especially Alarms, IntentService and notifications. I am using AlarmManager to schedule a periodic IntentService which might or might not fire notifications.
My questions is What happens when the device is in sleep mode?
Alarm will not fire and thus IntentService will not run at all. I am not sure if this will be the case.Will it make a difference if I make it a WakefulIntentService? I believe wake locks are needed to ensure the service keeps running after the BroadCastReciever returns. However, in this case there is no broadcast reciever.
Alarm and IntentService will run, but any notification will not have any impact since the device is sleeping. In this case, do I have to explicitly get a wakelock from PowerManager to fire notification ?
What happens when the device is in sleep mode?
That depends upon your type of alarm and the component your PendingIntent is to invoke.
If your alarm type ends in _WAKEUP, and you are using a broadcast PendingIntent, the device will wake up and remain awake through the call to onReceive() of the BroadcastReceiver. Once onReceive() returns, the device can fall asleep again. This is why WakefulIntentService and WakefulBroadcastRecevier were created -- to offer tested patterns for how to pass control to an IntentService and keep the device awake while the service completes its work.
If your alarm type ends in _WAKEUP and you are not using a broadcast PendingIntent, as the saying goes, your mileage may vary. You may not get control before the device falls back asleep. This is not a recommended pattern.
If your alarm types does not end in _WAKEUP, the device will not wake up due to your alarm.
With respect to the Notification, given the nature of the API, one hopes that it is the OS' responsibility to keep the device awake long enough for the ringtone or vibration pattern to play, as we do not know the precise instant when the Notification appears, nor do we know whether the ringtone will play (e.g., device is on silent mode).
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)?
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.
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.
Im confused with Service and Broadcast receiver.what is the relationship between these two?why we have to call broadcast receiver when we start a service.Can anyone kindly explain the concept between these two elements
You don't have to register a BroadcastRecevier when you start a Service. That is, even if you don't register a BroadcastReceiver, our Service will work as expected. There is no must have dependency between the two.
As explained by Gridtestmail, a Service is a process you want to run in the background, without having an interface to the user.
A BroadcastReceiver is registered, when you want to be notified about certain events happening - for example, discovering a new bluetooth device or receiving an incoming call.
If you register a BroadcastReceiver for receiving incoming calls , then your Receiver's onReceive() method is called whenever there is an incoming all, so you can process it.
Similarly, for other event detection stuff.
I hope the concept is clear to you now.
Service: If you want to do something in background , this will be running always in background even if the application closed. You can create this in separate process and also you can give your service to other app if you want. Downloading any content or Music is good example
Broadcast Reciever: Usually system will send some info which can be recieved by your app if you would wish to ,by registering. And you can do something what you want when that thing happens by using onReceive method. Example is the system will send BroadcastReceiver when new sms arrives or Booting done
Example : Service and BroadcastReceiver
I'm trying to figure out if a system event broadcast is broadcasted
using ordered broadcast or normal..
The event is EVENT_REMINDER and in the source for the calendarprovider
i noticed it sets up a alarmmanager to sent the broadcast.
I can't find how the alarmmanager sends it.
My guess would be as a normal broadcast ,
But while i was trying some things i noticed i could delay the
system's notification (tried up to 10 sec) by building a sleep in my
broadcastreceiver.
This would indicate that they are handled ordered , and the systems
receiver is only called when mine has finished.
But can i be sure of this behavour?? (in all 1.5> sdk versions)
the docs state that in some cases normal broadcasts are also handled
ordered..due to spare of resources.
All thoughts on this are welcome....
Thanks , arnold
You can check the isOrderedBroadcast flag in the BroadcastReceiver.