So being a primarily c/c++ developer, I've always thought that the only option for mobile game development for me was using iOS, which allows for c/c++ (and minimising objective C).

I heard from a friend though, that android has a native development toolkit which allows for c++ code to work on android.

Has anyone used this, and if so, how do you find it? I mean, will it "just work" like iOS, or are there more considerations that need to be taken care of due to the wide variety of android devices available?

3 Answers
3

for android 1.5 devices, you can load an elf library and uses it from the java application via a JNI bridge

for android 2.3 devices, you can use a NativeActivity to bypass the Java Activity code for Fullscreen Application.

The NDK offers few C/C++ API:

a pseudo libc called bionics: many functions aren't availabled

a pthread library

OpenGL ES 1.x (>Android 1.5) and OpenGL ES 2.x (Android 2.0)

OpenSL (limited support on Android 2.3)

But many API are Java only (also available via JNI).

NDK 5 version is the first usable for C++ developers because it offers:

RTTI

Exceptions supports

STLport

gdb support for multi-threaded programs

The most painful operation is debugging on android devices. So i develop my own multi-platform framework (OS X, Windows, Linux, iOS and Android) to debug first on desktop platform, next iOS platform (on Simulator) and Last (Android).

The android Emulator (not a simulator) have a poor performance and can't emulate OpenGL ES 2.x. I recommend real devices to develop.

I have successfully used the Android NDK to port two SDL + OpenGL games to Android and found it surprisingly easy. I have a 200-line Java wrapper that creates the GL context and provides utility classes such as input, sound and image loading for the C++ code to call back. The "San-Angeles" sample program in the NDK is an excellent starting point.

By the way, it is possible to build C/C++ programs without a line of Java, but I find it convenient to access some OS-level methods by calling back the JVM from time to time.

I think if your game already compiles on Linux, you will feel at home. Out of 100+ files in my current project, only 4 have an #ifdef ANDROID_NDK directive (the image and sound related classes).

In fact most of the time spent porting the game was because of a known emulator bug that I wasn't aware of.

\$\begingroup\$Earlier in the past I have had (frustrating)issues trying to get the simple pipeline of compile/build/deploy my opengl game on android emulator. Can you point me to a resource or something which I can use? (I don't know if you have those utility classes open source, but if you do, I'll be interested in seeing them.) Thanks\$\endgroup\$
– brainydexterMar 4 '11 at 17:37

1

\$\begingroup\$@brainydexter: I am a commandline guy who enjoys the autotools, so I'm not sure I'll be very helpful to you, but my pipeline is as follows: ensure ANDROID_NDK_ROOT is set, that it is in $PATH (together with [sdk_location]/tools and [sdl_location]/platform-tools); go to the project directory; compile the NDK code using ndk-build; compile the Java code and build the package using ant compile; upload to the emulator or connected device using ant install. As for opensourcing the engine, I have not decided yet, but I am already publishing code on the blog\$\endgroup\$
– sam hocevarMar 4 '11 at 21:36

\$\begingroup\$Thanks for the link! I'll keep an eye out for your blog.\$\endgroup\$
– brainydexterMar 5 '11 at 7:23

Android has supported native applications since version 1.5 through Android NDK, which should cover your target audience very well. You still need a simple Android Java application that loads the native side of your application through JNI and passes forward e.g. input and render calls.

There has been several versions of the NDK, but you can use the latest NDK and select the target API you want to support. Since Android version 2.3 you can do a lot more on the native side and need less Java code, but the device support for 2.3 is currently very limited.

Native Android C/C++ development is a working solution at least for fullscreen games and the effort needed to port existing C/C++ OpenGL ES applications is quite small.