My app needs to grab some data from the web at a specific time each day. So I use an AlarmManager to schedule the task and that works ok.
But when looking at various examples there seems to be two ways to deal with the AlarmManager when it comes to the pending intent.
One uses PendingIntent.getBroadcast() to call a broadcast receiver when the alarm goes off and inside that receiver the service to do the real work is started.
Another approach is to use PendingIntent.getService() and call the service directly when that alarm goes off.
Can someone explain to me the difference between the two approaches so I can decide on which one to rely?
EDIT: One more question is where to acquire the wake lock when using getService()?
For example, when using a BroadcastReceiver I have the following line in onReceive():
WakeReminderIntentService.acquireStaticLock(context);
How should I acquire the wake lock if I instead call the service directly like:
PendingIntent pi = PendingIntent.getService(this, 0, new Intent(this, OnAlarmReceiver.class), PendingIntent.FLAG_UPDATE_CURRENT);
Should I simply acquire it from within the service instead?
One uses PendingIntent.getBroadcast() to call a broadcast receiver when the alarm goes off and inside that receiver the service to do the real work is started.
it has one more step in starting service than
Another approach is to use PendingIntent.getService() and call the service directly when that alarm goes off.
then you should use the second approach as it is reducing your one step in execution..
Reading your edit I presume you found out yourself: If you want to make sure that your service is started when using AlarmManager, you better take the detour of first sending to a receiver and acquiring a wake lock there.
Otherwise it is possible that the phone will sleep before the requested service is launched.
That's what the javadoc of AlarmManager says and I also read it in post by Google engineer.
So now for your edit: When to acquire the lock?
The whole point of using the receiver is to acquire the lock within the onReceive() method of the receiver, because Android will not fall asleep during the execution of this method.
For an example see this question.
Related
I am having a look at the sample code from Google team for Android which is WakefulBroadcastReceiver
My question is is there a specific reason to have this mechanism acquire/release in BroadcastReceiver instead of putting this inside the Service itself. If yes what is it
?
It's very useful for something like alarms (see AlarmManager) or other types of PendingIntent use cases. With alarms send to BroadcastReceivers, the alarm manager mechanism ensures that the system will wake long enough to deliver the broadcast Intent (e.g. run the onReceive() method) to BroadcastReceivers only.
If you were to use a PendingIntent for a Service in this case, the Service would get "started" from an API perspective, but would not necessarily run because the system could go right back to sleep. Using a WakefulBroadcastReceiver, you could instead have the alarm trigger it, take the wake lock and start your Service. The Service would then get an opportunity to run and would ultimately need to release the wake lock so the system could go back to sleep.
The documentation for AlarmManager seems to imply (but does not outright explicitly require) that the PendingIntent you pass in to any of the set() methods should be of the type BroadcastReceiver, but I tested passing in other component types (like an IntentService) and it seemed to work fine.
Is it safe to use non-BroadcastReceiver Intents with AlarmManager?
Yes, and it has always worked, but I suspect not in the way that you're thinking. You can use any PendingIntent with an alarm; this could indeed be an activity or service PendingIntent. If it's a service PendingIntent, then the OS will call startService() for you when the alarm fires. The hidden catch is about the behavior of wakeup alarms.
When any alarm fires, the OS holds a wakelock on the sender's behalf for as long as it takes to deliver the PendingIntent, at which point the wakelock is released and the device is allowed to go back to sleep. The exact meaning of "as long as it takes to deliver" depends on which kind of PendingIntent is being used.
Broadcast delivery is essentially treated as synchronous: the wakelock is held by the Alarm Manager until the recipient's onReceive() callback returns. This gives you a hard guarantee that whatever processing you want to do in onReceive() is guaranteed to proceed without the device sleeping.
However, activity and service PendingIntent delivery does not wait for the recipient in the same way. With those kinds of alarm PendingIntents, the device remains awake long enough to begin the process of starting the target activity or service, but then it can (and does) go back to sleep immediately after that launch has begun, before the target code actually has a chance to run. In practice this means that with a service PendingIntent, even if the alarm is a wakeup alarm, the service will often not actually execute until the device as a whole is woken up normally, e.g. the next time the user turns on the screen manually.
Sometimes this is okay, if your code doesn't actually care that even though the alarm fired at 3am, the service didn't start running until 7am when the alarm clock went off and lit up the phone for an extended period. More often, though, what apps need to do is use a broadcast alarm, then in their onReceive() -- knowing that the device will sleep as soon as they return -- acquire their own wakelock and start up the service under that wakelock, etc.
There is a terrific support library class called WakefulBroadcastReceiver that encapsulates this alarm-wakelock-service dance and makes it both easy and bulletproof; it's https://developer.android.com/reference/android/support/v4/content/WakefulBroadcastReceiver.html. Use that if you ever want to start a service in response to a wakeup alarm.
I'm developing a little Android app, that needs to run a background process, used to start a remote connection periodically (for example, to check if there is new data on the server). This process obviously needs to work also if the application activity is not running at the moment.
As I can see in documentation, there are two types of approach to develop a scheduled background process in Android, working also when the application is closed.
Services
Alarms
The first one is not so good for my requirementes, because it can be killed by OS in case of low memory, so it is useless for me. startForeground() is not so good because I want the process is silent.
Alarm is ok, because it can't be killed by the OS, so it can work indefinitely. But... If I schedule an Intent with the AlarmManager, how can I preserve a reference to the Intent, surviving at application restart?
For example, if I want to cancel, or reschedule the Alarm, I need the reference to the initial Intent to cancel it thorugh the "AlarmManager.cancel(Intent i)" method. But if the application was restarted by the user, how can I obtain a reference to the initial Intent that was used to start the alarm?
Is there another way to stop an alarm if the launching application was restarted?
about alarms, you can cancel using the intent characteristics, so you don't need a reference to the original intent. In any case, the alarms mechanism still need you to run something on a service.
In any case, you missed another possible solution: SyncAdapter. Its purpose is to sync with servers, but you can do whatever you wish in the code, and it's unlikely the OS will kill it, as opposed to the other solutions you've mentioned.
Sadly even now it lacks on documentation and samples, but I think it can fulfill your needs. Here's what I've found
yes, note that cancel is looking for a PendingIntent, not an Intent per se.
so
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, R.string.some_string, new Intent(this, InitialIntent.class), 0);
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
alarmManager.cancel(pendingIntent);
gets you where you want to be.
note that I'm not getString'ing that string, that's becasue I want a unique Id/request code for this intent that I'm not going to screw up copypasting; I reference the same number when creating the alarm in InititalIntent.
This question was just answered, here:
How can I get the context of other activity?
Just cancel the intent you scheduled
Your best bet would be to make use to push notification (via GCM), whenever something new is available on the server. I am working on similar application where data can be pushed from one side (producers) and needs to be pushed to the consumer apps.
You need to look at BroadcastReceiver and GCM specific communication model. Hope this helps
I'm trying to make a task schedule app and I made an Alarm app trying to learn how to do that part at least. It uses AlarmManager and it makes an alarm go off at a time chosen by a TimePicker. But it doesn't work when the emulator is turned off and on again.
So I'm trying to use BroadcastReceiver but I don't understand any of the guides...I mean am I supposed to set the intent that the alarm manager does to the BroadcastReciever? Or can I just start up the app and then the alarm exists again or what? How are the alarms stored in android?
But it doesn't work when the emulator is turned off and on again.
That is the correct behavior -- AlarmManager's schedule is cleared on a reboot. You need to specifically register to receive the ACTION_BOOT_COMPLETED broadcast, in order to re-establish your alarm events after a reboot.
I mean am I supposed to set the intent that the alarm manager does to the BroadcastReciever?
Well, if you are using a _WAKEUP-style alarm, the recipe is to use a getBroadcast() PendingIntent with AlarmManager, where the BroadcastReceiver is either a WakefulBroadcastReceiver (and follows those instructions) or passes control to my WakefulIntentService.
I have somewhat-contrived examples of using WakefulIntentService and WakefulBroadcastRecevier.
How are the alarms stored in android?
AFAIK, they are held in the memory of a core OS process and are not persisted.
my application needs to send a message to my server every 30 seconds or so.
I understand I need to use AlarmManager using RTC_WAKEUP or ELAPSED_REALTIME_WAKEUP.
now I don't understand two things:
1) If the AlarmManager wakes up the device, why do I need to aquire a WakeLock?
2) I saw an example for using AlarmManager with WakeLock. In this example, its setting the alarm to send a broadcast to a broadcast receiver which then acquires a static wake lock and then start an IntentService which runs a task.
now, my question is, in my case, I need to follow this example entirely? why don't set the alarm to start a service instead?