Develop Reference

What should I use specifically for running a light background task?

I am in the process of making an app that will be triggered by a system broadcast and would take time input from the user, after which the app should just run a timer and do a task after the timer is over. My questions are as follows:
Do I need to use a background task for this, or is this possible to be achieved without it, because I need the timer to run even if the app is closed in the app drawer.
If I do need to use a background task, what should I use, an AsyncTask, a Service or a JobScheduler?
I understand that a BroadcastReceiver will listen to any system broadcasts, and since I have registered in the Manifest, the app will start on any such system broadcasts. However, as soon as the app is started due to the system change, I need it to popup a dialog box which takes input in the form of time (HH:MM:SS), and after that a timer begins which runs for that amount of time and as soon as the timer stops, another task is done.
I also don't want the task to be a one-up, meaning that I want it to be to done every time the system receives the system change broadcast.

For what you want to do, you basically need three things.
A BroadcastReceiver for receiving a system broadcast. This component is essential. Also, you don't have to worry about it being a one-up thing. A registered BroadcastReceiver will continue to run it's onReceive() method until the BroadcastReceiver is unregistered by you or the system, or if you intentionally place code in to block it from activating.
An Activity to display the Dialog. Technically, a BroadcastReceiver can also display a Dialog, but BroadcastReceivers are meant for short and quick tasks, so it's not a good place for this. An Activity where you show a DialogFragment is the better option because compared to a Service, an Activity is really the component meant to display a UI.
An AlarmManager for counting down the time. Rather than creating a Service yourself to handle the timer, you should use the AlarmManager with exact time to help you respond to the amount of time that passed. You can also use a JobScheduler as an alternative to AlarmManager, since both are meant for executing code at a later time. Which one you choose depends on the task you want to do later on. Personally, you should also consider the new WorkManager, which is the better option in my opinion. Depending on what you need to do, it will internally use a JobScheduler or AlarmManager, which helps get rid of the deciding process for you.

How to keep AlarmManager to start Service after kill my app?

I need to request a url every 5 seconds.So I used AlarmManager to send a intent by call setRepeating.but when I long click HOME hardware button to kill it, AlarmManager doesn't work. How to solve that? :)

Usually if you don't kill your Alarm when you call the onDestroy(), the Alarm should still be running on background even after application exit. Are you sure that you are not terminating it somewhere inside your onDestroy() method?
If you give a look here :
http://developer.android.com/reference/android/app/AlarmManager.html
The docs says : "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."
Remember that if your phone is in stand-by it might not be able to execute the code you want to, you need to wake it up properly.

Android Developer - Alarm manager vs service

I am making an app that needs to execute a function each hour even the app is closed.
First of all, I thought to create a service, but during my tests, I realise that android sometimes kills my service. So I was looking for another solution and I found AlarmManager. I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
Another question, it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread?

I have implemented it and it seems to work but I have the doubt if it will happen the same the service or it will run forever? (Until reboot of the mobile...)
It will run until:
the device is rebooted, as you noted, or
the user uninstalls your app, or
you cancel the events yourself, or
the user goes into Settings, finds your app in the list of installed apps, taps on that entry, and clicks the Force Stop button
It's possible that alarms will need to be scheduled again after your app is upgraded (I forget...).
it is necessary to create a new thread to execute the process in alarm manager or it runs directly in other thread??
Unless the work you are going to do will take only a couple of milliseconds, you will want a background thread for it. That leads to two possible patterns:
If you are not using a _WAKEUP-style alarm, use a getService() PendingIntent to send control to an IntentService every hour
If you are using a _WAKEUP-style alarm, you will need to use a getBroadcast() PendingIntent, and have it either invoke your subclass of my WakefulIntentService, or you will need to manage a WakeLock yourself to keep the device awake while you do your bit of work

