0

This is a follow-on to an earlier post today. If you create a persistent thread (Eg, for network activity every 15 seconds), is there a way you can guarantee its destruction when the app terminates?

I suppose this question can be generalized: when an Android app dies, is there any way you can guarantee a body of user- or application-logic to execute?

Community
  • 1
  • 1
Kode Charlie
  • 1,297
  • 16
  • 32
  • 2
    You need to be clear about what you mean when you say "an Android app dies". If the process dies, the thread dies with it, and there's no opportunity for any code to run. – fadden Jul 07 '15 at 20:30
  • Good point. What I mean by termination or death of the app is whatever "normally" happens when the Android OS decommissions an app's process, and takes it out of the execution cycle. It doesn't sound like the app can set up a signal-handler to intercept the termination directive and execute application code therein. – Kode Charlie Jul 07 '15 at 20:46
  • Indeed in Android you can not intercept a signal when a process is going to die, so you must be proactive about it. – BladeCoder Jul 07 '15 at 21:05
  • @KodeCharlie of course, else it would be a massive security problem! – Martin James Jul 08 '15 at 04:10
  • @MartinJames do you have online references that explain the security concerns here? Thx. – Kode Charlie Jul 08 '15 at 15:07
  • No, but it seems intuitive that, if you want an app to die, you should not allow any means for it to continue execution - you would have an unkillable process, really nice for malware. – Martin James Jul 09 '15 at 12:36
  • @MartinJames without public-domain references subject to community scrutiny, it's hard for me to accept your blanket claim that a signal-handler for exit-time execution logic is a "massive security problem". Publish your analysis, and let's see how the community responds. – Kode Charlie Jul 10 '15 at 15:54
  • What? If you want me to compile and pubish an analysis of logical deduction, you will have to pay me. Does it not seem obvious that, if a process is terminated from outside, eg. with Task Manager or kill-9, that all its threads must have execution removed from them without 'notice'? If some thread was left to run a signal-handler, it could start another copy of the same process; the one you are trying to terminate. – Martin James Jul 10 '15 at 16:13
  • For instance, it seem that fork() is valid in a signal handler:( – Martin James Jul 10 '15 at 16:17
  • @KodeCharlie so, since I have a logical argument on my side, I suggest that the onus is on you to explain how a signal-hander, or any other process code, that is run on an out-of-process termination could be made safe if the process was malware. – Martin James Jul 10 '15 at 16:22
  • @KodeCharlie There is always a way to achieve what you want in Android, even if you don't get notified when a process is killed. For example you can schedule background work by sending Intents to a Service. If the Service gets killed you can ask the system to restart it as soon as possible and the last unprocessed Intent will be redelivered to it automatically. Another example is the AlarmManager which will send an Intent to your app at a given time and this will restart it if it was previously killed. – BladeCoder Jul 10 '15 at 17:03

1 Answers1

0

On all non-trivial OS, process termination begins when a thread of the process requests termination, or another process with the appropriate permissions and privileges requests termination.

One of the first steps in process termination is to remove execution from all the threads, no matter what state they happen to be in. This is essential to prevent the threads allocating any further resouces to the process and to prevent them from actively using the rsources that are already allocated. Threads that are not currently running have their state changed to 'never run again'. Threads that are running on cores are stopped by a hardware-interrupt of the cores running them. Once all the threads are stopped, the kernel can start releasing resources like fd's, memory-segments etc.

A out-of-process temination cannot be allowed to run any kind of 'onTermination' code that belongs to the process. In such code, even a simple infinite loop would prevent process termination and tie up a core indefinitely. Other possibilities for malicious action are obviously possible.

This can result in problems with resources that are shared with other processes or systems. One way of getting round this is to design your app so that any 'left over' connections, partially-written files, shared memory stuff, whatever, are cleaned up on process startup, instead of process shutdown.

Systems should be designed so that they do not absolutey depend upon 'clean' shutdowns and can recover successfully from events like critical segfaults, out-of-process terminations, power failures, coffee-spillage and frothy beer-cans.

Your app-lifetime threads will be terminated upon an out-of-process termination. You can detach them so that they will be terminated upon an in-process shutdown, (and you should design to make that termination as safe as you can without relying on any 'onTermination' signals/handlers/whatever, since exploding beer cans do happen).

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • Thx. That clears up a lot. I could still see some real value in exit-time logic -- logic that could be "scrubbed" by the compiler and/or JVM of potentially malicious calls (Eg, a fork()). – Kode Charlie Jul 10 '15 at 16:43
  • Sure, just like there is real value in uninstalling AV scanners and firewalls - they use up CPU and add network latency. – Martin James Jul 10 '15 at 17:02
  • Actually what prompted my posting the question is that iOS actually does provide an on-termination callback (see https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplicationDelegate_Protocol/index.html#//apple_ref/occ/intfm/UIApplicationDelegate/applicationWillTerminate:). – Kode Charlie Jul 10 '15 at 19:32
  • Well, at least it has only five seconds to clone itself or destroy your file system. – Martin James Jul 10 '15 at 23:03
  • Reports (see the book "Future Crimes") indicate that 99% of mobile malware afflicts the Android platform. This statistic begs the question of why Apple has gotten away for years with on-termination callbacks. I don't know Android well-enough to know the pros and cons there. But if the Apple iOS team sees value in on-termination callbacks and continues to support it, I don't think it's such a bad idea. – Kode Charlie Jul 11 '15 at 03:24
  • The iOS environment is not open, and I'm pretty sure that Apple are quite good at examining/testing OnTermination handlers within their App Store approvals process. – Martin James Jul 11 '15 at 14:00