Vortex Runtime for Android
Eight years after my initial experiments with OpenGL via the Android NDK, there is now a fully-functioning Vortex Runtime for Android and Chromebook devices.

The Vortex Engine had not run on Android since November 21, 2011. When we recently decided to revisit support for this platform, it essentially required rebuilding the runtime from scratch.
The native App development scene on Android has improved significantly since back in 2011. The toolchain has been revamped to use CMake as the build system, Android Studio integration is tighter, and there are now even a few different options for architecting the App.
One possibility is to build the App as a NativeActivity. This has the advantage of keeping all the code in C/C++, with no need to develop Java, but I worry that it could limit access to some platform APIs. The other option is to build and package the native code into a shared object (.so), build a Java frontend App and have it call into C++ via JNI.
For the Vortex Runtime, we decided for the latter. A thin layer of Java code was built to handle the interactions with the platform and creating the OpenGL ES 3 framebuffer and context. This layer is also responsible from loading the shared object with the Vortex Engine code.
Engine Interface
The key component for calling into the native engine code from Java is the EngineInterface class. This class, written in Java, acts as a front controller and a facade for the engine.

This facade is backed by EngineInterfaceBackend C++ class. All requests to the engine are forwarded to the backend via JNI. Once in C++ land, we have access to the full engine.
It is worth mentioning that there is a thin procedural Android Bridge between the EngineInterface and its native backend. This allows us to use the C bindings to JNI and it’s a good place to hold the pointer to the backend object instance.
From the Java App’s perspective, the Engine Interface is responsible for unpacking Vortex Archives, setting up the script execution environment, running the simulation, handling events, and rendering the world.
Big Endian vs Little Endian
One thing to keep in mind when passing data as arrays of bytes from Java to C is that the JVM is a Big Endian machine. This is important, as both Intel and ARM CPUs will be running in Little Endian mode, so byte conversions need to be made when passing bytes through JNI.

It begs the question of why the JVM is Big Endian when the underlying platform is Little Endian. I imagine this goes back to the old days of Sun Microsystems. Back then, Sun’s Hardware, the SPARC, was a Big Endian architecture. It’s possible that the JVM was defined as a Big Endian machine to avoid having to alter the byte order when passing data from Java to native on their own hardware. Nowadays, of course, we need to account for this discrepancy in data representation.
Conclusion
In addition to iOS, we now have a Vortex runtime for Android (and ChromeOS) as well! We can now create a playground visually on the Desktop and deploy it on Android for a true what-you-see-is-what-you-get experience.

Ironing out all the smaller details around the platform differences that Android has with iOS and Windows ended up being the majority of the work. The Architecture we chose allowed encapsulating and calling into the native Vortex code from the Android Runtime App in an elegant and extensible fashion.
It was truly something seeing the Android runtime come together and the engine running on a platform it had not visited for 8 years.
Now that we have the ability to author our playgrounds in the Editor and run them on both iOS and Android, we can shift our focus to the renderer and continue pushing the visuals.
Stay tuned for more!