Note – I (Brian Heim) am posting this on behalf of Tim Weber (@scy, https://gist.github.com/scy). Apparently new users aren’t able to post more than 2 links in a single post. Everything below the dotted line is his.
This is supposed to be posted on the SC forums at scsynth.org, but I ran into the spam filter and want to go to bed right now. Saving it as a Gist in the meantime.
I’ve been thinking about using SuperCollider on my phone. There’s glastonbridge/SuperCollider-Android which hasn’t been touched since 2014, so I thought I’ll try to build a current version from source, based on the guide for Linux. Also, since Termux provides a great Linux CLI environment, including build toolchains, directly on the device, I wanted to try building SC under Termux.
Spoiler alert: I didn’t manage to do it. The main problem is not having an audio driver, since the Linux build requires libjack, and neither Android nor Termux provide it. (Termux has the libpulseaudio package, but that won’t help us here.) After asking around in Slack I was asked to note down what I did and how far I got here in the forums, maybe somebody else wants to pick up. I probably won’t find the time in the next couple of weeks, and even after that it’s unlikely.
I should point out that there is nine years old code that introduced an Android driver to SuperCollider, but according to Brian Heim “it doesn’t work and hasn’t worked for years” and “we don’t make any effort to support it”. Also, as far as I understand the code, it’s meant for running SuperCollider inside a normal Java-based Android app.
Nevertheless, if you install Termux and get the necessary build tools …
pkg install build-essential cmake fftw git libsndfile
… clone the project and create a build dir …
git clone --recurse-submodules https://github.com/SuperCollider/SuperCollider.git \
&& mkdir SuperCollider/build \
&& cd SuperCollider/build
… and then try to build with …
cmake -DCMAKE_INSTALL_PREFIX=~/sc -DAUDIOAPI=coreaudio -DSC_QT=OFF -DSC_HIDAPI=OFF -DNO_X11=ON -DSC_ABLETON_LINK=OFF ..
make -j3
… you can actually get quite far. (I’ve also added add_definitions(-DSC_ANDROID) to CMakeLists.txt, but I’m not sure anymore whether that was required.)
Of course, -DAUDIOAPI=coreaudio (the macOS/iOS audio API) is wrong, but if you don’t provide -DAUDIOAPI, it will default to Jack and instantly fail because it can’t find it. By using coreaudio, your build should at least get up to the point where the linker fails, telling you that -f may not be used without -shared. I believe that’s because when building for coreaudio, SC uses a -framework flag in its linker call that’s probably supported on Apple devices, but the Termux linker interprets it as -f with a bunch of additional stuff and gets confused.
Maybe making it work would be as simple as allowing a new AUDIOAPI value like android that would then set the -DSC_ANDROID C macro, which in turn uses the old Android driver, but I doubt it.
Instead, my approach would be to look at termux/play-audio’s code as an example of modern, high performance OpenSL ES Android audio output under Termux and then write a new SuperCollider driver based on it. That’s possibly all there’s missing.
If somebody wants to continue based on what I’ve found out: go for it! 
Let us know how it worked out. Termux would surely be happy about a supercollider package, and me too. 
but not there yet. I do not feel confident I can do a lot if the issues are down at the portaudio layer, but I want to try! My dream is pairing up my Teenage Engineering OP-Z with SuperCollider running on Android for livecoding SynthDefs and controlling them over MIDI for fun on the go