Writing “C” Code for Android

The Android SDK is strictly for Java Programmers -- however, the Native Development Kit cracks the door to let some "C" inside

Java Only, please

The supported and prescribed manner of creating Android applications is via the Android SDK and that means writing your applications in Java.

But what if you have a large body of code already written in C and you want to take leverage that investment for your Android efforts? Should you port your code to Java? Porting your code may be the right answer, but before you start refactoring your code into Java, you should have a look at the Android Native Development Kit (NDK).

Introduced around the release of Android version 1.5, the Android NDK permits developers to write code in “C” that is then callable from Android applications written in Java. The plumbing between the environments is known as the Java Native Interface, or JNI.

JNI has been around for years as a means to permit Java developers to access vendor SDKs or other available C code. Early on, the majority of software vendors’ SDKs were provided as C language static or dynamic libraries — however, this didn’t do Java programmers much good.

The solution to providing the functionality of those SDKs to Java applications was to write a “wrapper” dll in C. The wrapper implemented the Java Native Interface and then proxies calls to the third-party dll. Over time as Java became more popular, some thoughtful vendors began shipping their libraries Java-ready by providing their own JNI wrappers. Today Android developers can leverage C code with JNI with the help of the NDK.

Using the NDK

The Android NDK is a separate download from the Android development site. The NDK is supported on Linux, Mac OSX and Windows, however Windows users need to install Cygwin in order to run the tools properly.

After downloading the NDK, you need to run a script found in the build subdirectory named host-setup.sh. Before running the script you need to set the environment variable named ANDROID_NDK_ROOT to point to your installation of the NDK. For example, on my machine I perform this with:

export ANDROID_NDK_ROOT=~/Software/android/ndkpath

Running this script does basically two things:

It first verifies that your build tools are compatible and that your paths are properly setup for the C and C++ compilers, and the linker. It also locates the pre-built libraries shipped with the NDK which are specific to the Android environment.


Detecting host toolchain.

CC         : compiler check ok (gcc)
LD         : linker check ok (gcc)
CXX        : C++ compiler check ok (g++)
Generate   : out/host/config.mk
Toolchain  : Checking for arm-eabi-4.2.1 prebuilt binaries

Host setup complete. Please read docs/OVERVIEW.TXT if you don't know what to do.

The script also writes out a file named config.mk into a directory named $ANDROID_NDK_ROOT/build/out/host. This file is used by the build tools.

# This file was autogenerated by host-setup.sh. Do not edit !
HOST_OS       := darwin
HOST_ARCH     := x86
HOST_TAG      := darwin-x86
HOST_CC       := gcc
HOST_CXX      := g++
HOST_LD       := gcc
HOST_AR       := ar

Without this file, you cannot build NDK applications. Note that when running the script on my machine, I had to tweak the output directory location for the config.mk file to be written as there was an error in host-setup.sh. I was testing with version 1.5 of the NDK, so it is likely fixed in the latest release (1.6).

The NDK ships with two sample applications to exercise the NDK: a simple “Hello World” application named hello-jni and another project which demonstrates the use of both a static and a dynamic library. In addition to the “C” language components of these projects, the NDK also ships with sample Android Java applications to demonstrate loading and invoking the JNI code.

The NDK has a somewhat sophisticated build environment with a series of make files and make file “snippets” throughout the NDK installation. According to the documentation of the NDK, this build environment is very similar to the core Android source code base.

After getting the hello-jni code to compile, build and run successfully, I thought it would be worth the exercise to build one from scratch — or at least a healthy “cut, paste and modify” version of my own. So I created a simple application and JNI library to perform two basic tasks, each implemented as functions in a C source file. The first function just returns a string and the second increments a passed-in integer, returning the new value as an integer. Of course using JNI for such a task is not worth the effort, but once this is working, more sophisticated tasks are within our reach. Let’s have a quick look.

Building a JNI app

We’ll start by building our JNI C code, implementing the two methods of interest. Here is the C code.

#include <string.h>
#include <jni.h>

Java_com_msi_linuxmagazine_jnisample_LMJNI_stringFromJNI( JNIEnv* env,
                                                  jobject thiz )
    return (*env)->NewStringUTF(env, "Hello from Linux Magazine!");

Java_com_msi_linuxmagazine_jnisample_LMJNI_incrementFromJNI(JNIEnv* env,jobject thiz,jint innumber)
	return innumber + 1;

Note the funny-looking function names! The methods are named according to the following pattern:

Java_<the fully qualified Java name space with “.” replaced with “_”>_methodname

