Make AsyncTask (or a service) unkillable (or something approaching it) - java

In my application there's an AsyncTask which runs in the background for much time. The problem is that in low memory situations it's killed by the VM, is there a way to make the application's priority higher, so that it would be harder to kill? Should I use a service instead? My only target is to make it difficult to kill, any advice or guidance would be greatly appreciated, thank you.

I would advice you to make it a service and use startForeground() which will make it a little more resistant. But even then it might get stopped on low memory.

No, there's no as everyone would abuse this otherwise. If OS kills your service then it got a reason for this. If condition permits and your service qualifies, it will be restarted if Android thinks it shall do so.

If your service is killed, then it's restarted by the system as soon as resources allow.
So, make it a service (it shouldn't be a foreground service, if it doesn't do anything decidedly user-oriented like playing music), but a service that can save its state (onMemoryLow() and onDestroy() methods). So after the restart it can resume its process with the user being none the wiser.

Related

How to handle a shutdown request in Java

I assume Java applications receive some sort of shutdown request when, for instance, an OS is trying to reboot. I would like to have some control over how my applications handle these requests. But, I do not know where to start. Some questions I have are:
Do all shutdown requests come from the JVM?
Are the requests different for containers, VMs, and bare metal OSs? I am especially interested on how this is handled inside a docker container.
And, of course, what libraries can I use to handle these requests?
It would be wonderful if someone could point to a resource where this is covered in depth, besides the raw documentation, such as a book or online course (does not have to be free). Although, a link to the documentation will definitely be appreciated as well. Thanks!
Update:
I know I need to be able handle an event like the power cord being yanked.
However, when I ask my Windows machine to shutdown, sometimes a window pops up saying something like "waiting for these application to close". So, I assume the OS tells the applications to shut themselves down before forcing them to stop. Is this an incorrect assumption?
What I want to accomplish is for the app to log information or update a database before shutdown.
I will take a look at the addShutdownHook. Thanks again!
You can add a shutdown hook via the Runtime class. Mind you, these are not guaranteed to run, such as if someone yanks the power cord.
Refer Oracle Documentation

Background TimerTask gets killed when app is killed

I am using a passcode lock on my app. I set a varibale to true/false in shared preferences using the logic in this answer. But this approach doesn't work when I kill the app while still on foreground (using recent apps). Looks like killing the app kills my TimerTask which is scheduled for 2secs and hence the variable never gets set.
I have tried using services to do the same but no luck, even services get killed when the app is killed. Any workaround for this? Please help!!
You can use Service with START_STICKY, which will be recreated after killing. Check AlarmManager for events that will be launched by system even if your app is closed.
I personally suggest using the AlarmManager, instead of keeping long-running services.
The best way to execute background tasks in an efficient way is to use an IntentService
http://developer.android.com/reference/android/app/IntentService.html
An IntentService is going to run in a separate thread as long as the task requires and will be killed afterwards.
Also it will enqueue requests and deal with the queue itself

Using Timer.scheduleAtFixedRate() in Android

In my Android app, I need a certain bit of code to execute every minute, whether the phone is active or not.
(For those curious, the app is meant for a personal project, a "talking" clock which will need to check every minute if that time has a corresponding sound file to play. It's not something I plan to release to the world, so battery considerations are not in play.)
My current approach is to use Timer.scheduleAtFixedRate() to schedule a task.
This seems to work whenever I am looking at the app, and interacting with it occasionally to keep the screen from blanking, but if the phone turns the screen off to save power, it seems like my call happens sporadically.
I tried setting the interval to be every 30 seconds, but even then it seems like I miss some minutes. Are there specific considerations to using Timer on Android? Is there a better way to achieve what I need?
Question: are you 100% absolutely sure you need to be doing this every minute? It just sounds to me that you'll be hogging the battery like crazy and will get quite a few unhappy users.
But if you answer yes to that question:
After your activity is paused, there's not guarantee from the system that anything on it (including your task) will be kept running; that way as soon as the systems needs a couple of megabytes to do anything it will kill your activity and stop your timer.
You should implement the timer/task in a Service. Services are much less likely to be killed by the system and you might ask that if the system needs to kill it to re-created it as soon as possible.
Have you tried using AlarmManager, this will let you do a task every X amount of time even if the phone is in standby mode or off
Here are the docs for it
If you want a nice example of using an AlarmManager, here it is... This one does not work if the phone is turned off but you can enable this easily if you want

Prevent an Android application from getting closed/stopped

Is there some way to prevent the application from closing? Can I do it in the OnDestroy?
If your question is where you can prevent your application from being closed that is not possible. The system has the right to close when it runs on low resources or when the user wants to - through a task killer or the incorporated system in ICS.
OnDestroy just notifies you about that, you can't "revive" the application there.
You cannot prevent the application from closing as the kernel may force it to shut down if the device becomes low on resources. Normally, when the system is low on resources, the kernel will inform the application that it wishes to close it. Allowing the application to execute its onDestroy method and then close.
Your onDestroymethod can be useful for saving state. Here's a skeleton example:
protected void onDestroy() {
super.onDestroy();
//state is saved here.
}
However, it's worth remembering that you're not guaranteed that onDestroy() will execute. The kernel may or may not give it time to do so. You should check out the Activity Life Cycle for further information
Not sure what your question is, gonna try interpret it and i think this is what you need:
If you want your application to continue a process that it is running regardless of the application state, create a foreground service that will run the process instead, and can be binded to the application when needed.
http://developer.android.com/reference/android/app/Service.html

Android Keep Activity from Dieing

The main Activity I use in my Android application uses a fair amount of memory, meaning that on a less powerful phone, it is susceptible to being killed off when not at the front. Normally this is fine, but it also happens when I am still inside my application, but have a different activity at the top of the stack (such as a preference activity).
Obviously it's a problem if my application is killed while the user is still running it. Is there any way to disable the OS's ability to kill off the application for low memory problems?
Thanks.
No, there's no way. Your options are:
Read about Activity lifecycle and Activity and Task Design and implement these correctly and efficiently.
Use a Service.
It can't be done sadly. You see the linux Kernel will kill your application if it threatens the OS's ability to function. Sadly your application cannot prevent this. If it could I'm sure you can see the security implications of such things.
Sorry.

Categories