Develop Reference

Android Saving Images(with some processing) Optimal Method

I have obtained images from the camera and want to save it to a directory after some processing which takes about 10 seconds. I tried the following methods :
1) Asynctask(Problem : if the user closes(swipes) the app, the asyncTask is killed)
2) Intent Service(Problem : same as Asynctask)
3) Foreground Service(Problem : Hangs the UI of the application)
4) Running on UI Thread(Problem : Hangs the application).
So my question is what should I use to save my images(with some processing) such that all tasks are done even if app is closed and the UI does not hang(freeze).
Any help would be appreciated.

You cannot prevent Android from killing your process. If the user wants it killed (for example, using "force stop"), it will get killed. There is nothing you can do to prevent that.
When the user swipes the task from the recent tasks list, the behaviour is different in different versions of Android (and also different manufacturers have different behavour). However, in most cases, the OS Process hosting your app (including any services) is simply killed. If the app had a running Service that wants to be restarted, Android will create a new OS Process and reinstantiate the Service and restart it.
You can mitigate this a bit by putting your Service in a separate OS process. To do this, add android:process=":remote" to the <service> declaration. On some versions of Android, swiping the task from the recent tasks list will then kill the OS process hosting your activities, but NOT kill the OS process hosting your Service.
In any case you need to make your app robust so that it can handle being killed and restarted.

Thanks everyone for suggestions. How I finally was able to achieve this was using a foreground service which itself created and asynctask to perform the work in the background. I am a novice so don't exactly know how it's working, but it doesn't cause any app freezing/lag and does the work even if the app is swiped from the recent tasks list. (tested in Android L(5.1.1) and M)

Android process not terminating even after BroadcastRexceiver execution

Am using Network Change listener (in manifest) in android app, here i can observe once the app received any broadcast app process continues running even after completion of broadcastreceiver execution. I observed this behavior in debug build while connected to studio, is this is the behavior in the real-time also ?

Yes, this is expected. By triggering the BroadcastListener, Android system started the process of your app. It will then keep this process until it needs to kill it for resources.
This does not mean that any user-relevant components of your app (like Activities, Services etc.) are running in the background. Just the process, which is a "box" which houses all that :-)

Identifying the process on which my code runs

Is there a way to know which process my code is running on?
My app has two processes, one is the main process, the other process is used by an external SDK.
My custom application object is sometimes called from the other process.
I want to know which process is calling the application object.
Is it possible?

Android retain AsyncTask state/progress

In the app I'm developing atm. I use asynctasks to upload videos to a website, as it stands now if the application process is killed (User returning to home screen using the back key), those asynctasks are lost. ideally I would want the uploads to carry on despite the application process being killed, but I don't think that is possible.
I wonder if there is a way to retain their progress somehow (Maybe support from the website API is necessary?), or if not at least save the details of the asynctask and restart it when the app is opened again.
Vimeos application seems to have been able to resume video uploads, even after having killed the application process, thats exactly what I'm hoping to achieve.
Appreciate any ideas and suggestions.

I think you may be using the wrong architecture.
Anything that needs to survive in between Activity transitions is more suited for a Service. A service runs in the background (possibly even after the app is closed) and lets you do long running things such as performing uploads.
To kill the app process but have the Service continue to run, you can assign the service to a separate Android process using android:process in the manifest.
http://developer.android.com/guide/topics/manifest/service-element.html#proc
See this thread too:
How to keep a service running in background even after user quits the app?

Respond to kill requests by task managers

My situation:
I have created an Android service, which is started when the app is started. The service consists of a simple Thread that waits for 5 seconds, writes a log message and waits again.
After closing the application (using the back button), Android chooses to restart my service , because I am returning START_STICKY in OnStartCommand.
When debugging the application, I can actually use DDMS to kill the process. Android again chooses to restart the service. This is expected as per the manual.
I also installed a task manager, and used that to "kill" the instance. Funky thing, is that now my service is no longer restarted.
The funky thing is this: in either case, no destroy code of my classes is called. No InterruptedException is raised on my waiting threads. There seems to be no way for my application to know it's being destroyed.
My question:
How can I get around this, and respond to kill requests? I already noticed that the DVM lacks sun.misc.Signal and sun.misc.SignalHandler for proper signal handling (if that's even being used by task killers).
I kind of need to know wether my app is being destroyed, so I can properly close file handles, database connections and the likes.
Many thanks for any assistance.

How can I get around this, and respond to kill requests?
You don't. OTOH, this task killer behavior should have been eliminated in Android 2.2, so it eventually will not be a problem.