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

static

#1

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.


#2

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.


#3

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?


#4

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.


#5

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.


#6

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


#7

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


#8

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


#9

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


#10

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


#11

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.


#12

@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!.


#13

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


#14

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…


#15

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.


#16

Too bad… thanks for the update anyway!


#17

@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…