I think this has been asked before, but I really need to deal with this issue now.
On Android, it's currently not possible to separate Juce's GUI features from its core features. The main reason is because everything Android-related is linked to a Juce Activity. This makes impossibile to use the core features in a context where no GUI and Main Activity can be instantiated.
Now, since in Juce it's already possible to use those features on a BSD/linux platform, I would like to propose the following changes:
- remove linkage to JuceAppActivity (JUCE_ANDROID_ACTIVITY_CLASSNAME, JUCE_ANDROID_ACTIVITY_CLASSPATH)
- remove all JNI connections
- expose the necessary methods to configure Juce's environment as C or C++ functions (working directories, environment, etc.), so these can be called by another JNI bridge that isn't based on an Activity
Doesn't sound trivial, and even in the non-GUI stuff there are places where it needs JNI access to get/set other types of system information that aren't available via posix. If you want to have a go, good luck, but TBH it may be easier to tell juce that it's running on linux rather than android.
If I understand your remarks correctly there is no interest at all to support this kind of app?
This means it is not possible to have a native Android user interface while using JUCE for implementing everything else in a cross plattform library. That's a shame because I just wanted to start porting my app to Android.
It just sounds like a complex task.. A huge amount of functionality relies on having that special juce java activity class, so if you built it as a static lib and loaded into an app, then you'd need to make sure that class is accessible for it to be able to work. If you're happy to do that, then there's no reason why it wouldn't be possible.
