1

Suppose I have a BroadcastReceiver registered in manifest, and my app is not active. So the new process will be spawned and onReceive() method of BroadcastReceiver would be triggered on the main thread of this new process.

Now, I spawn a thread from onReceive() method (I know that it is not recommended and Service should be used to prolong the process lifetime beyound onReceive()).

I'm curious would the spawned thread (let's assume it runs indefinetely) keep the process alive? Thinking of JVM it should, as JVM wouldn't exit until there are active non-daemon threads. And what about ART? ART is not JVM, it is a compiler, and the behaviour of the compiled application may be different, like killing the process and hence all the threads irrespective of whether they still run or not. Does anybody has the insights into this situation?

Kurovsky
  • 1,081
  • 10
  • 25

1 Answers1

1

It's all up to the runtime environment and the OS. Whether a code is compiled or interpreted will not affect a kill decision for the process/app.

Long version:

Just to clear some things up: ART is not a compiler. It is a runtime environment. dex2oat is the compiler driver. And if I understood your scenario correctly, a broadcast is delivered to the OS, which starts your application. And in the onReceive method you launch a thread.

An application might not be 100% AOT compiled. This means that a few parts will be interpreted by ART, while most will be natively executed, still by ART. So ART, is a runtime that also has an interpreter. The decision whether to kill or not a thread in a broadcast handler, it does not depend whether the code is natively executed or interpreted. The OS might decide to kill the process when the memory is low, or the runtime to interrupt its execution if it detects that it runs forever, etc.

So, don't worry about compiled code, just play nicely with the OS (Services?).

Paschalis
  • 11,929
  • 9
  • 52
  • 82