4

I have a simple app with native code. That is, an Activity plus native code.

When the activity is entering background, I keep the native code running to do some processing. The problem is when the activity is killed by OS (due to low resource), JNI code seems to have no knowledge of what happened in Java land and still doing its job, hence wasting resource. Why does Android kill just the Activity instead of the whole process? and in this case, how does native code know that the activity was killed? OnDestroy() may not get called.

Yi Wang
  • 552
  • 2
  • 7
  • 20

2 Answers2

2

You could have multiple Activities in one Android Application. As your Activities go into the background, they can be killed to reclaim resources. The application is typically kept around until the phone runs really low on memory, or the user goes and kills your app manually. The process sticks around until the application is killed, roughly speaking.

Because you can continue processing in the background, when your Activity is re-created you can check the status of your global variables and perhaps pick up where you left off.

Keep in mind that Activities are killed quite often, so there's not much point to doing processing in the background but stopping when the Activity is killed. You might as well stop when onStop() is called in this case.

krsteeve
  • 1,794
  • 4
  • 19
  • 29
  • You didn't answer the question "Why does Android kill just the Activity instead of the whole process?". For the NDK there are no callbacks being called in onStop, this is what the user asked. – RelativeGames Oct 10 '13 at 14:02
  • Ok, I updated my answer to try to answer this more clearly, thanks – krsteeve Oct 10 '13 at 14:31
  • Do you have a source for the "Activities, Application, and only later the process" destruction? I've [always had trouble getting info on that](http://stackoverflow.com/questions/8050003/details-of-android-application-components-destruction-and-recreation) (follow CommonsWare's link for even more confusion) – kaay Jan 03 '17 at 07:36
2

An Activity in an Android application is described in the documentation as

An activity is a single, focused thing that the user can do.

It is usually something that is visible on screen and has the user's attention. It has associated with it a state-machine that describes the life-cycle of being shown and hidden when another activity become active. The operating system is at liberty to start and stop activities as it choses - and memory permits.

In addition, a key point of the Android architecture is that activities and services are reusable software components and do not necessarily have a one-one relationship to processes. Inside the same process as your activity may be a service in use by another process in the system.

If the JNI portion of your code is still active in the background when an activity has received an onPause(), onStop(), onDestroy() notifications, it can only be because you haven't forwarded these messages to it. The system certainly doesn't know how to clean up native code's resource utilisation - particularly memory allocated with new() or malloc(). Unless you free it, it will only ever be recovered upon process termination.

If your concern is that your activity is not being killed fast enough by the system and as a result holding references to resources in native-land, it's a good sign that the system isn't resource limited.

You might consider implementing the native portion of your application as a Service and have it self-destruct after short periods on dis-iuse.

marko
  • 9,029
  • 4
  • 30
  • 46
  • Hi @marko I have relating issue about running native portion of application as Service. Can you suggest way to do this? As far as I know, the native part of application is called using intent on android.app.NativeActivity.class – bonchenko Jan 28 '14 at 15:11