I’ve been reading about how to build a Juce project for Android, based on this link. I have yet to try this with Android Studio, but the rest of my builds are configured with CMake, so i was wondering if anyone has found a way to cross compile to Android using CMake? Is the process scriptable at all?
Atsushieno (whom you can find on The Audio Programmer Discord server) wrote about this topic in: JUCE + CMake + Android, now works
I have to admit I didn’t give a deep look at it yet.
Oof, certainly not the short read I was hoping it would be.
My ultimate dream is to be able to write a single shell script that can execute the Android cross-compile on a CI machine such as GitHub actions, but it seems this will be a much more involved process.
Perhaps I’ll wait and see if Reuk has any more gifts in store for us CMake lovers in the next few months…
I’ve read it (briefly). But it seems this solution isn’t integrating with existing CMake support in JUCE.
It basically modifies JUCE and the Android Studio CMake to work together.
But in terms of cross-platform holy grail of singular CMake project (even with branching) it isn’t adding the desired ability of the JUCE CMake support to cover Android.
There was discussion on this topic in the TAP discord, but to recap it seems to be what I’d call an “inversion of control” problem unique to Android. It would be essential to first design how a solution might work in this case, due to this problem:
- CMake abstracts away target platforms, so you can pick your platform based on say, a preset which indicates a native or cross-compilation toolchain to build with
- Android seems to produce an automatically generated CMakeLists.txt as a result of configuration via gradle, which inverts the control logic that is normally used in CMake (i.e. generators that generate IDE projects for Xcode, Visual Studio, etc.)
At first glance, it might appear that due to the above, the best bet would be if the CMake team were to make available an Android Studio generator, but I am sure the CMake team would find this obtuse, since it would effectively need to generate a gradle file (set), which would then in turn just make another auto-generated CMakeLists.txt!
So hopefully my explanation at least illustrated what a tricky problem this actually is, all stemming from the fact that Android inverted the control logic when they paired gradle and CMake together way back when. The mistake is understandable as CMake just handles the “native” portion of an Android build, it doesn’t address the managed code layer above and JNI bindings at all.
Interestingly, the equivalent language barriers on iOS don’t represent equivalent eccentricities in their build system, Apple really did a better job than Android on that one.
Thanks for summing this up so succinctly.
I’m still somewhat unclear on the overall Android compilation process, because the NDK does provide a CMake toolchain file…
So is compiling to Android simply not possible without using Gradle?
You can compile a static or dynamic library using the CMake toolchain file available in the NDK no problem.
The problem starts when you need to do more than that, building a full Android application with a GUI…
I see. Thanks for the info!