page.title=Concepts
@jd:body
Before Beginning
This guide assumes that you are already familiar with concepts inherent in native programming and
in Android development.
Introduction
This section provides a high-level explanation of how the NDK works. The Android NDK is a set of
tools allowing you to embed C or C++ (“native code”) into your Android apps. The ability to use
native code in Android apps can be particularly useful to developers who wish to do one or more of
the following:
- Port their apps between platforms.
- Reuse existing libraries, or provide their own libraries for reuse.
- Increase performance in certain cases, particularly computationally intensive ones like games.
How it Works
This section introduces the main components used in building a native application for Android,
and goes on to describe the process of building and packaging.
Main components
You should have an understanding of the following components as you build your app:
- Java: From your Java source, the Android build process generates {@code .dex}
(Dalvik EXecutable) files, which are what the Android OS runs in the Dalvik Virtual Machine
(“DVM”). Even if your app contains no Java source code at all, the build process still generates a
{@code .dex} executable file within which the native component runs.
When developing Java components, use the {@code native} keyword to indicate methods implemented
as native code. For example, the following function declaration tells the compiler that the
implementation is in a native library:
public native int add(int x, int y);
- Native shared libraries: The NDK builds these libraries, or {@code .so} files, from your native
source code.
Note: If two libraries implement respective methods with the same
signature, a link error occurs. In C, "signature" means method name only. In C++, "signature" means
not only method name, but also its argument names and types.
- Native static libraries: The NDK can also build static libraries, or {@code .a} files, which you
can link against other libraries.
- Java Native Interface (JNI): The JNI is the interface via which the Java and C++ components
talk to one another. This guide assumes knowledge of the JNI; for information about it, consult the
Java Native Interface Specification.
- Application Binary Interface (ABI): The ABI defines exactly how your app's machine code is
expected to interact with the system at runtime. The NDK builds {@code .so} files against these
definitions. Different ABIs correspond to different architectures: The NDK includes ABI support for
ARMEABI (default), MIPS, and x86. For more information, see
ABI Management.
- Manifest: If you are writing an app with no Java component to it, you must declare the
{@link android.app.NativeActivity} class in the
manifest.
Native Activities and Applications provides more detail on how to do this, under
“Using the {@code native_activity.h} interface.”
The following two items are only required for building using the
{@code ndk-build} script,
and for debugging using the
{@code ndk-gdb} script.
- {@code Android.mk}:
You must create an
{@code Android.mk} configuration file inside your {@code jni} folder. The {@code ndk-build}
script looks at this file, which defines the module and its name, the source files to be compiled,
build flags and libraries to link.
- {@code Application.mk}: This file
enumerates and describes the modules that your app requires. This information includes:
- ABIs used to compile for specific platforms.
- Toolchains.
- Standard libraries to include (static and dynamic STLport or default system).
Flow
The general flow for developing a native app for Android is as follows:
- Design your app, deciding which parts to implement in Java, and which parts to implement as
native code.
Note: While it is possible to completely avoid Java, you are likely
to find the Android Java framework useful for tasks including controlling the display and UI.
- Create an Android app Project as you would for any other Android project.
- If you are writing a native-only app, declare the {@link android.app.NativeActivity} class in
{@code AndroidManifest.xml}. For more information, see the Native Activities and
Applications.
- Create an {@code Android.mk} file describing the native library, including name, flags, linked
libraries, and source files to be compiled in the "JNI" directory.
- Optionally, you can create an {@code Application.mk} file configuring the target ABIs,
toolchain, release/debug mode, and STL. For any of these that you do not specify, the following
default values are used, respectively:
-
ABI: armeabi
-
Toolchain: GCC 4.8
-
Mode: Release
-
STL: system
- Place your native source under the project's {@code jni} directory.
- Use ndk-build to compile the native ({@code .so}, {@code .a}) libraries.
- Build the Java component, producing the executable {@code .dex} file.
- Package everything into an APK file, containing {@code .so}, {@code .dex}, and other files
needed for your app to run.
Native Activities and Applications
The Android SDK provides a helper class, {@link android.app.NativeActivity}, that allows you to
write a completely native activity. {@link android.app.NativeActivity} handles the communication
between the Android framework and your native code, so you do not have to subclass it or call its
methods. All you need to do is declare your application to be native in your
{@code AndroidManifest.xml} file, and begin creating your native application.
An Android application using {@link android.app.NativeActivity} still runs in its own virtual
machine, sandboxed from other applications. You can therefore still access Android framework APIs
through the JNI. In certain cases, however–such as for sensors, input events, and
assets–the NDK provides native interfaces that you can use instead of having to call
across the JNI. For more information about such support, see
Android NDK Native APIs.
Regardless of whether or not you are developing a native activity, we recommend that you create
your projects with the traditional Android build tools. Doing so helps ensure building and packaging
of Android applications with the correct structure.
The Android NDK provides you with two choices to implement your native activity:
- The {@code native_activity.h}
header defines the native version of the
{@link android.app.NativeActivity} class. It contains the callback interface and data structures
that you need to create your native activity. Because the main thread of your application handles
the callbacks, your callback implementations must not be blocking. If they block, you might receive
ANR (Application Not Responding) errors because your main thread is unresponsive until the callback
returns.
- The {@code android_native_app_glue.h} file defines a static helper library built on top of the
{@code native_activity.h} interface.
It spawns another thread, which handles things such as
callbacks or input events in an event loop. Moving these events to a separate thread prevents any
callbacks from blocking your main thread.
The {@code /sources/android/native_app_glue/android_native_app_glue.c} source is
also available, allowing you to modify the implementation.
For more information on how to use this static library, examine the native-activity sample
application and its documentation. Further reading is also available in the comments in the {@code /sources/android/native_app_glue/android_native_app_glue.h} file.
Using the native_activity.h interface
To implement a native activity with the
{@code native_activity.h}
interface:
- Create a {@code jni/} directory in your project's root directory. This directory stores all of
your native code.
- Declare your native activity in the {@code AndroidManifest.xml} file.
Because your application has no Java code, set {@code android:hasCode} to {@code false}.
<application android:label="@string/app_name" android:hasCode="false">
You must set the {@code android:name} attribute of the activity tag to
{@link android.app.NativeActivity}.
<activity android:name="android.app.NativeActivity"
android:label="@string/app_name">
Note: You can subclass {@link android.app.NativeActivity}. If you
do, use the name of the subclass instead of {@link android.app.NativeActivity}.
The {@code android:value} attribute of the {@code meta-data} tag specifies the name of the shared
library containing the entry point to the application (such as C/C++ {@code main}), omitting the
{@code lib} prefix and {@code .so} suffix from the library name.
<meta-data android:name="android.app.lib_name"
android:value="native-activity" />
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
- Create a file for your native activity, and implement the function named in the
{@code ANativeActivity_onCreate} variable.
The app calls this function when the native activity starts. This function, analogous
to {@code main} in C/C++, receives a pointer to an
{@code ANativeActivity}
structure, which contains function pointers to the various callback implementations that you need
to write.
Set the applicable callback function pointers in {@code ANativeActivity->callbacks} to the
implementations of your callbacks.
- Set the {@code ANativeActivity->instance} field to the address of any instance of specific
data that you want to use.
- Implement anything else that you want your activity to do upon starting.
- Implement the rest of the callbacks that you set in {@code ANativeActivity->callbacks}. For
more information on when the callbacks are called, see
Managing the Activity
Lifecycle.
- Develop the rest of your application.
- Create an {@code Android.mk file} in the {@code jni/} directory of your project to describe your
native module to the build system. For more information, see
Android.mk.
- Once you have an {@code Android.mk}
file, compile your native code using the {@code ndk-build} command.
$ cd <path>/<to>/<project>
$ <ndk>/ndk-build
- Build and install your Android project as usual. If your native code is in
the {@code jni/} directory, the build script automatically packages the {@code .so} file(s) built
from it into the APK.