If you are a Java programmer and don't expect to be writing any native code (but want to know how to get the application to build and run correctly), then all you really need to know is the following: unlike the SDK, the Android NDK isn't automatically downloaded by the Jenkins Android Emulator Plugin so you need to configure Jenkins to pull this down into the build workspace yourself. There's a good case for a Jenkins plugin to do just that and I'm happy to write one - in which case, I'll update this blog with the details. In the meantime, it's fairly easy to use the Execute Shell and EnvInject plugins to do the job, like in this example:
You can find the correct download link for your target environment (Windows/MacOS/Linux) from the Android NDK Download page. Note how we use the built-in Jenkins $WORKSPACE environment variable to set a custom environment variable (ANDROID_NDK) to point to the location of the NDK install. Then all you need to do is add a custom_rules.xml file - the standard Android Ant build.xml contains a placeholder to include this automatically - that references it, like so:
That will cause the NDK build utility (ndk-build) to run whenever the project is cleaned/built. You can see the result if you look at the -pre-build Ant target in the console output of this example build.
Native Code in the DroidFish ApplicationIf you are interested in understanding how native code is actually used in the DroidFish application, open the DroidFish project (I have a copy on GitHub) using Eclipse/ADT and take a look in the DroidFish/jni folder - that's the default location for native Android code. Open up the Android.mk make files and you'll see that there are three native-code components, which get built in DroidFish/libs:
- stockfish: this is the main chess engine (the 'brain' of the app), which is built as a separate 32-bit ELF executable for the different taget architectures with the include $(BUILD_EXECUTABLE) directive and copied to the DroidFish/assets folder to be included in the .apk archive.
- gtb.so: this is a shared library that manages the Gaviota Endgame Tablebases - these are special databases which provide the computer with perfect information about every possible endgame with a certain number of pieces (http://en.wikipedia.org/wiki/Endgame_tablebase), built with the include $(BUILD_SHARED_LIBRARY) directive.
- nativeutils.so: another, smaller shared library that provides a couple of utility functions for setting permissions and properties for the stockfish engine.
Mark Prichard, Senior Director of Product Management