Intel® Developer Zone offers tools and how-to information for cross-platform app development, platform and technology information, code samples, and peer expertise to help developers innovate and succeed. Join our communities for Android, Internet of Things, Intel® RealSense™ Technology and Windows to download tools, access dev kits, share ideas with like-minded developers, and participate in hackathon’s, contests, roadshows, and local events.
Introduction
Libraries and test apps are often written in C/C++ for testing hardware and software features on Windows*. When these same features are added to an Android* platform, rewriting these libraries and tests in Java* is a large task. It would be preferable to simply port the existing C/C++ code, but many believe that these libraries and tests need to be accessed as Java-based Android applications. But that’s not always the case. If the code to be ported is written in ANSI C/C++ and doesn’t have any OS-specific dependencies, it can be rebuilt using the Android NDK build tools and run from the command line in a shell in much the same way you can run command-line apps from the command prompt in Windows.
This article shows how to write a simple “Hello World” application and run it on an Android device using a remote shell.
Setting up your development environment
Download and install the Android NDK
Go to https://developer.android.com/ndk/downloads/index.html and download the appropriate NDK for your OS. Follow the instructions to extract and install the NDK on your computer.
Set up your build environment
Modify your path environment variable to indicate the location of the NDK directory. This allows you to run the NDK build tools from any other location on your computer without having to specify the tool’s entire path.
On Linux*, you can modify the variable for your local shell with the following command:
export PATH=$PATH:/your/new/path/here
If you’d like the change to be permanent and present in each shell upon opening, add the following line to your ~/.profile or /etc/profile:
PATH=$PATH:/your/new/path/here
Figure 1. Modify the path environment variable.
On Windows, you can modify your environment variables by opening the Control Panel > System and Security > System > Advanced system settings > Environment Variables. Find your path variable in the System variables list, and then click Edit. Add a semicolon to the end of the last path, and then add your NDK path to the end. Click OK on each dialog.
Figure 2. Modify the environment variables.
Writing the code and build scripts
Creating your makefiles
To build for Android, you need to have at least two makefiles: Android.mk and Application.mk. Android.mk is similar to the makefiles you might be familiar with for building on Linux from the command line. In this file you can define the source files to build, the header include directories, compiler flag options, libraries and their locations, the module name, and much more. Application.mk is for specifying Android-specific properties, such as the target Android platform, SDK version, and platform architecture.
Figure 3. The Android.mk makefile.
In Android.mk (Figure 3), you can see that a LOCAL_PATH directory is specified. This is initialized to the current directory so that you can use relative paths to other files and directories in the build environment.
The line that includes CLEAR_VARS clears existing local variables that might have been set from previous builds or more complex builds that have multiple makefiles.
The LOCAL_MODULE variable specifies the output name of the binary you’re creating.
The LOCAL_C_INCLUDES variable specifies the directories you want the preprocessor to search for additional include files.
The LOCAL_SRC_FILES variable specifies the specific source files you’d like to be built for this application/library. Place your .c or .cpp files here.
The final line is the key portion to indicate the building of an executable instead of a library. Most native code is built into libraries for Android applications, but changing the value to $(BUILD_EXECUTABLE) in Android.mk will result in an executable.
Figure 4. The Application.mk makefile.
In Application.mk (Figure 4), the first line indicates a build for x86 versus ARM. This tells the NDK to use the correct tool-chain for x86 target architecture.
The second line specifies the platform to build for. In this case, it is version 21, which is for Android 5.0 also known as Lollipop*.
The third line indicates the use of the static version of the standard library runtime.
The final line indicates the name of the main makefile for this application.
Writing your application
A command-line application in Android is written in the same way, regardless of the platform. Figure 5 shows an example of a simple “Hello World” application. The cout function is used to print to the screen, and myPrint() is defined in another file.
Figure 5. An example of a simple “Hello World” application.
Figure 6. The layout of the folder structure for the project and source files.
Building your application
To have the ndk-build script build an application, first create a project folder. In the folder, create a folder named jni. In the jni folder, place the Android.mk file, Application.mk file, and source files.
Then navigate to the project folder in a terminal and execute ndk-build. ndk-build is a script that resides in the root folder of your NDK installation directory. The ndk-build script will parse the project directory and its subfolders and build the application.
Since this example is about building a command-line application, the structure of having it built under a jni folder doesn’t make much sense since there is no Java code or any code to interface with Java. However, removing the jni folder results in two additional steps that must be taken in the build process.
The first step is to specify the NDK project path. Here, it is set to dot (.) for the current working directory.
export NDK_PROJECT_PATH=.
Then navigate to the project directory and use the ndk-build script. The second step is to specify where the Application.mk file is. Place it in the project directory, so the build command looks like this:
ndk-build NDK_APPLICATION_MK=./Application.mk
This prints your compile steps, executable creation, and where it “installs” your app. In this case, it creates a libs directory under your project directory. In the libs directory, it will create an x86 directory and place your executable in there.
Figure 7. The build command.
Below is the project tree with the source code and output from the build.
Figure 8. The project tree with the source code and output from the build.
Deploying the application
Installing your application
In order to install your application, you’re going to need a host machine and an adb (Android debug bridge) connection to the Android device from it. You’ll need to use adb to connect to the device. The adb application comes with the Android SDK and can be downloaded as part of the platform tools bundle. Move your application to your host machine (main.out, in this instance). Using adb in a command prompt, you can push the file to your Android device.
adb push /path/to/your/file /data/path/to/desired/folder/
Figure 9. Using adb in a command prompt.
Now the main.out executable is on your Android device in the folder you specified.
Running your application
To run your application, first you need to open a shell to your device. You do this with the adb shell command. Now you have a Unix*-like shell open.
Change to the directory where you stored your sample. You can’t yet execute it though. On Unix systems, a file needs to be marked as executable for you to be able to run it. You can do this with the chmod command.
Now you’re ready to run your command line app. Execute it by typing ./<filename> or in this instance: ./main.out.
Figure 10. Running the application.
Congratulations! You can now build and run a command-line application on an Android device.
Author bio
Gideon Eaton is a member of the Intel® Software and Services Group and works with independent software vendors to help them optimize their software for Intel® Atom™ processors. In the past he worked on a team that wrote Linux* graphics drivers for platforms running the Android OS.
