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).
Related
My IntentService gets fired from 2 places, either by an Alarm or by the Activity and since the duration is related to the amount of data it needs do fetch from the web, from what I understood, I need to keep a partial wakelock.
Here's my implementation:
#Override
protected void onHandleIntent(Intent intent) {
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
WakeLock wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "WakeLock");
try {
wakeLock.setReferenceCounted(false);
wakeLock.acquire(3600000);
///other code here
}
catch{
}
finally{
if (wakeLock.isHeld()) {
wakeLock.release();
}
}
My question is: will this work good enough? Will the finally make sure that the wakelock is released in any circumstances? From what I know onHandleIntent handles intent one after another, so there is no risk in having 2 intents/2 wakelocks in the same time.
Later edit:
The IntentService is called in 2 ways:
from my Activity, like
startService(new Intent(context, MyService.class).putExtra()..);
2 from a triggered Alarm using a PendingIntent
PendingIntent pendingIntent = PendingIntent.getService(context, someId, myServiceIntent, PendingIntent.FLAG_UPDATE_CURRENT);
Will the service have enough time to aquire wakelock when ran from the Alarm?
Whether you need to keep wake-lock or not should not be related to the amount of work your Service does - theoretically, device can go to sleep even if the amount of work is small.
Wake-locks should be considered only if you absolutely must ensure that device can't sleep while the Service is running. Cases like this are very rare. Some examples:
Alarm clock applications (need to wake you up even if the device is sleeping)
Real time messaging applications (need to notify you about new messages even if the device is sleeping)
Most applications don't have such a strict timing requirements. For example, the following are NOT good reasons to use wake locks:
Periodic synchronization of data with the server (should be delayed until device awakes)
Displaying current user's location on map (can be obtained when device awakens; but wake-lock will be needed for applications that monitor user's entire route)
If you really need to ensure that the device doesn't sleep during Service execution, then you need to acquire a wake-lock (one of the several types). Let's assume that this is the case here.
You want to be able to start the "wakeful" Service from application's UI (Activity), and using AlarmManager.
Starting from UI
Since the device should be completely awake in order for the user to interact with UI, you can safely assume that if you start the Service in response to UI interaction it will have a chance to acquire a wake-lock (but do it as soon as the Service is started).
Your solution covers this case.
Starting from AlarmManager
Unfortunately, there is no guarantee (at least no documented guarantee) that when AlarmManager starts the Service it will hold a wake lock and allow the Service to acquire its own wake-lock. This means that the device can go to sleep after alarm fired, but before your Service had a chance to acquire the wake-lock.
This means that your solution will "break" in this case.
The only documented scheme in which AlarmManager will help you with wake-locks involves broadcasts:
The Alarm Manager holds a CPU wake lock as long as the alarm
receiver's onReceive() method is executing. This guarantees that the
phone will not sleep until you have finished handling the broadcast.
Once onReceive() returns, the Alarm Manager releases this wake lock.
This means that the phone will in some cases sleep as soon as your
onReceive() method completes. If your alarm receiver called
Context.startService(), it is possible that the phone will sleep
before the requested service is launched. To prevent this, your
BroadcastReceiver and Service will need to implement a separate wake
lock policy to ensure that the phone continues running until the
service becomes available.
This is where WakefulBroadcastReceiver comes in very handy.
Note that if you use this scheme, then there is no need to support a different one for "UI initiated" case - use the same approach in both cases.
You might also want to take a look at this library developed by #CommonsWare (I didn't use it myself though).
I can observe my device is not going to sleep because alarm is holding a partial wakelock, but i don't know how to find app on behalf of which alarm is holding wakelock.
AlarmManager provides access to the system alarm services. These allow you to schedule an application to be run at some point in the future. When an alarm goes off, the Intent that has been registered for it is broadcasted by the system, automatically starting the target application if it is not already running. Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted. The Alarm Manager holds a CPU wake lock as long as the alarm receiver's onReceive() method is executing. This guarantees that the phone will not sleep until you have finished handling the broadcast. Once onReceive() returns, the Alarm Manager releases this wake lock. This means that the phone will in some cases sleep as soon as your onReceive() method completes. more Detail
https://github.com/asksven/BetterBatteryStats-Knowledge-Base/wiki/AlarmManager
You can also look at battery-historian. It's a very helpful tool for finding unreleased wakelocks and logging battery history.
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 want to build an alarm application. I've seen some examples and some of them use Service and some use BroadcasterReceiver. The user will set the alarm and then when it goes off they'll have to do certain things like solve a mathematical equation or scan NFC tag before it turns off. Which one should I use?
If you are using AlarmManager with a _WAKEUP alarm, you must have the PendingIntent route to a BroadcastReceiver. The only thing Android guarantees with a _WAKEUP alarm is if you use a BroadcastReceiver, Android will keep the device awake long enough for onReceive() to complete. Anything else, all bets are off.
It the work you want to do would take more than a couple of milliseconds, have the BroadcastReceiver turn around and pass control to a service, which can do its work on a background thread. You may wish to use my WakefulIntentService for that; if not, you will need to manage your own WakeLock to ensure that the device stays awake until the service can complete its work.
I've been seeing some strange issues using the Alarm manager in Android, despite the fact that I'm using RTC (non Wakeup) the phone will reliably send the PendingIntents on the correct repeating intervals.
Details of my test
Device is not charging, just sitting on my nightstand while I slept
My service woke up on its repeat interval (30 minutes, an extreme I know) EVERY TIME
The service logged its activity in a file so I could read it in the morning
Now from my understanding the phone should be sleeping unless I wake it up and my Alarms should not be sent until the phone is awake.
Why was my service executing?
If another service is misbehaving and using the _WAKEUP variants of the alarm will my service wake up too?
Can I avoid being woken by another service, and just awake from the user turning the screen on?
Why was my service executing?
Presumably something else was having the device awake at those moments.
If another service is misbehaving and using the _WAKEUP variants of the alarm will my service wake up too?
Yes, though "misbehaving" is in the eye of the beholder.
Can I avoid being woken by another service, and just awake from the user turning the screen on?
Not directly via AlarmManager. You can watch for ACTION_SCREEN_OFF and ACTION_USER_PRESENT broadcasts, and perhaps disable your alarms between those.
I've just spent an hour trying to find out why my RTC alarm sends PendingIntents even when my phone is sleeping. And the answers is very simple, because it was pluged with USB so the phone had status "charging".
Presumably something else was having the device awake at those
moments.
A lot of applications with notification ads (like AirPush, Leadbolt ect) wake up the device.