0

There has been instances where we need some code must be executed at the end no matter what happens to the application. Is there any way we can achieve the finally() functionality in Android?

Note: OnDestroy will not be called during the crash.

For the matter of fact even finally() is not a full proof method when the JVM exits. But in Java we do not see too many JVM exits. But in android since we have a DVM for every app process, we need a way to execute the final code else, we end up leaking the memory and battery consumption shoots up.

blganesh101
  • 3,647
  • 1
  • 24
  • 44
  • memory is managed by the garbage collector. – IAmGroot Jun 27 '13 at 17:48
  • Well, app runtime memory is managed by garbage collector but not the native level memory. It is managed by the kenel. – blganesh101 Jun 27 '13 at 17:51
  • @blganesh101 - memory belonging to a crashed process is released by the kernel upon death of the process. – Chris Stratton Jun 27 '13 at 19:39
  • Looks like we are using the word "leak" very loosely here. @blganesh101 seems to be referring to the fact that a process that was started by his process continues to run (seemingly in an uncontrollable fashion), which is continue to occupy memory and resources. There is no 'traditional leak' in the original process, which would have all been claimed back once it 'died'. – Kumar Rangarajan Jun 28 '13 at 03:28
  • So true. Not the leak at the app space but at the system level due to app misbehavior – blganesh101 Jun 28 '13 at 04:19

4 Answers4

1

Your best bet would be to run the cleanup operations in the onPause() of every Activity individually.

There is nothing like finally() in Android, as when an app crashes the entire process is simple terminated. Even normal methods like onPause() aren't called. Everything included in the process (Activities, Services, Receivers, Threads etc) is completely killed.

Raghav Sood
  • 81,899
  • 22
  • 187
  • 195
  • So that leaves with no option on Android right. How else can we deal with the situation of accidental memory leaks? – blganesh101 Jun 27 '13 at 09:06
  • You can set a Thread.UncaughtExceptionHandler on each of your threads to catch all your exceptions in one place and perform clean up operations. – Raghav Sood Jun 27 '13 at 09:07
1

You can't leak memory when the application/vm crashes or is killed. In that case, the process is gone and any memory associated with it is gone.

If you are talking about allocating and freeing memory that's in a different process, you can get a Binder from the consumer process, and then use the Binder.linkToDeath functionality to receive a notification when that process dies.

JesusFreke
  • 19,784
  • 5
  • 65
  • 68
  • In few situations there's a memory leak. For example when I m opening camera and my app crashes, then camera does not get closed and the driver just hangs leaking the memory continously till we restart a phone. Camera is just an example there are so many native services which behave like this. – blganesh101 Jun 27 '13 at 17:31
  • Curious to know how you detected the driver hanging or do you mean the camera app opens up and never closes (which the user can close if needed). – Kumar Rangarajan Jun 27 '13 at 17:36
  • Well very simple. When we open the camera and the app is killed. We try to launch the camera again and it would never launch till we restart the device. – blganesh101 Jun 27 '13 at 17:48
  • 1
    I do believe I recall hearing about a **bug in the framework camera code** along these lines. If that is what is being discussed, the issue would be more one of working around a faulty Android release than of anything else. – Chris Stratton Jun 27 '13 at 19:41
  • This seems to the best possible explanation to this issue. And unfortunately the solution I assume is to make sure the app does not crash (easier said than done), or have handlers in the native code segments which would do some cleanup (like the classic signal handlers or atexit handlers, which I assume can be registered from native code) – Kumar Rangarajan Jun 28 '13 at 03:31
1

I am not sure what you mean by a leak here when your original process is anyhow not running.

Still one thing we did to handle such scenarios is to have a 'watchdog' process, though we had to do this in native code running in Android.

In your case, you could potentially create a service and make it run as a sperate process by specifying the

android:process=":remote"

flag in your manifest file. Now that service can potential watch for the main application process and do some cleanup if possible. Ofcourse you would need a way for the service process to know about which elements to clean up.

Hope this helps.

Kumar Rangarajan
  • 431
  • 2
  • 7
0

There are various ways to die:

  1. Killed by system. Shouldn't happen while you're in the foreground, so make sure you close stuff as part of the Android lifecycle.
  2. Fatal exception. You can deal with this by using a global uncaught exception handler. See Ideal way to set global uncaught exception Handler in Android
  3. Native crash. Not much you can do about this. In some cases you can try to recover with a signal handler, but the app will be in a very uncertain state, so it's generally a bad idea and unlikely to work.

Looking through some of the other comments, it sounds like your device has a bug in the Camera driver that is causing it to be held open even after the process that opened the camera has died. This is a system bug -- the app shouldn't have to manage system resources when it crashes. (But, until it gets fixed, you've got to work with what you're got.)

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • Well, i have observed this behavior in most of the phones. Yes, i understand this is a issue to be dealt with the camera driver per se but from an application developer there is nothing much we could do. – blganesh101 Jun 28 '13 at 04:17