I am using a timer in my application for repeated task. By default, the timer should repeat the task with a delay of one second. I am starting the timer when the application Starts. All this is works perfectly. Also,When I came out of my application and open some other application, the timer keeps running.
When I open Google Maps application, my timer stops running. I don't know why this is happening. I googled and found from the activity life cycle that, if other applications needs memory, all processes will be killed. This is what happening in my case, I guess.
I do not want my timer to stop. It must run always till the user uninstall my application.
Why the above problem occurs?
How to achieve my requirement?
Does Using services will solve the problem? If so, Is there any way to keep timer always ON without using services?
Does Alarm Manager be helpful? Even if the user restarts the phone, the timer should work properly.
Yes, a service will solve your problem. The persistence of an Activity is governed by its lifecycle, so in the end, you have no control of its execution. A service is persistent in that it will not be shut down by the system. If you are doing extensive calculation, however, be warned that the OS will not be as generous with resource allocation as it is with an on-screen activity.
In short:
1) Well, from the information you've given, I suppose you drew the right conclusions.
2) Through a service.
3) Yes, it will solve your problem, no, I don't think there is another way to do that, at least not from within an activity.
4) If you're not actually asking about the persistence of a Java.util.Timer but for a way to have a piece of code executed at certain times, this might be the better (/easier) solution. I don't know how well it works for rather frequent timings, though. A service can be resumed on system restart, so no worries about phone shutdown. You can subscribe to the startup event.
Related
Search engines and Android developer website didn't help and I guess you can help with my problem.
I want to make an app for personal use, which is supposed to run all the time on my old tablet (powered all the time). The app will have several features requiring user interaction but independent of those, it should run a background job to check something continuously (real time!) for instance sound detection. It should also always try to connect another device on the network.
That means that job needs to run almost eternally without being killed. Some comments I have found suggested AlarmManager or BroadcastReceiver. But those are triggered by very defined triggers (either time or broadcast). I don't want that, because it should perform its task continuously all the time. This background job should also be able to communicate with the main Activity of my app to report what it is doing and allow user to interact with it (change settings of the job for instance).
Do you know any way how to accomplish this? Is IntentService correct choice for this (hoping that it won't get killed or maybe I should let the Activity to restart it?)
Thanks!
Do you know any way how to accomplish this?
Build your own custom ROM, with a modified version of Android that contains your code as a native Linux daemon.
Otherwise, what you want is technically impossible.
You can come fairly close by using a foreground Service (not an IntentService) and returning START_STICKY or START_REDELIVER_INTENT from onStartCommand(). Android may terminate your process from time to time, but it should restart your service automatically after a short while. That service can use its own background threads to do whatever it is that you are trying to do.
I made an android application with a runnable that checks something ever minute.
But the problem is the application goes [DEAD] after a couple hours without an error messages or anything.
Anybody have any idea what the problem could be?
That is not a problem, that is actually expected behaviour.
The lifecycle of all apps is managed by the Android OS. It decides whether to terminate an app in order to free resources and keep the system responsive. Apps that are currently is use have priority over paused and background ones. I think in your case the OS just decides to shut down the app because it thinks it's not needed anymore.
There are ways to get around this, but it all depends on what your app actually does. I don't know your implementation details, but may want to look into sticky Services or the JobScheduler in order to achieve what you want. Keep in mind that there is no such thing as a perpetually running background task that comes out of the box in Android (not should there be one) and usually implementations have certain limitations.
It could be the Android OS itself closing the app. If the OS requires more memory it will start to kill of other processes that have not been used for a long time (i.e. interacted with). You haven't stated how the check happens but it shouldn't be done directly within the app, but it sounds like it is something that a background service should be doing the work which would likely prevent this from happening.
You should NOT use Runnables for background processes, as they get suspended/killed by the OS as soon as your app goes off-screen.
If you want to let some processes run regularly, you have to stick with AlarmManager / BroadcastReceiver combination
my knowledge of services in any operating system, is that they usually run in the background and perform whatever work they have to do.
but the first time I got familiarized with android services, I got confused.
it appears they only run when the application is working, and that for me, makes them no more then sophisticated threads.
do I have this all wrong? how do I make a service that runs when the application doesn't? (so that I can check for updates and create notifications for the user that will then lead him to the application if he chooses to open them).
does push notifications have anything to do with it?
Edit:
thank you guys for your answers so far.
my problem seems to be the fact that the service is only started officialy when the device is booted up. I do call startService when the app starts, but that doesn't seem to help. the service still dies when the app is turned off (unless it was booted)
also I never call stopService
If you are trying to implement a long running task that is performed in a (background) service, you have to start one or more threads within your service. So the service just gives you the opportunity to have an application context without having to have a user interface ;) you can consider it as a kind of container.
This page give you a nice overview about different thread approaches in Android. As you can see a service has not its own thread.
Anyway, in your case it seems that an AlarmManager is probably the better option. Running services for polling information all the time can be quite CPU and battery consuming (see this post for instance). So try to avoid having threads that run all the time.
If you can push information about updates from a server it's just fine. Check out Googles Cloud Messaging in this case.
Michael who commented on my question first was right in his comment about startService()
so it goes like this:
my receiver is only activated on boot, and uses an AlarmManager to
time the service to certain intervals.
what I did was to bind the activities to the service. if the service
was off and I binded it and unbinded it, then by the time the app was
terminated, there was nothing keeping it alive.
by simply making sure that the service was started properly with
startService if it is not already on, I managed to keep the service
alive at all times
also thanks to Trinimon who gave a very nice explanation on what
services are, and the importance of not overloading the CPU with
excessive polling. (which is kind of a trade off situation)
good luck to all :)
I want to perform action/event when application killed from task manager or any other app. Is there any to perform action when application killed. My application is running in background like service. If i terminate the application then main service stop . I want to start it again.
No, there's no reliable way to know if your application was killed by a another process. The whole point of "killing" an app is to terminate it as soon as possible, without letting it run any code.
== Do not actually use the following suggestions in production application. They are here purely as potential technical solutions, but in general are not a good idea for apps running on end user devices. ==
It might be possible to use IBinder.linkToDeath() from a secondary application, which acts as a monitor for your primary one. However, you will have to convince the user to install the secondary app as well. If you can do it, you could establish two-side monitoring between the two apps, and have one of them restart the other if the second is killed.
You could also attempt to set an alarm through the AlarmManager that fires every so often, to restart your application if it happens to be killed. However, if your alarm period is too big, you risk having certain period of time where your app is not running. And if your time period is too small, most likely your app will not be allowed by Google in the Google Play Store, and the malware app analysis on the phone (JB+) might kick in. Also, alarms that kick in too often will keep the device awaken, and drain the battery very fast.
If you kill some process, you just kill it, so it stops working immediately. There is no event sent to the application.
I looked for the same thing and the answer that i found is : NO, the application does not go to OnDestroy() or anything like that.
I want to update the location every 5 mins till the lifecycle of the application. I know how to update the location. What I want to know is whether the requestForLocation is a blocking call or not.
I can do this in Service class but Service is run on main thread only and also Service can be stopped by the system anytime. I do not want this to happen. The location update should work till the application is in memory. If the application itself is killed then obviously the Service also gets killed.
What should be the approach for implementing this?
What I want to know is whether the requestForLocation is a blocking call or not.
There is no method named requestForLocation() or requestForLocationUpdates() in Android. If you mean requestLocationUpdates(), this is not a blocking call.
I do not want this to happen.
Users and the OS have the right to terminate your service whenever they wish. In this case, it's a good thing, because your proposed plan wastes RAM for no benefit.
What should be the approach for implementing this?
Use AlarmManager and a service akin to my LocationPoller, so you can get your location data, do something with it, and shut down until the next period comes around.
Also, please allow your users to configure the polling period, including an option for "do not poll".
For some reason this requestLocationUpdates() call is really blocking, at least in the phone brands that I tested. The way to fix it is to use one of its overloads. Please see this answer in another post.