9a4548a (on develop), we have completely re-structured JUCE’s low-level Android code. JUCE’s Android support is now much more flexible, allowing you to choose which parts of JUCE you want to use for your app’s code/GUI and which parts you would like to implement natively.
Before this change, JUCE’s android support was substantially different compared to all other JUCE platforms. On all other JUCE platforms, it was always possible to only use just “a bit of” JUCE and write the rest of your app/GUI with native code. For example, on macOS/Windows/Linux/iOS, it was always possible to write a native app and only use JUCE for the audio engine part of your app. This was not possible on Android as JUCE would need to provide your app’s main Activity making it impossible to use JUCE without JUCE also providing all of the GUI.
This restriction had a big impact. For example, It was not possible to create JUCE android projects which did not use the
juce_gui_basics module. It also wasn’t possible to create Android libraries with JUCE, targeting apps which did not necessarily also use JUCE. And finally, the “
nativeWindowToAttachTo” parameter of
Component::addToDesktop was ignored on Android, making it impossible to embed JUCE components in a native view container.
To alleviate the above restrictions, most of the low-level native Android code needed to be re-written. Although no public JUCE APIs (any APIs listed on
docs.juce.com) have changed, this commit may introduce breaking changes if you used any of JUCE’s internal JNI helper macros (
modules/juce_core/juce_android_JNIHelpers.h) or invoked native android code directly. See more about this in this forum post.
If you want to know more about how you can now mix & match native and JUCE code/GUI elements, have a look at this post here.