No, Android won't kill scheduled alarms and they got executed as planned unless app is replaced or device is rebooted. Use broadcast receivers for these events to reschedule Alarms. There's no way to prevent Force Stop as it kills all of your app components and threads totally.
That depends on what Alarm Manager do. If it sends a broadcast, the receiver limit is 10 second.
If it starts an Activity, Service or Intent Service, there is no limit. For Activity and Services you must finish or stop it and for Intent Services until the process is finished. Be aware that you can't have another thread inside Intent Service and you'r limited to code inside the OnHandleIntent.
Also you must consider device state. If it's sleep and you are using Wake Up flag receivers won't need a wake lock, but others do. It won't take long for device to go back to sleep.
Don't waste system resources with a service because Alarm Manager do what you want.

Android Timer Alternative

I'm looking for some timer alternative, since timer dies with app, is limited, and every timer launches own thread.
Sometimes I need to launch about 20-30 timers.
I need to set some event, in time, and when it comes display app screen. Is it possible?

This may or may not be possible depending upon your definition of "dies with app".
You can use AlarmManager to schedule PendingIntents to be invoked at specific times in the future. Those PendingIntents can launch activities. This will work if your app "dies" from ordinary causes.
However:
If the user force-closes your app via Settings, your alarms are unscheduled, and there is nothing you can do to stop this (nor do you have any alternative to AlarmManager that somehow survives this)
Please allow the user to determine whether or not you display an activity or raise a Notification at these times, as users may not necessarily appreciate having their game, navigation, video, or phone call interrupted by your activity.

You should use AlarmManager.
As CommonsWare says that there are some limitation of it, but that is ok, if an user force closes your application it means he doesn't want to use your application (any more or due to sort of memory)....
And I have a solution (but may be not the best), because you can not listen if user force closes your app, so one way is that you can re schedule your event on each start of your application. I know this is not a good solution but ..... we have no any other way yet
Here is a good example.

Best strategy to implement this behavior in Android app?

In my Android app, I have some data that needs to be synced daily but also needs to be updated every hour when a user is inside the app.
I have already implemented a service that gets called from an alarm for the daily update. Im having a problem with developing a strategy to do the hourly sync. I could use an hourly alarm too and fire the same intent, but since your app can be killed at any time, there would be no way to cancel it (and since they use the same Intent, doing a cancel would cancel ALL alarms including my daily sync, so that's probably not good).
The other option is to use a Timer that's set when inside the app, and have that fire my Intent when inside the app. Im assuming all Timers get cancelled when an app is killed right? But my app consists of several activities and I want the timer to work across all activities, how do I do that? I dont want to duplicate code - we're already using a subclass for Activity and ListActivity.

I have some data that needs to be
synced daily but also needs to be
updated every hour when a user is
inside the app.
The solution seems easy: drop the second requirement. Few apps are used continuously for hours on end, since people tend to use their Android phones for other things (e.g., phones), so your update-hourly-if-used-all-the-time code will probably never run.
I could use an hourly alarm too and
fire the same intent, but since your
app can be killed at any time, there
would be no way to cancel it
FWIW, your app will not be killed while it is on-screen. And, while it is not on-screen, you don't want the updates going hourly.
Im assuming all Timers get cancelled
when an app is killed right?
Apps generally are not "killed". We expect you to clean up after yourself when your activities are called with onDestroy(). If you set up the Timer with a daemon thread, you will need to terminate that thread.
But my app consists of several
activities and I want the timer to
work across all activities, how do I
do that?
Bind to your service from each of your activities. If it is started by your alarm Intent, have it do normal update processing. If it is started due to a binding request, just have it make sure its hourly Timer is running. When it is called with onDestroy() (e.g., after all activities have unbound), have it stop the Timer.

You might be able to have a Timer run in a background service (which get killed less than activities) but there is still no guarantee that Android won't kill your service either. And running something like this is the background might use a lot of battery.
What about doing the hourly sync in a background thread that get's created in onResume? And just save the last time the user did the sync, and if it has been > an hour just do the sync. Because I don't think there is any reason to eagerly sync data that the user is never going to see.