In our Java code shown below, the Java package name is com.msi.linuxmagazine.jnisample and the class name is LMJNI. Therefore the function prefix is: “Java_com_msi_linuxmagazine_jnisample_LMJNI_”

Once the code is written, we also need a couple of Makefile snippets to grease the skids in the build process. The first file named Android.mk is required to compile the C code.

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := linuxmagazine
LOCAL_SRC_FILES := linuxmagazine.c


The Java application is stored beneath the ANDROID_NDK_ROOT in a directory named apps. This directory contains a file named Application.mk which tells the NDK where to save the created JNI library file: liblinuxmagazine.so. The Android code is in a sub-directory named project. Here is the contents of the Application.mk file:

APP_PROJECT_PATH := $(call my-dir)/project
APP_MODULES      := linuxmagazine

To build the JNI code, change directory to the base of your NDK installation and run make, along with the specific target we want the build system to compile:

make APP=linuxmagaine V=1

The V=1 makes the output verbose.

To perform a rebuild, add a -B option to the command line above. Here is what the verbose output looks like:

Android NDK: Building for application 'linuxmagazine'
Compile thumb  : linuxmagazine <= sources/samples/linuxmagazine/linuxmagazine.c
build/prebuilt/darwin-x86/arm-eabi-4.2.1/bin/arm-eabi-gcc -Ibuild/platforms/android-1.5/arch-arm/usr/include -march=armv5te -mtune=xscale -msoft-float -fpic -mthumb-interwork -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__   -Isources/samples/linuxmagazine -DANDROID  -O2 -DNDEBUG -g    -c -MMD -MP -MF out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o.d.tmp sources/samples/linuxmagazine/linuxmagazine.c -o out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o
build/core/mkdeps.sh out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o.d.tmp out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o.d
SharedLibrary  : liblinuxmagazine.so
build/prebuilt/darwin-x86/arm-eabi-4.2.1/bin/arm-eabi-gcc -nostdlib -Wl,-soname,liblinuxmagazine.so -Wl,-shared,-Bsymbolic  out/apps/linuxmagazine/android-1.5-arm/objs/linuxmagazine/linuxmagazine.o -Wl,--whole-archive  -Wl,--no-whole-archive   build/platforms/android-1.5/arch-arm/usr/lib/libc.so build/platforms/android-1.5/arch-arm/usr/lib/libstdc++.so build/platforms/android-1.5/arch-arm/usr/lib/libm.so   -Wl,--no-undefined   -Wl,-rpath-link=build/platforms/android-1.5/arch-arm/usr/lib /Users/fableson/Software/android/android-ndk-1.5_r1/build/prebuilt/darwin-x86/arm-eabi-4.2.1/bin/../lib/gcc/arm-eabi/4.2.1/interwork/libgcc.a -o out/apps/linuxmagazine/android-1.5-arm/liblinuxmagazine.so
Install        : liblinuxmagazine.so => apps/linuxmagazine/project/libs/armeabi
mkdir -p apps/linuxmagazine/project/libs/armeabi
install -p out/apps/linuxmagazine/android-1.5-arm/liblinuxmagazine.so apps/linuxmagazine/project/libs/armeabi/liblinuxmagazine.so
build/prebuilt/darwin-x86/arm-eabi-4.2.1/bin/arm-eabi-strip --strip-debug  apps/linuxmagazine/project/libs/armeabi/liblinuxmagazine.so

That was fun — now we have our liblinuxmagazine.so sitting in $ANDROID_NDK_ROOT/apps/linuxmagazine/libs/armeabi.

Now let’s create our Android Java application to exercise our JNI code.

The application has two TextView (edit box) fields and two buttons, organized into pairs. The first pair is used to exercise the “get a string” JNI function and the second is used for the “increment a number” function. This image shows the user interface of the application before the buttons are clicked.

Before running JNI code
Before running JNI code

Now, let’s look at the code for this Java application:

package com.msi.linuxmagazine.jnisample;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.TextView;
import android.widget.Button;

