Android.mk
While Application.mk allows you to specify variables common to your whole application, Android.mk is used to specify what modules you want to build and how to build them, all of this in excruciating detail. Table 2–5 lists the available variables in NDK revision 6.
Once again, we are going to focus on the few variables that have an impact on performance:
- LOCAL_CFLAGS
- LOCAL_CPPFLAGS
- LOCAL_ARM_MODE
- LOCAL_ARM_NEON
- LOCAL_DISABLE_NO_EXECUTE
LOCAL_CFLAGS and LOCAL_CPPFLAGS are similar to APP_CFLAGS and APP_CPPFLAGS, but apply only to the current module, whereas the flags defined in Application.mk are for all the modules. It is recommended you actually don't set optimization levels in Android.mk but instead rely on APP_OPTIM in Application.mk.
LOCAL_ARM_MODE can be used to force the binaries to be generated in ARM mode, that is, using 32–bit instructions. While code density may suffer compared to Thumb mode (16-bit instructions), performance may improve as ARM code tends to be faster than Thumb code. For example, Android's own Skia library is explicitly compiled in ARM mode. Obviously, this only applies to ARM ABIs, that is, armeabi and armeabi-v7a. If you want to compile only specific files using ARM mode, you can list them in LOCAL_SRC_FILES with the .arm suffix, for example, file.c.arm instead of file.c.
LOCAL_ARM_NEON specifies whether you can use Advanced SIMD instruction or intrinsics in your code, and whether the compiler can generate NEON instructions in the native code. While the performance can be dramatically improved with NEON instructions, NEON was only introduced in the ARMv7 architecture and is an optional component. Consequently, NEON is not available on all devices. For example, the Samsung Galaxy Tab 10.1 does not support NEON but the Samsung Nexus S does. Like LOCAL_ARM_MODE, support for NEON can be for individual files, and the .neon suffix is used. Chapter 3 covers the NEON extension and provides sample code.
TIP: You can combine the .arm and .neon suffixes in LOCAL_SRC_FILES, for example, file.c.arm.neon. If both suffixes are used, make sure .arm is used first or else it won't compile.
The LOCAL_DISABLE_NO_EXECUTE does not have any impact on performance in itself. However, expert developers may be interested in disabling the NX bit when code is generated dynamically (most likely to achieve much better performance). This is not a common thing to do, and you probably won't ever have to specify that flag in your Android.mk as the NX bit is enabled by default. Disabling the NX bit is also considered a security risk.
Android.mk can specify multiple modules, and each module can use different flags and different source files. Listing 2–15 shows such an Android.mk file, compiling two modules with different flags for each.
Listing 2–15. Two Modules Specified In Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := fibonacci
LOCAL_ARM_MODE := thumb
LOCAL_SRC_FILES := com_apress_proandroid_Fibonacci.c fibonacci.c
include $(BUILD_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := fibonarmcci
LOCAL_ARM_MODE := arm
LOCAL_SRC_FILES := com_apress_proandroid_Fibonacci.c fibonacci.c
include $(BUILD_SHARED_LIBRARY)
Like Application.mk, Android.mk can be configured in many ways. Choosing the right values for variables in these two files can be the key to achieving good performance without having recourse to more advanced and complicated optimizations. With the NDK always evolving, you should refer to the latest online documentation as new variables can be added in new releases while others may become deprecated. When a new NDK is released, it is recommended you recompile your application and publish an update, especially when the new release comes with a new compiler.
NOTE: Test your application again after you have recompiled it with a different tool chain (that is, the new SDK or NDK).