From c2d1a2037ef0045abb75c651ca86e681f617cf8f Mon Sep 17 00:00:00 2001
From: Robert Ly Includes fixes for several issues in the NDK build and debugging scripts
-— if you are using NDK r4, we recommend downloading the NDK r4b build. For
-detailed information the changes in this release, read the CHANGES.TXT document
-included in the downloaded NDK package. Originally released as "Android 1.6 NDK, Release 1". Originally released as "Android 1.5 NDK, Release 1". The Android NDK is a toolset that lets you embed components that make use
-of native code in your Android applications.
- Android applications run in the Dalvik virtual machine. The NDK allows
-you to implement parts of your applications using native-code languages
-such as C and C++. This can provide benefits to certain classes of applications,
-in the form of reuse of existing code and in some cases increased speed. The NDK provides: The latest release of the NDK supports these ARM instruction sets: Future releases of the NDK will also support: ARMv5TE machine code will run on all ARM-based Android devices. ARMv7-A will
-run only on devices such as the Verizon Droid or Google Nexus One that have a
-compatible CPU. The main difference between the two instruction sets is that
-ARMv7-A supports hardware FPU, Thumb-2, and NEON instructions. You can target
-either or both of the instruction sets — ARMv5TE is the default, but
-switching to ARMv7-A is as easy as adding a single line to the application's
-Application.mk file, without needing to change anything else in the file. You
-can also build for both architectures at the same time and have everything
-stored in the final The NDK provides stable headers for libc (the C library), libm (the Math
-library), OpenGL ES (3D graphics library), the JNI interface, and other
-libraries, as listed in the section below. The NDK will not benefit most applications. As a developer, you will need
-to balance its benefits against its drawbacks; notably, using native code does
-not result in an automatic performance increase, but does always increase
-application complexity. Typical good candidates for the NDK are self-contained,
-CPU-intensive operations that don't allocate much memory, such as signal processing,
-physics simulation, and so on. Simply re-coding a method to run in C usually does
-not result in a large performance increase. The NDK can, however, can be
-an effective way to reuse a large corpus of existing C/C++ code. Please note that the NDK does not enable you to develop native-only
-applications. Android's primary runtime remains the Dalvik virtual machine. The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that
-can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin)
-platforms. It provides a set of system headers for stable native APIs that are
-guaranteed to be supported in all later releases of the platform: The NDK also provides a build system that lets you work efficiently with your
-sources, without having to handle the toolchain/platform/CPU/ABI details. You
-create very short build files to describe which sources to compile and which
-Android application will use them — the build system compiles the sources
-and places the shared libraries directly in your application project. Important: With the exception of the
-libraries listed above, native system libraries in the Android platform are
-not stable and may change in future platform versions.
-Your applications should only make use of the stable native system
-libraries provided in this NDK. The NDK package includes a set of documentation that describes the
-capabilities of the NDK and how to use it to create shared libraries for your
-Android applications. In this release, the documentation is provided only in the
-downloadable NDK package. You can find the documentation in the
- Additionally, the package includes detailed information about the "bionic"
-C library provided with the Android platform that you should be aware of, if you
-are developing using the NDK. You can find the documentation in the
- The NDK includes sample Android applications that illustrate how to use
-native code in your Android applications. For more information, see
-Using the Sample Applications. The sections below describe the system and software requirements for using
-the Android NDK, as well as platform compatibility considerations that affect
-appplications using libraries produced with the NDK.
-Android NDK, Revision 4b (June 2010)
-
-
-
-
-
-
-
-ndk-build build
-command. ndk-gdb command.armeabi-v7a. The new ABI extends the existing armeabi
-ABI to include these CPU instruction set extensions:
-
-
-cpufeatures static library (with sources) that lets
-your app detect the host device's CPU features at runtime. Specifically,
-applications can check for ARMv7-A support, as well as VFPv3-D32 and NEON
-support, then provide separate code paths as needed.hello-neon, that illustrates how to
-use the cpufeatures library to check CPU features and then provide
-an optimized code path using NEON instrinsics, if
-supported by the CPU..apk.
-Android NDK, Revision 3 (March 2010)
-
-
-
-
-hello-gl2, that illustrates the use of
-OpenGL ES 2.0 vertex and fragment shaders.
-Android NDK, Revision 2 (September 2009)
-
-
-
-
-san-angeles, that renders 3D
-graphics through the native OpenGL ES APIs, while managing activity
-lifecycle with a {@link android.opengl.GLSurfaceView} object.
-
-Android NDK, Revision 1 (June 2009)
-
-
-
-
-What is the Android NDK?
-
-
-
-
-.apk) that can be deployed on Android devices
-
-
-
-
-
-.apk. For complete information is provided in the
-CPU-ARCH-ABIS.TXT in the NDK package. Contents of the NDK
-
-Development tools
-
-
-
-
-Documentation
-
-<ndk>/docs/ directory. Included are these files:
-
-
-cpufeatures
-static library that lets your application code detect the target device's
-CPU family and the optional features at runtime. <ndk>/docs/system/libc/ directory:
-
-
-Sample applications
-
-System and Software Requirements
-
-The Android SDK
-
-
-
-Supported operating systems
-
-
-
-Required development tools
-
-
-
-Android platform compatibility
-
-
<uses-sdk>
-element in its manifest file, with an android:minSdkVersion attribute
-value of "3" or higher. For example:
-
-<manifest>
- ...
- <uses-sdk android:minSdkVersion="3" />
- ...
-</manifest>
-android:minSdkVersion attribute value, as given in the table.
| OpenGL ES Version Used | -Compatible Android Platform(s) | -Required uses-sdk Attribute | -
|---|---|---|
| OpenGL ES 1.1 | Android 1.6 and higher | android:minSdkVersion="4" |
| OpenGL ES 2.0 | Android 2.0 and higher | android:minSdkVersion="5" |
For more information about API Level and its relationship to Android -platform versions, see -Android API Levels.
- -<uses-feature> element in its manifest, with an
-android:glEsVersion attribute that specifies the minimum OpenGl ES
-version required by the application. This ensures that Android Market will show
-your application only to users whose devices are capable of supporting your
-application. For example:
-
-<manifest> - ... - - <uses-feature android:glEsVersion="0x00020000" /> - ... -</manifest>- -
For more information, see the <uses-feature>
-documentation.
<uses-sdk android:minSdkVersion="8" />attribute
-value in its manifest.Installing the NDK on your development computer is straightforward and -involves extracting the NDK from its download package. Unlike previous releases, -there is no need to run a host-setup script.
- -Before you get started make sure that you have downloaded the latest Android SDK and upgraded your applications -and environment as needed. The NDK will not work with older versions of the -Android SDK. Also, take a moment to review the System -and Software Requirements for the NDK, if you haven't already.
- -To install the NDK, follow these steps:
- -android-ndk-<version>. You can rename the NDK directory if
-necessary and you can move it to any location on your computer. This
-documentation refers to the NDK directory as <ndk>. You are now ready start working with the NDK.
- -Once you've installed the NDK successfully, take a few minutes to read the
-documentation included in the NDK. You can find the documentation in the
-<ndk>/docs/ directory. In particular, please read the
-OVERVIEW.TXT document completely, so that you understand the intent of the NDK
-and how to use it.
If you used a previous version of the NDK, take a moment to review the -list of NDK changes in the CHANGES.TXT document.
- -Here's the general outline of how you work with the NDK tools:
- -<project>/jni/...<project>/jni/Android.mk to
-describe your native sources to the NDK build system<project>/jni/Application.mk.-$ cd <project> -$ <ndk>/ndk-build -- -
The build tools copy the stripped, shared libraries needed by your -application to the proper location in the application's project directory.
-.apk file. For complete information on all of the steps listed above, please see the -documentation included with the NDK package.
- - -The NDK includes sample applications that illustrate how to use native -code in your Android applications:
- -hello-jni — a simple application that loads a string from
-a native method implemented in a shared library and then displays it in the
-application UI. two-libs — a simple application that loads a shared
-library dynamically and calls a native method provided by the library. In this
-case, the method is implemented in a static library imported by the shared
-library. san-angeles — a simple application that renders 3D
-graphics through the native OpenGL ES APIs, while managing activity lifecycle
-with a {@link android.opengl.GLSurfaceView} object. hello-gl2 — a simple application that renders a triangle
-using OpenGL ES 2.0 vertex and fragment shaders.hello-neon — a simple application that shows how to use
-the cpufeatures library to check CPU capabilities at runtime,
-then use NEON intrinsics if supported by the CPU. Specifically, the
-application implements two versions of a tiny benchmark for a FIR filter
-loop, a C version and a NEON-optimized version for devices that support it.bitmap-plasma — a simple application that demonstrates
-how to access the pixel buffers of Android {@link android.graphics.Bitmap}
-objects from native code, and uses this to generate an old-school "plasma"
-effect. For each sample, the NDK includes the corresponding C source code and the
-necessary Android.mk and Application.mk files. There are located under
-<ndk>/samples/<name>/ and their source code can be found under
-<ndk>/samples/<name>/jni/.
You can build the shared libraries for the sample apps by going into <ndk>/samples/<name>/
-then calling the ndk-build command. The generated shared libraries will be located under
-<ndk>/samples/<name>/libs/armeabi/ for (ARMv5TE machine code) and/or
-<ndk>/samples/<name>/libs/armeabi-v7a/ for (ARMv7 machine code).
-
Next, build the sample Android applications that use the shared -libraries:
- -<ndk>/apps/<app_name>/project/. Then, set up an AVD, if
-necessary, and build/run the application in the emulator. For more information
-about creating a new Android project in Eclipse, see Developing in
-Eclipse.android tool to create
-the build file for each of the sample projects at
-<ndk>/apps/<app_name>/project/. Then set up an AVD, if
-necessary, build your project in the usual way, and run it in the emulator.
-For more information, see Developing in Other
-IDEs.If you have questions about the NDK or would like to read or contribute to -discussions about it, please visit the android-ndk group and -mailing list.
+
Android NDK, Revision 5 (November 2010)
+
+ The r5 release of the NDK includes many new APIs, many of which are introduced to + support native game development and applications that require similar requirements. Most + notably, native activities are now supported, which allow you to write an application + entirely with native code. For detailed information describing the changes in this + release, read the CHANGES.HTML document included in the downloaded NDK package.
+.apk file.native-plasma and
+ native-activity, to demonstrate how to write a native activity.
Android NDK, Revision 4b (June 2010)
+
+ Includes fixes for several issues in the NDK build and debugging scripts — if + you are using NDK r4, we recommend downloading the NDK r4b build. For detailed + information describing the changes in this release, read the CHANGES.TXT document + included in the downloaded NDK package.
+ndk-build build
+ command.ndk-gdb command.armeabi-v7a. The new ABI extends the existing armeabi ABI to
+ include these CPU instruction set extensions:
+
+ cpufeatures static library (with sources) that lets your
+ app detect the host device's CPU features at runtime. Specifically, applications can
+ check for ARMv7-A support, as well as VFPv3-D32 and NEON support, then provide separate
+ code paths as needed.hello-neon, that illustrates how to use the
+ cpufeatures library to check CPU features and then provide an optimized
+ code path using NEON instrinsics, if supported by the CPU..apk.
Android NDK, Revision 3 (March 2010)
+
+ hello-gl2, that illustrates the use of
+ OpenGL ES 2.0 vertex and fragment shaders.
Android NDK, Revision 2 (September 2009)
+
+ Originally released as "Android 1.6 NDK, Release 1".
+ +san-angeles, that renders 3D graphics
+ through the native OpenGL ES APIs, while managing activity lifecycle with a {@link
+ android.opengl.GLSurfaceView} object.
Android NDK, Revision 1 (June 2009)
+
+ Originally released as "Android 1.5 NDK, Release 1".
+ +Installing the NDK on your development computer is straightforward and involves extracting the + NDK from its download package. Unlike previous releases, there is no need to run a host-setup + script.
+ +Before you get started make sure that you have downloaded the latest Android SDK and upgraded your applications and environment as + needed. The NDK will not work with older versions of the Android SDK. Also, take a moment to + review the System and Software Requirements for the + NDK, if you haven't already.
+ +To install the NDK, follow these steps:
+ +android-ndk-<version>. You can rename the NDK directory if necessary and you
+ can move it to any location on your computer. This documentation refers to the NDK directory as
+ <ndk>.You are now ready start working with the NDK.
+ +Once you've installed the NDK successfully, take a few minutes to read the documentation
+ included in the NDK. You can find the documentation in the <ndk>/docs/
+ directory. In particular, please read the OVERVIEW.HTML document completely, so that you
+ understand the intent of the NDK and how to use it.
If you used a previous version of the NDK, take a moment to review the list of NDK changes in + the CHANGES.HTML document.
+ +Here's the general outline of how you work with the NDK tools:
+ +<project>/jni/...<project>/jni/Android.mk to describe your native sources to the
+ NDK build system<project>/jni/Application.mk.+cd <project> +<ndk>/ndk-build ++ +
The build tools copy the stripped, shared libraries needed by your application to the + proper location in the application's project directory.
+.apk file.For complete information on all of the steps listed above, please see the documentation + included with the NDK package.
+The NDK includes sample applications that illustrate how to use native code in your Android + applications:
+hello-jni — a simple application that loads a string from a native
+ method implemented in a shared library and then displays it in the application UI.two-libs — a simple application that loads a shared library dynamically
+ and calls a native method provided by the library. In this case, the method is implemented in a
+ static library imported by the shared library.san-angeles — a simple application that renders 3D graphics through the
+ native OpenGL ES APIs, while managing activity lifecycle with a {@link
+ android.opengl.GLSurfaceView} object.hello-gl2 — a simple application that renders a triangle using OpenGL ES
+ 2.0 vertex and fragment shaders.hello-neon — a simple application that shows how to use the
+ cpufeatures library to check CPU capabilities at runtime, then use NEON intrinsics
+ if supported by the CPU. Specifically, the application implements two versions of a tiny
+ benchmark for a FIR filter loop, a C version and a NEON-optimized version for devices that
+ support it.bitmap-plasma — a simple application that demonstrates how to access the
+ pixel buffers of Android {@link android.graphics.Bitmap} objects from native code, and uses
+ this to generate an old-school "plasma" effect.native-activity — a simple application that demonstrates how to use the
+ native-app-glue static library to create a native activitynative-plasma — a version of bitmap-plasma implemented with a native
+ activity.For each sample, the NDK includes the corresponding C source code and the necessary Android.mk
+ and Application.mk files. There are located under <ndk>/samples/<name>/
+ and their source code can be found under <ndk>/samples/<name>/jni/.
You can build the shared libraries for the sample apps by going into
+ <ndk>/samples/<name>/ then calling the ndk-build command.
+ The generated shared libraries will be located under
+ <ndk>/samples/<name>/libs/armeabi/ for (ARMv5TE machine code) and/or
+ <ndk>/samples/<name>/libs/armeabi-v7a/ for (ARMv7 machine code).
Next, build the sample Android applications that use the shared libraries:
+ +<ndk>/apps/<app_name>/project/. Then, set up an AVD,
+ if necessary, and build/run the application in the emulator. For more information about
+ creating a new Android project in Eclipse, see Developing in Eclipse.android tool to create the build file
+ for each of the sample projects at <ndk>/apps/<app_name>/project/.
+ Then set up an AVD, if necessary, build your project in the usual way, and run it in the
+ emulator. For more information, see Developing in Other IDEs.The hello-jni sample is a simple demonstration on how to use JNI from an Android application. + The HelloJni activity receives a string from a simple C function and displays it in a + TextView.
+ +The main components of the sample include:
+ +AndroidManifest.xml
+ file, a src/ and res directories, and a main activity)jni/ directory that includes the implemented source file for the native code
+ as well as the Android.mk filetests/ directory that contains unit test code.android tool to update the project so it generates a build.xml file that you can
+ use to build the sample.
+
+ <ndk-root>/samples/hello-jni directory.<ndk-root>/samples/hello-jni directory.+android update project -p . -s ++
ndk-build command.
+ +cd <ndk-root>/samples/hello-jni +<ndk_root>/ndk-build ++
+ant debug +adb install bin/HelloJni-debug.apk ++
When you run the application on the device, the string Hello JNI should appear on
+ your device. You can explore the rest of the samples that are located in the
+ <ndk-root>/samples directory for more examples on how to use the JNI.
The native-activity sample provided with the Android NDK demonstrates how to use the + android_native_app_glue static library. This static library makes creating a native activity + easier by providing you with an implementation that handles your callbacks in another thread, so + you do not have to worry about them blocking your main UI thread. The main parts of the sample + are described below:
+ +AndroidManifest.xml
+ file, a src/ and res directories). The AndroidManifest.xml declares
+ that the application is native and specifies the .so file of the native activity. See {@link
+ android.app.NativeActivity} for the source or see the
+ <ndk_root>/platforms/samples/native-activity/AndroidManifest.xml file.jni/ directory contains the native activity, main.c, which uses the
+ android_native_app_glue.h interface to implement the activity. The Android.mk that
+ describes the native module to the build system also exists here.To build this sample application:
+ +android tool to update the project so it generates a build.xml file that you can
+ use to build the sample.
+
+ <ndk-root>/samples/native-activity directory.<ndk-root>/samples/native-activity directory.+android update project -p . -s ++
ndk-build command.
+ +cd <ndk-root>/platforms/samples/android-9/samples/native-activity +<ndk_root>/ndk-build ++
+ant debug +adb install bin/NativeActivity-debug.apk ++
If you have questions about the NDK or would like to read or contribute to discussions about + it, please visit the android-ndk group + and mailing list.
diff --git a/docs/html/sdk/ndk/overview.jd b/docs/html/sdk/ndk/overview.jd new file mode 100644 index 0000000000000..a7ec5d42a1103 --- /dev/null +++ b/docs/html/sdk/ndk/overview.jd @@ -0,0 +1,334 @@ +page.title=What is the NDK? +@jd:body + +The Android NDK is a toolset that lets you embed components that make use of native code in + your Android applications.
+ +Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts + of your applications using native-code languages such as C and C++. This can provide benefits to + certain classes of applications, in the form of reuse of existing code and in some cases + increased speed.
+ +The NDK provides:
+ +.apk) that can be deployed on Android devicesThe latest release of the NDK supports these ARM instruction sets:
+ +Future releases of the NDK will also support:
+ +ARMv5TE machine code will run on all ARM-based Android devices. ARMv7-A will run only on
+ devices such as the Verizon Droid or Google Nexus One that have a compatible CPU. The main
+ difference between the two instruction sets is that ARMv7-A supports hardware FPU, Thumb-2, and
+ NEON instructions. You can target either or both of the instruction sets — ARMv5TE is the
+ default, but switching to ARMv7-A is as easy as adding a single line to the application's
+ Application.mk file, without needing to change anything else in the file. You can also build for
+ both architectures at the same time and have everything stored in the final .apk.
+ Complete information is provided in the CPU-ARCH-ABIS.HTML in the NDK package.
The NDK provides stable headers for libc (the C library), libm (the Math library), OpenGL ES + (3D graphics library), the JNI interface, and other libraries, as listed in the Development Tools section.
+ +The NDK will not benefit most applications. As a developer, you need to balance its benefits + against its drawbacks; notably, using native code does not result in an automatic performance + increase, but always increases application complexity. In general, you should only use native + code if it is essential to your application, not just because you prefer to program in C/C++.
+ +Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't + allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding + a method to run in C usually does not result in a large performance increase. When examining + whether or not you should develop in native code, think about your requirements and see if the + Android framework APIs provide the functionality that you need. The NDK can, however, can be an + effective way to reuse a large corpus of existing C/C++ code.
+ +The Android framework provides two ways to use native code:
+ +Write a native activity, which allows you to potentially create an application completely in native
+ code, because you can implement the lifecycle callbacks natively. The Android SDK provides
+ the {@link android.app.NativeActivity} class, which is a convenience class that notifies your
+ native code of any activity lifecycle callbacks (onCreate(), onPause(),
+ onResume(), etc). You can implement the callbacks in your native code to handle
+ these events when they occur. Applications that use native activities must be run on Android
+ 2.3 (API Level 9) or later.
You cannot access features such as Services and Content Providers natively, so if you want + to use them or any other framework API, you can still write JNI code to do so.
+The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate + native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
+ +It provides a set of system headers for stable native APIs that are guaranteed to be supported + in all later releases of the platform:
+ +The NDK also provides a build system that lets you work efficiently with your sources, without + having to handle the toolchain/platform/CPU/ABI details. You create very short build files to + describe which sources to compile and which Android application will use them — the build + system compiles the sources and places the shared libraries directly in your application + project.
+ +Important: With the exception of the libraries listed above, + native system libraries in the Android platform are not stable and may change in future + platform versions. Your applications should only make use of the stable native system + libraries provided in this NDK.
+ +The NDK package includes a set of documentation that describes the capabilities of the NDK and
+ how to use it to create shared libraries for your Android applications. In this release, the
+ documentation is provided only in the downloadable NDK package. You can find the documentation in
+ the <ndk>/docs/ directory. Included are these files:
cpufeatures static library that
+ lets your application code detect the target device's CPU family and the optional features at
+ runtime.Additionally, the package includes detailed information about the "bionic" C library provided
+ with the Android platform that you should be aware of, if you are developing using the NDK. You
+ can find the documentation in the <ndk>/docs/system/libc/ directory:
The NDK includes sample Android applications that illustrate how to use native code in your + Android applications. For more information, see Sample Applications.
+ +The sections below describe the system and software requirements for using the Android NDK, as + well as platform compatibility considerations that affect appplications using libraries produced + with the NDK.
+ +
+ <uses-sdk> element in its manifest file, with an
+ android:minSdkVersion attribute value of "3" or higher. For example:
+ +<manifest> + ... + <uses-sdk android:minSdkVersion="3" /> + ... +</manifest> ++
android:minSdkVersion attribute value, as given in the
+ table.| OpenGL ES Version Used | + +Compatible Android Platform(s) | + +Required uses-sdk Attribute | +
|---|---|---|
| OpenGL ES 1.1 | + +Android 1.6 and higher | + +android:minSdkVersion="4" |
+
| OpenGL ES 2.0 | + +Android 2.0 and higher | + +android:minSdkVersion="5" |
+
For more information about API Level and its relationship to Android platform versions, + see Android API Levels.
+<uses-feature> element in its manifest, with an
+ android:glEsVersion attribute that specifies the minimum OpenGl ES version
+ required by the application. This ensures that Android Market will show your application only
+ to users whose devices are capable of supporting your application. For example:
+ +<manifest> + ... + + <uses-feature android:glEsVersion="0x00020000" /> + ... +</manifest> ++ +
For more information, see the <uses-feature>
+ documentation.
<uses-sdk
+ android:minSdkVersion="8" /> attribute value in its manifest.