We have already seen the differences between an Android application and an Android game. The Android SDK is very capable of taking care of both. Certainly, the question that arises is "What is the requirement of a separate development toolset in native languages such as C and C++?" Compared to Java, C and C++ are much more difficult to manage and write code in. The answer lies in the question itself. The Java architecture runs on JVM, which is associated with the Android operating system. This creates an extra latency, which has a performance lag. The scale of the lag depends on the scale of the application.
A highly CPU-intensive application may cause a significant amount of visible lag in Java architecture. Native language code can be processed faster. Moreover, native code can be varied depending on the CPU/platform architecture, which is not possible in the case of the Java architecture used by the Android SDK.
Android uses the OpenGL rendering system. So, an application made in OpenGL can also choose Android as the target platform. Native code helps directly structure the application using OpenGL.
We will have a detailed look at these aspects in this chapter through the following topics:
- Introduction to the 3Android NDK
- C++ for games—pros and cons
- Native code performance
- Introduction to OpenGL
- Rendering using OpenGL
- Different CPU architecture support
Android is actually based on the Java architecture. However, part of an Android application can be developed using native languages such as C and C++. This is where the Android NDK comes into the picture.
The Android NDK is a toolset used to develop a module of an application that will interact with hardware much faster. It is a well-known fact that C and C++ have the ability to interact with a native component directly, which reduces the latency between the application and hardware.
An Android native code segment interacts with main application through the Java Native Interface (JNI). The Android NDK comes with a build script that converts native code into binary and includes it in the main Android application.
This binary is basically a native code library that can be used in any Android application as per requirement. An NDK build script creates .so files and adds them to the application path.
The Android build process creates Dalvik Executable files (.dex) to run on the Dalvik Virtual Machine (or ART) of the Android OS. The Java executable recognizes the native library and loads the implemented methods. The native methods are declared with the native keyword:
public native void testFunc (int param);
The method always has public access, because the native library is always treated as an external source. Here, the developer should always keep in mind that there should never be multiple definitions of a method for the same declaration collectively for all the included native libraries. This will always create a compilation error.
The native building process can build the native project into two types of libraries:
- Native shared library
- Native static library
The native build script creates .so files from C++ files, which is termed as the native shared library. However, it is not always shared between applications in the true sense. An Android application is a Java application, but a native application can be triggered through a native shared library.
For game development, if the game is written in a native language, then the game code is included in the shared library.
Android SDK is capable of building and packaging an Android application project into an APK file with the support of Java. However, the NDK is not sufficient to build and package APK files. Here are the dependencies for creating an Android application APK other than the NDK:
- Android SDK
- C++ compiler
- Python
- Gradle
- Cygwin
- Java
Android applications are basically Java applications. Hence, it is absolute necessary to have Android SDK in order to create an Android application package.
A native Android application is written in C++, so a C++ compiler is required to compile the code base on the development platform. C++ compilers are platform dependent, so it may not be the same C++ compiler on each platform.
For example, on a Windows machine, the C++11 compiler is used currently in the development industry, whereas the GC++ compiler is used on Linux machines.
These may create different code bases for the actual development project in terms of syntax and API calls.
Python is a separate development language. It can be used to create applications for Android and can support multiple platforms by converting the source into native language. In the case of Android NDK development, Python is used for the conversion of C++ code to native binary.
Gradle is used by the build script and the Android native build tool to convert native code to a shared library. It also provides a virtual Unix environment to make application packages.
An Android project needs the following configurations in order to create an application package from native source code. A native project build depends on the configuration defined in these two files:
Android.mkApplication.mk
Location
The Android.mk file can be located at <Application Project Path>/jni/.
Configuration options:
The Android.mk file contains the following options to create an application package:
CLEAR_VARS: This clears the local and user-defined variables. This option is invoked by theinclude $(CLEAR_VARS)syntax.BUILD_SHARED_LIBRARY: This includes all local files, defined inLOCAL_MODULEandLOCAL_SRC_FILES, in a shared library. It is invoked by theinclude $(BUILD_SHARED_LIBRARY)syntax.BUILD_STATIC_LIBRARY: This specifies static libraries to create.afiles used by the shared libraries. It is invoked by theinclude $(BUILD_STATIC_LIBRARY)syntax.PREBUILT_SHARED_LIBRARY: This indicates a prebuilt shared library at a specific path to build a dependent shared library from local includes. It is invoked by theinclude $(PREBUILT_SHARED_LIBRARY)syntax.PREBUILT_STATIC_LIBRARY: This indicates a prebuild static library at a specific path to build a dependent shared library from local includes. It is invoked by theinclude $(PREBUILT_STATIC_LIBRARY)syntax.TARGET_ARCH: This indicates the basic type of processor architecture family such as ARM, x86, and so on.TARGET_PLATFORM: This defines the target Android platform. The mentioned platform must be installed in the development system through the Android SDK manager. It indicates the Android API level in order to create the application package.TARGET_ARCH_ABI: This indicates the specific ABI for target processor architecture, such as armeabi, armeabi-v7, x86, and so on.LOCAL_PATH: This points to the current file directory. This variable does not get cleared by theCLEAR_VARScommand. It is invoked by theLOCAL_PATH := $ (call my-dir)syntax.LOCAL_MODULE: This indicates all the unique local module names. It is invoked by theLOCAL_MODULE := "<module name>"syntax.LOCAL_MODULE_FILENAME: This indicates the library name that contains the definedLOCAL_MODULE. It is invoked by theLOCAL_MODULE_FILENAME := "<module library file name>"syntax.LOCAL_SRC_FILES: This indicates all the native source code file paths to be compiled into a shared library. It is invoked by theLOCAL_SRC_FILES := <Local source file path>syntax.
There are other optional configurations that can be set in this file, such as LOCAL_C_INCLUDES, LOCAL_CFLAGS, LOCAL_CPP_EXTENSION, LOCAL_CPP_FEATURES, LOCAL_SHARED_LIBRARIES, LOCAL_STATIC_LIBRARIES, and LOCAL_EXPORT_CFLAGS.
Location
The Application.mk file can be located at <Application Project Path>/jni/.
Configuration options
The Application.mk file contains the following options to create an application package:
APP_PROJECT_PATH: This is the absolute path to the project root directory.APP_OPTIM: This indicates the optional setting to create the build package as release or debug.APP_CFLAGS: This defines a set of C-compiler flags for the build instead of changing in theAndroid.mkfile.APP_CPPFLAGS: This defines a set of C++-compiler flags for the build instead of changing in theAndroid.mkfile.APP_BUILD_SCRIPT: This is an optional setting to specify a build script other than the defaultjni/Android.mkscript.APP_ABI: This option specifies the set of ABIs to be optimized for the Android application package. Here is the complete list and keywords for each ABI support:- ARMv5:
armeabi - ARMv7:
armeabi-v7a - ARMv8:
arm64-v8a - Intel 32-bit:
x86 - Intel 64-bit:
x86_64 - MIPS 32-bit:
mips - MIPS 64-bit:
mips64 - ALL-SET:
all
- ARMv5:
APP_PLATFORM: This option specifies the target Android platform.NDK_TOOLCHAIN_VERSION: This option specifies the version of the GCC compiler. By default, versions 4.9 and 4.8 are used for compilation in 64 bit and 32 bit, respectively.APP_STL: This is an optional configuration to link alternative C++ implementations.APP_LDFLAGS: In the case of building a shared library and executables, this option is used to link flags to the build system to link the application.