7

If a user is running my app and decides to kill it via the task manager, are there any guarantees about how much code will be executed before the process dies?

I feel like it could stop running at any arbitrary line, however I guess I don't really know the answer to this.

An example use case is for stopping and restarting a background alarm. If I wanted to cancel an alarm, do some work, then reset the alarm, I feel like there is a chance that the app could stop running after the 'cancel alarm' step but before the 'reset alarm' step. This would leave me in a state that I don't want to be in because I always want my alarm to be set to go off in the future. (Keep in mind this is just an example, I'm not looking for workarounds to this specific case).

Is there anything I can do to ensure that code my java code runs as a 'transaction' similar to a db transaction so that it either all runs or none of it runs?

neonDion
  • 2,278
  • 2
  • 20
  • 39
  • This may be useful http://stackoverflow.com/questions/11473849/android-app-doenst-call-ondestroy-when-killed-ics – Nanoc Nov 17 '15 at 15:17
  • 1
    In case your app gets killed with SIGKILL (which afaik happens on forcekill / low memory), your threads are simply no longer scheduled and your RAM "erased" (actually simply considered empty because writing 0s would waste time) so it can stop in the middle of a line of code. The kernel does some cleanup e.g. sockets & files (which are kernel managed resources) but only to the extend that resources are "free" for another process, not closed properly with remaining data written. https://www.reddit.com/r/AskComputerScience/comments/173o0g/what_actually_happens_when_you_send_a_sigkill_to/ – zapl Nov 17 '15 at 15:43
  • @zapl So it seems to me that there is no way to guarantee that state transitions in the app will take place. For example, if my app is running in State A and at some point gets a command to transition to State B, there's no guarantees that it will actually transition before it gets killed by the user or the OS. Is that correct? – neonDion Nov 17 '15 at 15:48
  • To some extend. Android provides all those lifecycle callbacks for that. Activities are guaranteed to be put into stopped(or paused?) state before they get killed for memory for example. And if you're only in the taskmanager, you already are stopped and activites most likely destoryed leaving only background services at risk. Manual force stop could kill you in any state though – zapl Nov 17 '15 at 15:57

1 Answers1

3

If a user is running my app and decides to kill it via the task manager, are there any guarantees about how much code will be executed before the process dies?

Not really. If the user elects to use Force Stop in Settings, your process is terminated immediately with extreme prejudice. In other situations where your process is terminated, Android usually will destroy outstanding activities and services, but that is not guaranteed either, particularly if Android is in a rush to free up system RAM (e.g., to handle an incoming phone call). Removing the task from the overview screen is not really distinctive here.

Is there anything I can do to ensure that code my java code runs as a 'transaction' similar to a db transaction so that it either all runs or none of it runs?

No.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • What about when the user removes the app from the 'Recents' UI? – neonDion Nov 17 '15 at 15:24
  • @neonDion: That is the overview screen. Removing the task from the overview screen is not really distinctive here, with the exception that if you have a running service, it's supposed to be called with `onTaskRemoved()`, though I am not sure if this is reliable. – CommonsWare Nov 17 '15 at 15:26
  • So it seems like if I have a few critical lines of code to run that it's best to run them from a Service or IntentService because those can be setup to restart and finish the job if they are killed. The appropriate action is probably heavily dependent on the application, but if you really need to ensure that something happens, it seems like Service or IntentService setup with the correct flags would give your code a high probability of being run. – neonDion Nov 17 '15 at 16:08