I am developing an application that needs to constantly run a service unless the user consciously deactivates it. The problem is that there are taskkiller-apps with a "kill all applications"-button. These seem to become increasingly popular, and they are causing me a fuzz. When I kill my service with som task managers, onDestroy() is never run and all AlarmManagers are killed with the service. Is there any way to protect my service from these apps, or to restart my service immediately after it is killed?
Is there any way to protect my service
from these apps, or to restart my
service immediately after it is
killed?
Not really, sorry.
Besides, if your service is well-behaved (i.e., not designed to run in memory all of the time), users will be less likely to kill it off using these tools. Services are not designed to run forever.
I ran into a similar problem, using "Advanced Task Manager" for Android. The app even has an "exlude list" where you can protect your apps from being killed by the Task Manager.But still, my service would be killed, leaving it useless. I've been through loads of forums, trying to contact the author of ATM, but to no avail.
The solution (sounds like a bug in ATM): I had to exclude the service as well as the app that started the service in ATM to make it leave my app untouched (even though only the service was needed). Weird, but true.
Related
I would like to upload large files (~10 - 100Mb wifi or mobile network), but in background, because the user maybe will leave the app and later the system will close the app (if not enoguh memory) I created a service for this case but my problem is that when i killed the app the service restarting and the uploading start again. I found same problems without solution:
keeping background service alive after user exit app
My service is restarted each time the application is closed
So it won't work, but what is the solution? How does the youtube app???
You should use a foreground service via the startForeground() method if you are concerned about the possibility of the service being killed.
From the Service Lifecycle Docs:
A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)
Do you have control over the server? This seems just like:
Uploading big files over HTTP
Googling brought up a proposal for the Gears project:
https://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal
If you can use a server/plugin/module that will allow for Ranged PUTs, that's your best bet, otherwise you may have to roll-your-own "chunking"... Depending on your tools and knowledge, that may be the best option anyway, you could tweak it to optimize it for your specific mobile conditions.
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.
This may be discussed before, but i didn't find answer. I've problem with my application beeing killed when some other apps needs memory. I looked at Activity Lifecycle and tested my app. All i want to know is: when in one of my processes are called onPause() or onStop() and other apps needs memory, how to avoid from my process being killed.
You can't avoid this. When system needs memory or does cleanup, it can kill application.
However you may somehow control importance of your application, so that it may live longer.
Read here about importance of various application parts related to process killing:
http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle
To have long-running application, implement Service. However, also Service may be killed, but system schedules to restart killed or crashed services after some time.
This isn't possible, every application is treated equally in android and one of the things you have to consider is that your app might be killed. You can keep services running, that might do what you want if it's something in the background.
What happens to a service started by BOOT_COMPLETE after system kills it for memory?
Will it ever be restarted without rebooting the phone? Is it possible to restart it somehow?
What is the best practice to avoid as much as possible an important service from being killed?
Will it ever be restarted without rebooting the phone?
Possibly. If it truly was because "system kills it for memory", and you return an appropriate value from onStartCommand() (e.g., START_STICKY), it should be restarted at some point in the future. If the service was killed due to user action (e.g., Force Stop in the Manage Services screen in Settings), it will not be restarted.
What is the best practice to avoid as much as possible an important service from being killed?
First, design your application to not rely on an everlasting service like this. 99.44% of Android applications do not need a service that runs continuously, let alone one that starts doing so at boot time. Android device users hate developers who think that their apps are sooooooooooooo important that they have services running all the time -- that's why we have task killers, Force Stop, and Android killing services due to old age. For example, if you are checking for new email every 15 minutes, use AlarmManager and an IntentService, not a service that runs forever.
If you can demonstrate -- to me and to your users -- that yours is among the 0.56% of applications that really do need a service that starts at boot time and runs forever, you can use startForeground(). This will indicate to the OS that your service is part of the foreground user experience. You will have to display a Notification, ideally to allow the user to shut down your service cleanly if and when the user no longer feels that it is justified.
If you need to restart the service then you should use AlarmManager to check up on the service in a separate BroadcastReceiver, but nominally when a service is killed by the system for memory it will not get automatically restarted.
You may want to take a look at START_STICKY
Use the AlarmManager to periodically send an Intent-- receive the intent and make sure your service is running.
I've got a running service. But when taskmanager kill the Activivty that starts the service the service get killed to.
Why do my service get killed when the taskmanager kill the activity not the service?
There is no "taskmanager" in Android, at least by that name.
If you are running Android 2.1 or older, third party applications that describe themselves as "task managers" or "task killers" can terminate your entire process, and more besides, which will get rid of your service.
If you are running Android 2.2 or newer, while "task managers" have a somewhat reduced role, the Settings application in the OS allows users to force-stop any application or individual service.
IOW, what you are seeing is perfectly normal and something you need to take into account. Users do not like services running for long stretches of time, unless they perceive value from those services being there. So, for example, a user who kills the service that is playing back music quickly learns not to do that anymore. But, if the user does not know what value your service is adding, and your service is running a lot, expect it to be shut down by the user.
As a result, savvy developers architect their applications to avoid long-running services. For example, if you are checking the Internet for something (e.g., new email) every 15 minutes, rather than have a service running all of the time, use AlarmManager to start up your service every 15 minutes, and have that service stop itself once the Internet check is complete. This gives you the same functionality, but you stay out of memory most of the time.
Complementing CommonsWare: if the only reason for your Service to exist was that it was bound to the activity, when that activity is killed there is no longer a reason for the service to exist, hence it could be killed.
(I thinking in bound services in here! http://developer.android.com/guide/topics/fundamentals/services.html)
Update
Based on your comment, I see that you are using a "Started" service. In that case I recommend you to implemente the service in a separate class, not as an inner class within the Activity class. This could be what was causing your problem.