JNIEnv not initialized when building an Android Library (AAR) out of a Juce project

Hi,

I am trying to build a dynamic library for Android that would be based on Juce so that I can link it with a ReactNative project.
The goal is to export some native functions with JUCE_JNI_CALLBACK so that they can be used in the React environment to use Juce audio engine.
It works great but as soon as I call the first method I’m encountering a SIGSEV. It seems that something tries to call getEnv in juce_android_SystemStats.cpp and that the JNIEnv pointer isn’t set yet.*

A little bit more about the context.
As you know Jucer isn’t really compatible with a dynamic library project and the Android platform.
It will create an app project and not an AAR one. Therefore I’ve manually changed the gradle so that it builds a dynamic library (apply plugin: ‘com.android.model.library’) and also removed the MainActivity that the Jucer pre-generates. I assume this is not calling some of the initialization lines that are mentioned in this thread:

I’d really like to avoid writing a Dummy app but perhaps I could make sure the the relevant variables are initialized manually during the initialization of my library. How could I do this properly?

PS: I’m still on Juce 4 btw but afaik Juce 5 still doesn’t support the dynamic-library type for the AndroidStudio output either.

Yes, this is expected. If you run your app in the Android Studio debugger you should have hit this assertion. Just call setEnv on the thread before calling any JUCE functions.

Ok I did this but now I’m running into another crash.

I think it’s because the generated Juce MainActivity is never reached and therefore the AudioTrack object might not be properly initialized. Could you confirm?

05-09 22:31:20.793 18211-18420/com.awesomeproject A/art: art/runtime/java_vm_ext.cc:470] JNI DETECTED ERROR IN APPLICATION: CallStaticIntMethodV received NULL jclass
05-09 22:31:20.793 18211-18420/com.awesomeproject A/art: art/runtime/java_vm_ext.cc:470] in call to CallStaticIntMethodV

As I’m linking my AAR in a project that already has a MainActivity I wonder how could I easily turn this Juce Activity into something else that would be initialized when the main application starts. Isn’t the purpose of the Android.Service class?

Step by Step. Ok now after setEnv I call JNIClassBase::initialiseAllClasses (env) and I’m now really reaching the problem as at one point it tries to call a Java method of the MainActivity… that is not yet initialized.

You cannot use JUCE code without also using JUCE’s generated Activity class. You will notice that JUCE will automatically generate a .java file in Builds/Android/app/src/main/java which contains the necessary methods when you save a standalone GUI project. Make sure that all these methods/classes are included in your activity class.

It’s not that easy as I do not want to mix up my react activity directly with the generated JUCE activity. Actually I’m a bit disappointed that JUCE 5 doesn’t come with such modularization. This is a major gap to use JUCE in the Android environment.

For instance, @adamski has made a very promising work by creating a bridge that can be encapsulated into other activities. It is very close to what we need. His work is available here

FYI I need to rebase my fork to the recent changes in JUCE 5. This will happen soon!

@adamski that would be great then we might use your fork. Why not proposing your changes to the Juce team though?

I sent a pull request last year. However, they have decided to go a different, and ultimately better route.

@adamski good to know they are working on it thanks to your initiative.
Any further insight @fabian by any chance? :slight_smile:

All I can say is that we are aware of this issue and fixing this is definitely on our backlog. However, don’t expect a fix anytime soon.

@fabian I appreciate the transparency although I’m sad to hear that there isn’t so much momentum behind it apparently as of now Thank you!.

@fabian, any news on this? This would be definitely interesting for many people and in many cases a showstopper for introducing JUCE…

Hi @adamski, can you tell us anything about that better route, as we cannot see any comment about it in the PR…
Working on a RN project, we currently have your promising, but outdated project as a base or we can hack our own solution - both doesn’t make too much sense when Roli decided to go another way…

I can only repeat what we have already said: we are actively looking at this issue and of ways to fix it. But we don’t make any timeline promises.

Too bad… thanks for the update anyway!

@harryg as @fabian stated, it’s being worked on, and so far the solution will be similar to what is in my now outdated fork. Basically, hold tight, its in the pipeline…