0

As far as I can read, Android may kill my process at any time 1.

One might interpret the article [1] such that, at any point, a process must be able to survive a crash. How is that handled? Are there any guarantees of any methods being called if a process is killed this way? The article* doesn't mention it.

My question is, how do you guarantee that a force-killed process resumes in some sane way on next start? The only state my process has (assuming no guarantees are made for methods being called when process is killed) is the state in persistent storage (a DB or elsewhere) and this is likely to be incomplete if process is force-killed.

Concrete example: Let's say I ask a Service to perform some work. This work is not something like playing a music file. It is work that can be considered "done" at some point (e.g. sending data to the web). If my Service gets killed, say after 50% of the work is done, how would my app know if the work was successful? I could have a flag in persistent storage saying "done", but even then, Android might kill my Service after I send the last byte and before I set the flag.

Is there any common way of handling this? My Service could, when restarted, negotiate with the web server to see if the file was transferred, but it quickly gets really complicated and I don't think it would really solve the problem.

[Edit 1 start]

I am aware of the following text [1] but that does not solve the problem for services, "This last state is generated each time the user leaves that part of the application, not when it is killed"

[Edit 1 end]

[Edit 2 start]

I found something really interesting. An apparent inconsistency in the Android documentation related to this. Please see my new question at 2

[Edit 2 end]

[Edit 3 start]

The "apparent inconsistency" has been resolved. It was due to me not being precise about "app"/"process"/"activity" terms. This question still stands, though.

[Edit 3 end]

Community
  • 1
  • 1
jgreen81
  • 705
  • 1
  • 6
  • 14
  • That's why you should develop your app mindfully. Try to optimize it as much as you can and make it **light**. – Phantômaxx May 12 '14 at 13:38
  • My point is, if I'm correct then no matter how mindfully I develop, my app might be killed at any time. Even when in the foreground. I assume that I'm not correct and that there is some guarantees given by Android but I cannot find any. – jgreen81 May 20 '14 at 15:14
  • 1
    Well, `Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.` - So, don't make Android think YOUR app is memory consuming and you'll have more chances that OTHER apps are closed. – Phantômaxx May 20 '14 at 15:26

1 Answers1

3

Are there any guarantees of any methods being called if a process is killed this way?

Nothing is called on your app when your process is terminated.

how do you guarantee that a force-killed process resumes in some sane way on next start?

That cannot be answered in the abstract.

The only state my process has (assuming no guarantees are made for methods being called when process is killed) is the state in persistent storage (a DB or elsewhere) and this is likely to be incomplete if process is force-killed.

You should be updating your local persistent store when the data changes. Hence, your persistent store is likely to be up to date when your process is terminated. An in-memory cache should be treated as a read cache, not a write cache.

It is work that can be considered "done" at some point (e.g. sending data to the web). If my Service gets killed, say after 50% of the work is done, how would my app know if the work was successful?

It would have to negotiate with the Web server to determine what was and was not successfully uploaded.

Is there any common way of handling this?

There are various approaches for trying to maintain "transactional integrity", particularly for long-running operations where process termination poses a greater issue. None of those are unique to Android, as this has been a problem in computers for decades. Most boil down to "check what succeeded, and re-try what didn't". How complicated this is depends entirely on the nature of the data you are trying to update and the available means for updating it.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks. I'm puzzled that there aren't more resources about this. On a Linux PC you wouldn't expect your program to be killed unless power shuts down etc. On Android, it's part of the system design. That's why I think it's more important to be aware of it. Based on this article*, I actually read that, in rare cases, Android might kill any process, even a foreground process! * http://developer.android.com/guide/components/processes-and-threads.html – jgreen81 May 13 '14 at 12:26
  • I've edited the question to direct to this new question since I think one is about the state of apps and the other is about system design. Please see http://stackoverflow.com/questions/23801934/android-inconsistency-in-documentation-when-may-an-app-be-killed – jgreen81 May 22 '14 at 08:49