from the error log:
I/fmod (32589): [ERR] FMOD_OS_Output_GetDefault : JavaVM::GetEnv returned -2.
FMOD source file/line number for the error is
The native code is getting invoked from the main application thread that the NativeActivity is running on.
It doesn’t seem like I’m doing anything crazy here but it’s not working.
Is there an initialization step I’m missing or something?
This application was working fine with FModEX. I upgraded to pick up the ARM64 support and have been having problems getting back to a running state since.
additional data point: calling system->setOutput to avoid the check for default output type lets the app get further along before failing but the log indicates the underlying issues are related to the JVM failing to provide environment info.
After a great deal of spelunking on the web & the error logs + some experimentation, a solution has been found.
It turns out that error -2 as returned from JavaVM::GetEnv() is JNI_EDETACHED.
Because native code launched via android.app.NativeActivity actually executes in a separate thread from the main activity thread and JavaVM methods can’t be safely invoked across multiple threads you need to use JavaVM::AttachCurrentThread()/JavaVM::DetachCurrentthread() to lock/unlock the VM for access off the main thread.
It is possible to detect the JNI_EDETACHED error in GetEnv() and use AttachCurrentThread() as a fallback case:
This does not appear to be happening in FMOD’s use of JNI. The answer was just to do something like this:
Please note FMOD will make JNI calls during runtime too, so it would be wise to keep the native thread attached to the Java VM. We plan to better document the attached VM requirement but have been reluctant to automatically attach user threads without their knowledge.