This code set an alarm at 25/12/2012. How is possible replace 2012 with every years?
Calendar cal = Calendar.getInstance(TimeZone.getDefault(), Locale.getDefault());
cal.set(Calendar.DATE,25);
cal.set(Calendar.MONTH,Calendar.DECEMBER);
cal.set(Calendar.YEAR,2012);
Keep in mind that alarms are not persisted to disk. Since it is very likely that your device will be reset, rebooted or simply run out of battery long before the alarm is triggered, using the AlarmManager for such long periods is not a good idea. You could have a broadcast receiver for device boot (BOOT_COMPLETED) and register your alarm, but that too is not too reliable and may not be available on ICS and later (not unless the user started your app manually).
The comment above is correct though, one way to do this is for each alarm to schedule the next one.
Related
I have an alarm that works fine if i am interacting(using) with my application but it dose not works if I set it for next day and not interacting with my app.Therefore I am getting doubt is this because my application process is not running at that time.
here is what I am doing
Calendar calSet = Calendar.getInstance();
calSet.set(Calendar.HOUR_OF_DAY, selectedhour);
calSet.set(Calendar.MINUTE, selectedminute);
calSet.set(Calendar.YEAR, year);
calSet.set(Calendar.MONTH, monthOfYear);
calSet.set(Calendar.DATE, dayOfMonth);
alarm = new Intent(ActivityA.this, Service.class);
pendingIntent = PendingIntent.getService(getApplicationContext(), i++,alarm, 1);
alarmanager.set(AlarmManager.RTC_WAKEUP, calSet.getTimeInMillis(),pendingIntent);
From AlarmManager
AlarmManager provides access to the system alarm services. These 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. 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.
In simple way, it will work until your device has been rebooted.
You can read Android AlarmManager after reboot where #CommonsWare has been given a link of his sample application which persists Alarm even after device reboot.
Please ignore below section, it seems not valid. I will remove in future
You can read more about application kill at How to create a persistent AlarmManager, and How to save Alarm after app killing? can give you the idea about how to handle such issue (to persist alarm if application has been killed).
Yes it worked but proper understanding see doc.
Note: The Alarm Manager is intended for cases where you want to have your application code run at a specific time, even if your application is not currently running. For normal timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler.
see here http://developer.android.com/reference/android/app/AlarmManager.html
Looking at the AlarmManager documentation..
http://developer.android.com/reference/android/app/AlarmManager.html
I don't see anywhere where it states that killing your app will remove all alarms that have been scheduled by that app. More specifically it states if your app is not started, it will start it for you.
I have done my own testing and can validate this by..
Setting an alarm 5 sec in the future.
Then closing app from recents.
Then watching logs for my broadcast to be received.
Keeping in mind this was done with a signed apk.
Calendar cal = Calendar.getInstance();
cal.add(Calendar.MILLISECOND, 5000);
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
alarmManager.set(AlarmManager.RTC_WAKEUP, cal.getTimeInMillis(), pendingIntent);
I would also keep in mind what Pankaj Kumar said about the restarting alarms on boot. That is the one place you need to cover yourself, because AlarmManager does clear all alarms on device restart.
We need to enable our app in autostart manager in app manager, some handsets like Vivo v5,
In Vivo v5, we can find out this menu in
iManager > App Manager > Auto Start Manager > Enable our app here.
Then your alarm / alarm manager will trigger alarm if the app is killed or closed.
How to use alarm manager at accurate time interval?
I used alarm manager but it response inaccurate.
Can anyone help me?
I used this code
PendingIntent sender;
AlarmManager am;
long firstTime;
Intent itnt = new Intent();
itnt.setAction("abts.medismo.medismo.ALARMRECEIVER");
sender = PendingIntent.getBroadcast(context, 0,itnt, 0);
am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
am.cancel(sender);
firstTime = SystemClock.elapsedRealtime();
am.setInExactRepeating(AlarmManager.ELAPSED_REALTIME,firstTime, Integer.parseInt(sep[3]), sender);
You should use ELAPSED_REALTIME_WAKEUP, because if the phone is asleep it wont fire until it wakes up again.
There are two issues here.
The first, as others have pointed out, is that your alarms are not "wakeup" alarms. This means that if the device is asleep when the trigger time is reached, the alarm will not cause the device to wake up and process the alarm immediately. Instead, it will be processed as soon as something else causes the device to become active, such as the user picking it up and pushing the power button to start using it.
The second issue is that you are using setInexactRepeating(). As the name implies, these alarms are never going to be delivered at precisely predictable times. As the documentation says, "In addition, while the overall period of the repeating alarm will be as requested, the time between any two successive firings of the alarm may vary."
This is often enough for most apps, and it is more efficient in terms of battery use. However, if you truly need the alarm to be delivered at a specific time, you need to set the alarm time yourself instead of relying on periodic alarms. In addition, as of API version 19, you should use the new setExact() APIs if you truly need precise delivery.
I believe your observed inaccuracy may be caused by the subtle variation of flags for the alarms.
AlarmManager.ELAPSED_REALTIME and AlarmManager.ELAPSED_REALTIME_WAKEUP utilize elapsedRealtime(), which is the number of milliseconds since the device last booted up, good for measuring elapsed time for timers and the like.
AlarmManager.RTC and AlarmManager.RTC_WAKEUP utilize currentTimeMillis(), which is the system clock:
time in milliseconds since January 1, 1970 00:00:00 UTC. This method shouldn't be used for measuring timeouts or other elapsed time measurements, as changing the system time can affect the results.
All four of the AlarmManager clock flags I've listed will include time spent in sleep, but only the *_WAKEUP flags will wake the device to sound the alarm; the default flags will wait until the device is otherwise awakened and then sound the alarm immediately.
Make sure you select the flag that matches your use-case, and ensure that the value of your delay {Integer at sep[3]?} is the amount of time to wait between alarms in milliseconds; as you have it, your Integer is being unboxed and cast to a long; it works, but unless there's a reason for it, I recommend switching to a primitive long; so a 15 minute delay would be:
int delay = 900000L // 15 minutes * 60 seconds * 1000 milliseconds
http://developer.android.com/reference/android/app/AlarmManager.html
http://developer.android.com/reference/android/os/SystemClock.html
I would like to achieve this:
After first turning on the application, user receives notifications, every day at 2pm, if certain condition is true. If condition is false, we are not showing a notification this day. The condition is checked at 2pm, it downloads some data from the Internet.
So far I used AlarmManager and its method setRepeating() with 24h interval. AlarmManager fires up a Service. In this Service I'm downloading the data, checking condition and if it's true - showing Notification. Since downloading can last more than 5 seconds, I've declared android:process=":background" for this Service, to run it in separate process and not block my UI.
This approach has two drawbacks:
1: If user opens application let's say at 4pm (and the condition is true), he will receive the notification immediately. From setRepeating() documentation:
If the time occurs in the past, the alarm will be triggered
immediately, with an alarm count depending on how far in the past the
trigger time is relative to the repeat interval.
I would like that user will not receive a notification this day, only the next day and so on.
2: I'm worried that my notifications will not show after user switch the phone off. From AlarmManager documentation:
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.
I don't know if it's possible to make it work all the time.
If you have any ideas how to make it better, you're welcome.
1: I'm not quite sure if i understood your question, but I think all you have to do is if it already is past 2pm add a day to 2pm:
GregorianCalendar twopm = new GregorianCalendar();
twopm.set(GregorianCalendar.HOUR_OF_DAY, 14);
twopm.set(GregorianCalendar.MINUTE, 0);
twopm.set(GregorianCalendar.SECOND, 0);
twopm.set(GregorianCalendar.MILLISECOND, 0);
if(twopm.before(new GregorianCalendar())){
twopm.add(GregorianCalendar.DAY_OF_MONTH, 1);
}
alarmManager.setRepeating(type, twopm.getTimeInMillis(), 1000*60*60*24, intent);
2: You could register a BroadcastReceiver for booting and start your alarm again there. Take a look at this: Android BroadcastReceiver on startup - keep running when Activity is in Background
I want to set a repeating alarm monthly; but my app resets the alarm everytime it boots up. So is it bad practice to do it this way rather than setting a repeating alarm?
(The Alarm is set for a specific day of the month. (e.g. The 8th, 16th, 21st, etc). So if it is past that day, it simply +1's on the total the current month.)
I also run a service on boot up to set any alarms so even if they don't go into the app for a month, it will be reset again.
Again, is this the best way of doing this or is this bad practice?
So is it bad practice to do it this way rather than setting a repeating alarm?
If it works for you, it is probably fine.
I also run a service on boot up to set any alarms so even if they don't go into the app for a month, it will be reset again.
That is a little odd. Getting control at boot time to re-establish alarms is fine, but you should not need a service for that.
I am writing an alarm app, and would like to do some specific work when the alalrm is triggered. For this I use the AlarmManager.set() method and the pending intent broadcasts the intent. So far so good. But what if the OS decides to close my app which was in background due to memory crunch. Could someone help me with this.
Also if I want repeated alarms then I can use the AlarmManager.setRepeating(). Does this take into consideration the day light saving adjustment ?
The Alarm will start your application even if this isn't currently running. In order for this to happen you need to register a broadcast receiver either with the <receiver> tag in the manifest file or with the registerReceiver method. Read the documentation for details.
As for your second question, although I haven't tried it, with setRepeating you configure the interval between subsequent alarms. If for example you have your first alarm at 13:00 and use an INTERVAL_DAY interval, the alarm will fire every day at 13:00. If daylight savings take affect and 13:00 becomes 12:00, then the alarm will fire daily at 12:00. However, I suppose you need to try this out.