After I created a Dynamic Library project for Android.
I can’t compile the project.
The error said undefined reference to ‘juceCreateApplication()’
and I want to create a Dynamic Library for my project.
I thought there will be only a juce_jni.so file.
but why still have a Juce Activity.
I just want to use the Juce Audio Modules,without GUI or other component.
Is there any way I can do that?
please help me ,thanks.
Right now a lot of the juce codebase relies on being able to call Java methods in the activity class in order to control a whole bunch of OS functionality. So it’s not really possible to just build a standalone .so file.
This is something we want to change, by rewriting all of these Java dependencies as embedded C++/JNI code, which would make this possible, but this will take some time, and won’t happen just yet!
Jules, that would be excellent, but if that’s not feasible right now, how about keeping the java stuff around, but just removing the restriction that the Juce java activity must be the android start-up activity? This is what is causing most problems : that we cannot provide our own start-up activity, preventing us from bootstrapping our own native Android GUI
If you could somehow allow the juce java part to be initialised from a user-provided java activity (eg by calling some java equivalent of juce::InitialiseJuce_GUI()), that would go a long way to solving the problem of using Juce as a headless audio library!
You can provide your own activity class - there’s a field in the Projucer to let you specify its name. Or does that not work for you?
eh, I understood it’s just the activity class name you can control there?, but the code for the java class is still generated by the ProJucer? Can it be used to replace this with a pre-existing start-up activity? That would be awesome
Yes, as long as your class has the right methods that the juce code needs to call, or if it inherits from our standard activity class then it’d work.
The problem I see is that often we’d want to inherit both from the Juce Activity and another class such as AppCompatActivity. Since Java does not support multiple inheritance it generally means adapting the generated activity which is a little fiddly and prone to headaches on Juce updates.
I can confirm this. For instance when using the CocosSharp (Xamarin) gaming framework the launch activity needs to already derive from another class - so there is no way to make it inherit the Juce activity.
Yes, that’s a java annoyance. But the method lookup is done by name, so as long as you give your class some methods with the same signatures as the juce one, it should still work.
Thanks for reply,jules.
but wha’t the solution for this compile error???
It’s the function that the android code will call to instantiate your app. If you’re not building an app, it doesn’t make much sense, but you may have to implement that function yourself and return nullptr to make things link.
Perhaps a more flexible system would be to use composition and declare a JuceInterface interface with all the necessary method names. Then implement that in a Juce class which becomes a member of the generated JuceActivity.
This way we could inherit from whatever Activity class we need and also use the generated Juce bridging code, without risking breaking things when we update Juce.
I’d be happy to send a PR when I get the time if this issue isn’t high on Team Juce’s backlog…
@Adam: sounds very sensible! If you’d like me to to test your code by calling it from a Xamarin launch activity let me know.
@mucoder please check my modifications: Modifications to JUCE Android implementation
Would be good to know if it works for your use case.