Application turns into background process after APP_CMD_TERM_WINDOW

[Ronnie van Aarle]

I am working on some OpenGL ES 2.0 Tutorials.

I wrote a small program that draws a triangle from a VBO in using GLES
2.0 with shaders, using native_app_glue.h.

The problem is, when I close the program, it remains active in the
background and I need to kill it using the debugger.

I don't use globel variables or anything like that, and in the engine-
>state I have only added on extra variable, GLuint mProgram, which I
delete and set to 0 after APP_CMD_TERM_WINDOW is received by the
application. Besides that, none of the variables from engine->state
are being freed or reset in the application NativeActivity, which I'm
modifying for building my examples on.

I don't know how I can find out if there is any data left behind,
which should be set to 0 or anything. Is there a way to enable some
kill flag or terminate option in the struct android_app* state which
is passed on to android_main by java.runtime.NativeActivity, so the
runtime know this process had ended and can be freed?

I thinks it is something in this javaclass that keeps the application
alive and not my source file, but thats just guesswork.

[Ronnie van Aarle]

I see this also happens with sample application NativeActivity.

[Dianne Hackborn]

This is how Android works.

http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Ronnie van Aarle]

Hi Dianne,

I am aware of these fact. However, but even after changing

case APP_CMD_TERM_WINDOW:
// The window is being hidden or closed, clean it up.
engine_term_display(engine);
engine->app->destroyRequested = 1; // RvA
break;

in function 'static void engine_handle_cmd(struct android_app* app,
int32_t cmd)'

and modifying this part of android_main'

// Check if we are exiting.
if (state->destroyRequested != 0) {
LOGI("DestroyRequested");
engine_term_display(&engine);
engine.animating = 0; // solved issue egl call to
window without context
running = 0;
return;
}

The process still exists in the background, despite the fact these
lines show up in logcat:

I/threaded_app(30523): NativeWindowDestroyed: 0x11a310 -- 0x143f28
I/threaded_app(30523): APP_CMD_TERM_WINDOW
I/threaded_app(30523): APP_CMD_TERM_WINDOW
I/RvA: (30523): DestroyRequested
I/threaded_app(30523): android_app_destroy!
I/threaded_app(30523): Stop: 0x11a310

The log entry ' android_app_destroy!' is definately created by the
function 'static void android_app_destroy' but still after this the
process is still runing in the background.

Eclipse TADP, set up the way I downloaded it from developer.nvidia.com
also does not install the .apk packages when I click run in the
developer environment, and also these running background processes
interfere with new builts of the applications that I am trying to run.

It might be because I'm running cyanogenmod, but I don't think so.
Everytime I try a new built after making some changes in the code I
have to:

- enable usb storage mode on the device
- manually copy the resulting libMyApp.so to the sdcard.
- disable usb storage
- use 'root explorer' to move the shader object from /sdcard to /data/
data/com.company.myapp/lib
- open 'process explorer', or use the remote debugger and kill the
last instance that I ran.
- clear the log

and only after repeating that entire procedure I can run the
application, to see if my changes have the desired results. Proper
shutdown procedures and apk installation from the IDE would probably
reduce the amount of time that I need testing and debugging with about
75%.

Thanks, Ronnie van Aarle.

On 16 sep, 17:59, Dianne Hackborn <hack...@android.com> wrote:
> This is how Android works.
>

> http://developer.android.com/guide/topics/fundamentals/processes-and-...

> hack...@android.com

[Dianne Hackborn]

Yes what you are describing is what that document describes.  Your activity is destroyed, but its (now empty) process remains around in case it is needed again.

If you use "adb install" (or the eclipse dev environment) to re-install the .apk, its current process will be killed at that point (and various other things cleaned up like alarms, notifications, any activity records, etc).

If you just want to kill the process, you can use "adb shell ps" to find it and "adb shell kill <pid>" to kill it.

That whole list of things you are doing about putting in a new .so is very odd.  Why are you doing that?  Why not just put the .so in your .apk so when you make a new version of your app you can just let the tools build it and install it and go?

hac...@android.com

[Ronnie van Aarle]

Well, I found a better way to install the .so in an .apk and the .apk
on the device, however, still not directly from eclipse. running from
eclipse does work, but only after 'ndk-build', 'ant debug' and 'adb -d
install -r /bin/app.apk' in cygwin.

How to configure eclipse's ADT and run configuration is still a
mystery to me, but at least now I don't need to step trough that
stupid routine anymore. I downloaded and installed this toolkit only
about ten days ago, so I'm still discovering new features every day.

I'm also glad to know that the process remaining active in the
background is not a side effect of me writing bad code so now I know
all I needed to know.

Thanks a lot for your time, its clear to me now.