public class LMJNI extends Activity {
    /** Called when the activity is first created. */
    public void onCreate(Bundle savedInstanceState) {

        Button btnGetString = (Button) this.findViewById(R.id.btnGetString);
        btnGetString.setOnClickListener(new Button.OnClickListener() {
        	public void onClick(View v) {
	                TextView label = (TextView) findViewById(R.id.TheLabel);
	                label.setText(stringFromJNI());   // calling a JNI function here!

        Button btnAddNumber = (Button) this.findViewById(R.id.btnAddNumber);
        btnAddNumber.setOnClickListener(new Button.OnClickListener(){
        	public void onClick(View v) {
	                TextView numberField = (TextView) findViewById(R.id.number);
	                int operand = Integer.parseInt(numberField.getText().toString());
	                int answer = incrementFromJNI(operand);  // calling a JNI function here!
	                numberField.setText("" + answer);

    // declare the externally provided methods
    public native String  stringFromJNI();
    public native int incrementFromJNI(int number);

    static {
    	// load our JNI library.  Note, leave off the "lib" and the ".so"

And here is the layout for the user interface:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/TheLabel" android:text="LMJNI ..."/>

<Button android:text="Get String" android:id="@+id/btnGetString" android:layout_width="wrap_content" android:layout_height="wrap_content"></Button>

    android:id="@+id/number" android:text="10" android:numeric="integer"/>

<Button android:text="Add Number" android:id="@+id/btnAddNumber" android:layout_width="wrap_content" android:layout_height="wrap_content"></Button>


Some things to note in this code snippet:

  • We are using a basic single-Activity Android application with a simple user interface layout: two pairs of TextView and Button.
  • A call to System.loadLibrary loads our JNI shared library.
  • We define each of the implemented methods. Note the native qualifier on the methods.
  • Each user interface element has an “id” attribute so we can get access to it at run-time, a standard Android practice.
  • We create onClick handlers for each button and within those methods, we invoke the native code. These click handlers have no idea that the code is external to the application.
  • If the native methods were missing, the application would throw an exception. The app really should have a try/catch block.

The JNI library is automatically deployed as part of our apk file and the code runs as expected at runtime!

After selecting the buttons we see the string has been returned from the JNI code and the number 10 has been incremented to 11.

After running JNI code
After running JNI code

This is just scratching the surface of using the NDK, but hopefully sheds some light on using C with the Android platform. There is a subset of the system libraries shipped with the NDK — the documentation warns against using other libraries as the underlying architecture is at risk of changing. I personally would not be too concerned with this as the entire mobile space is rapidly changing!

This code was compiled against version 1.5 of the NDK and was found to run just fine against the 1.5 and 2.1 Android emulators.

Comments on "Writing “C” Code for Android"



Your article is very helpful. But I am not able to build the application properly.
I have created the jni code as explained in the \”apps\” dir. and the application is in /home/abc/workspace.

When i run the application thru eclipse on emulator, i get the error \”The aaplication Jni Sample has stopped unexpectedly.Please try again\”.
and when i see the logcat, i found \”Exception Ljava/lang/UnsatisfiedLinkError; thrown during Lcom/msi/linuxmagazine/jnidemo/Hello;.<clinit>\” message.

I think the System.loadLibrary() can not locate the library properly.
Can you please tell me if i have missed any step?

Thanks in advance!


article is very helpful.i have tested with android 2.2 and ndk r4.
heyanu21 ,check you run as configuration is proper or not.and test once again.


Very useful information. I could develop my own libraries and successfully created applications using those libraries.

Now i want to move more deep into Native code development. My sample library method is trying to read from /dev/dsp and write to a file in SDCard. To write in to SDCard file we have to specify <uses-permission name:writetoexternalmemory….>(something like this) in android manifest. But not able to open /dev/dsp.
How can i access the a/dev/dsp file in my native code library method??


can you please give more workable examples


I love what you guys are up too. This sort of clever work and coverage!
Keep up the amazing works guys I’ve incorporated you guys to our blogroll.


I really liked your post.Much thanks again. Will read on…


myKrCA kkqxewctfspc, [url=http://favdzclxxcgp.com/]favdzclxxcgp[/url], [link=http://iqwzdoalmodx.com/]iqwzdoalmodx[/link], http://zynsmcaaliwd.com/


I really like and appreciate your blog post.Much thanks again. Want more.


I was curious if you ever thought of changing the structure of your website? Its very well written; I love what youve got to say. But maybe you could a little more in the way of content so people could connect with it better. Youve got an awful lot of text for only having one or two images. Maybe you could space it out better?


I and my buddies were found to be going through the nice tips and tricks located on the blog while quickly got an awful feeling I had not expressed respect to the blog owner for those tips. Those people appeared to be as a result warmed to learn them and have pretty much been loving these things. Appreciation for actually being so accommodating as well as for choosing this kind of awesome useful guides most people are really needing to understand about. Our honest apologies for not saying thanks to you sooner.


I really liked your post. thanks


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>