Aristarhys Aristarhys - 6 months ago 41
Android Question

NDK app onDestroy cleanup - how to DetachCurrentThread

So if we attach we must detach thread after after it finish, right?

JNIEnv* get_jni_env()
JNIEnv* res;
JAVA_VM->GetEnv((void**) &res, JNI_VERSION_1_6);//Using cached JavaVM
JAVA_VM->AttachCurrentThread(&res, NULL);
return res;

I call next native method from @Override protected void onDestroy() of my Activity class

void free_jni_manager()
JNIEnv* env = get_jni_env();
... //Here i delete global refs (jclass)

ERROR: detaching thread with interp frames (count=16) - main thread still running and we try to detach it.

Even if we take any function that use JNIEnv (for example calling java methods), putting DetachCurrentThread will cause same error.

DetachCurrentThread works flawlessly if used in pthread function

static void* thread_func(void* arg)
get_jni_env(); // attach new thread
//Do thread stuff
JAVA_VM->DetachCurrentThread();//thread done detached it with ok
return NULL;

Do we need detach main thread then we done with JNI, there do it? Or then activity will be destroyed, it will freed itself with JavaVM? Do we need do call DestroyJavaVM() (just doing crash if use onDestroy), how free cached JavaVM or garbage cleaner will handle this?

P.S. What benefits of using AttachCurrentThreadAsDaemon()


The Activity.onDestroy() method is called on the UI thread. Why are you trying to detach the Java VM from the UI thread? That thread is managed by the system, you should neither attach nor detach the Java VM from/to it.

The JNIEnv* is available to every native method as the first parameter. Why do you need get_jni_env() in the first place?

If you need a JNIEnv on worker threads, then you need to attach and detach (OR spawn a thread from Java; it's quite easy).

EDIT: If it's a repeat attachment, you don't need to detach. It's not a ref-counted system. AttachCurrentThread is documented as

Trying to attach a thread that is already attached is a no-op.

As opposed to requiring matched attach/detach calls.