Introducer issues when generating a Dynamic library project for Android

#1

Hello

I'm trying to generate a shared library for Android. Using the introducer, the generated files seem a bit flawed.

1. whatever I set as binary name, the generated libraries are always called libjuce_jni.so

2. if I add x86 to architectures in debug and release, I'd expect 

APP_ABI      := armeabi armeabi-v7a x86

to be added to Application.mk. It isn't. And only the armeabi lib gets built as long as I do not add that.

3. The builder doesn't specify a toolset version. So by default eclipse is using the 4.6 toolchain. I need 4.8 because of c++11, but that only works after adding

NDK_TOOLCHAIN_VERSION=4.8

to Application.mk. 

All three items are easily adjusted manually, after which i can compile my library. But it's hardly an elegant solution since i have to redo them every time I save my project.

 

Regards,

yvan vander sanden

 

#2

Wow, I didn't expect anyone to try to build an android DLL - I've never even considered making it support that target!

If I had thought about it, I would have made it disable the option completely for android rather than trying to fix it, as I'm really not sure what would need to be changed to support it. It seems like such a niche thing to need that I can't really justify the time it'd take for me to make it work..

What exactly are you trying to do? Are you building something to integrate with another existing android app?

#3

I am working on a 3D sound engine: https://github.com/yvanvds/yse-soundengine Mainly because I'd like something cross-platform with extensive DSP functions and tools for interactive music.

And yes, it should be integrated with other programs as a library. I tried a static library at first, but that doesn't work since most game engines already include vorbis libs and such, and neither Juce or the engines have them put in a namespace. (I'm not making games but audiovisual artworks, which still makes them very attractive to me.)

People can of course include my code directly in their project, but i figure that it would be much easier if I can also provide libs and header files. 

About what it needs to support it: The three items i mention in my post above are enough to get the library compiled. I'm not able to run it yet, but I think that's mainly because of the way I include it in my test project. Android documentation is scarce on that matter, stackoverflow information not always current, and so on... Hopefully I will have figured it out in a few days :-)

 

 

 

#4

Ok, well I'm a bit busy right now, but if you want to suggest a few simple changes to the introjucer that would do what you need, I'd be happy to consider them..

#5

Ok, thanks.

Nevermind though. I turned out that the library crashed as soon as I started a threadpool. I implemented a treadpool of my own and that works, but now it crashes on AudioDeviceManager::initialise(). 

Since you pass information to the compiler like JUCE_ANDROID_ACTIVITY_CLASSPATH, I suspect the library needs that information while running. Which makes it impossible to use as a shared library. (Unless I recompile it for every program on its own, which defeats the idea of a shared libary.)

A pitty, because I've grown to like juce over the last months. Thanks for your time.

yvan