diff --git a/docs/html-ndk/ndk/guides/sample_hellojni.jd b/docs/html-ndk/ndk/guides/sample_hellojni.jd
index f05f042d4fe85..fa3fb5dd1fdbb 100644
--- a/docs/html-ndk/ndk/guides/sample_hellojni.jd
+++ b/docs/html-ndk/ndk/guides/sample_hellojni.jd
@@ -1,4 +1,4 @@
-page.title=Sample: HelloJNI
+page.title=Sample: hello-jni
@jd:body
@@ -16,14 +16,15 @@ page.title=Sample: HelloJNI
-This sample provides a bare-bones look at a minimal
-application built with the NDK.
+This sample provides a bare-bones look at HelloJNI, a minimal
+application built with the NDK. This sample is in the {@code samples/hello-jni/} directory
+under the root directory of your NDK installation.
Android.mk
The following two lines provide the name of the native source file, along
with the name of the shared library to build. The full name of the built
-library is {@code libhello-jni.so}, but you should omit the
+library is {@code libhello-jni.so}, once the build system adds the
{@code lib} prefix and the {@code .so} extension.
@@ -31,23 +32,23 @@ LOCAL_SRC_FILES := hello-jni.c
LOCAL_MODULE := hello-jni
-For more information on what this file does, and how to use it, see
+
For more information about what the {@code Android.mk} file does, and how to use it, see
Android.mk.
Application.mk
-This line tells the build system the architecture against which to build. If
-you don't specify anything, the build system defaults to {@code armeabi}.
+This line tells the build system the CPU and architecture against which to build. In this
+example, the build system builds for all supported architectures.
APP_ABI := all
-For more information on what this file does, and how to use it, see
+
For more information about the {@code Application.mk} file, and how to use it, see
Application.mk.
-Java-side implementation
-This file calls a function to retrieve a string from the native side, then
-displays it on the screen.
+Java-side Implementation
+The {@code helloJNI.java} file is located in {@code hellojni/src/com/example/hellojni/}. It calls
+a function to retrieve a string from the native side, then displays it on the screen.
The source code contains three lines of particular interest to the NDK user.
They are presented here in the order in which they are used, rather than by
@@ -60,8 +61,8 @@ System.loadLibrary("hello-jni");
The {@code native} keyword in this method declaration tells the
-virtual machine that the function is in the shared library (i.e., implemented on the native side).
-
+virtual machine that the function is in the shared library (that is, implemented on the native
+side).
public native String stringFromJNI();
@@ -74,15 +75,15 @@ previous steps, displaying the string on the screen.
tv.setText( stringFromJNI() );
-C-side implementation
-This file contains a function that returns a string that the Java side
-requested (see Java-side implementation). The function declaration is as
+
C-side Implementation
+The {@code hello-jni.c} file is located in {@code hello-jni/jni/}. It contains a function that
+returns a string that the Java side requested). The function declaration is as
follows:
-jstring Java_com_example_hellojni_HelloJni_stringFromJNI(
-JNIEnv* env,
- jobject x )
+jstring
+Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
+ jobject thiz )
This declaration corresponds to the native function declared in the
@@ -104,12 +105,12 @@ according to the following rules:
After the last underscore, append the function name.
-Based on these rules, in this example, the function name
-{@code Java_com_example_hellojni_HelloJni_stringFromJNI} refers to a Java
+
Following these rules, this example uses the function name
+{@code Java_com_example_hellojni_HelloJni_stringFromJNI}. This name refers to a Java
function called {@code stringFromJNI()}, which resides in
{@code hellojni/src/com/example/hellojni/HelloJni.java}.
-Finally, {@code JNIEnv*} is the pointer to the VM, and
+
{@code JNIEnv*} is the pointer to the VM, and
{@code jobject} is a pointer to the implicit {@code this} object passed from
the Java side.
diff --git a/docs/html-ndk/ndk/guides/sample_na.jd b/docs/html-ndk/ndk/guides/sample_na.jd
index e6f36ba19f29a..55362cd81960f 100644
--- a/docs/html-ndk/ndk/guides/sample_na.jd
+++ b/docs/html-ndk/ndk/guides/sample_na.jd
@@ -1,4 +1,4 @@
-page.title=Sample: Native Activity
+page.title=Sample: native-activity
@jd:body
-This is a very simple example of a purely native
+
The native-activity sample resides under the NDK installation root, in
+{@code samples/native-activity}. It is a very simple example of a purely native
application, with no Java source code. In the absence of any Java source, the
-Java compiler still creates an executable stub for the Dalvik Virtual Machine
-("DVM") to run. The stub serves as a wrapper for the actual, native program,
-which lives in the .so file.
-The application itself simply renders a color onto the entire screen, and
-then changes the color partly in response to detected movement.
-AndroidManifest.xml
-Make sure not to specify an Android API level lower than 9.
-<uses-sdk android:minSdkVersion="9" />
-
Because this application has only native code, specify
-android:hasCode as false.
-<application android:label="@string/app_name"
+Java compiler still creates an executable stub for the virtual machine to run.
+The stub serves as a wrapper for the actual, native program, which lives in the {@code .so}
+file.
+
+The app itself simply renders a color onto the entire screen, and
+then changes the color partly in response to movement that it detects.
+
+AndroidManifest.xml
+
+An app with only native code must not specify an Android API level lower than 9, which introduced
+the {@code NativeActivity} framework class.
+
+
+<uses-sdk android:minSdkVersion="9" />
+
+
+The following line declares {@code android:hasCode} as {@code false}, as this app has only
+native code–no Java.
+
+
+
+<application android:label="@string/app_name"
android:hasCode="false">
-
Declare the NativeActivity class.
- <activity android:name="android.app.NativeActivity"
-
For android:value, provide the name of the shared library
-to be built, minus the initial lib and the .so
-extension. This value must be the same as the one you described for
-LOCAL_MODULE in Android.mk.
- <meta-data android:name="android.app.lib_name"
- android:value="native-activity" />
-
Android.mk
-This file tells the build system the following information:
-The name of the shared library to generate.
-LOCAL_MODULE := native-activity
-
The name of the native source-code file.
-LOCAL_SRC_FILES := main.c
-
A list of external libraries that will be used in building the binary,
-each preceded by the -l (link-against) option.
+
+
+The next line declares the {@code NativeActivity} class.
+
+
+<activity android:name="android.app.NativeActivity"
+
+
+Finally, the manifest specifies {@code android:value} as the name of the shared library to be
+built, minus the initial {@code lib} and the {@code .so} extension. This value must be the same as
+the name of {@code LOCAL_MODULE} in {@code Android.mk}.
+
+
+<meta-data android:name="android.app.lib_name"
+ android:value="native-activity" />
+
+
+Android.mk
+This file begins by providing the name of the shared library to generate.
+
+
+LOCAL_MODULE := native-activity
+
+
+Next, it declares the name of the native source-code file.
+
+
+LOCAL_SRC_FILES := main.c
+
+
+Next, it lists the external libraries for the build system to use in building the binary. The
+{@code -l} (link-against) option precedes each library name.
+
-- log is a logging library.
-- android encompasses the standard Android support APIs for NDK. The Stable APIs
-section discusses these in more detail.
-- EGL, standardized by Khronos, corresponds to the platform-specific portion
-of the graphics API.
-- OpenGL ES, the version of OpenGL for Android, depends on EGL.
+- {@code log} is a logging library.
+- {@code android} encompasses the standard Android support APIs for NDK. For more information about
+the APIs that Android and the NDK support, see Android NDK Native
+APIs.
+- {@code EGL} corresponds to the platform-specific portion of the graphics API.
+- {@code GLESv1_CM} corresponds to OpenGL ES, the version of OpenGL for Android. This library
+depends on EGL.
-Note that, for each library:
+
+For each library:
+
-- The actual file name starts with
lib, and ends with the
-.so extension. For example, the actual file name for the
-log library is liblog.so.
-- The library lives in the following directory, relative to the NDK root:
-
<ndk>/platforms/android-<sdk_version>/arch-<abi>/usr/lib/.
+- The actual file name starts with {@code lib}, and ends with the
+{@code .so} extension. For example, the actual file name for the
+{@code log} library is {@code liblog.so}.
+- The library resides in the following directory, NDK root:
+{@code <ndk>/platforms/android-<sdk_version>/arch-<abi>/usr/lib/}.
-LOCAL_LDLIBS := -llog -landroid -lEGL -lGLESv1_CM
-
A static library, android_native_app_glue, that the
-application uses to manage NativeActivity lifecycle events, along
-with touch input.
-LOCAL_STATIC_LIBRARIES := android_native_app_glue
-
The final line tells the build system to build this static library.
-ndk-build places the built library
-(libandroid_native_app_glue.a) into the obj directory
-generated during the build process. The next sample discusses the
-android_native_app_glue in more detail.
-$(call import-module,android/native_app_glue)
-
For more information about the Application.mk file, consult the Application.mk section of this guide.
-Application.mk
+
+
+LOCAL_LDLIBS := -llog -landroid -lEGL -lGLESv1_CM
+
+
+The next line provides the name of the static library, {@code android_native_app_glue}, which the
+application uses to manage {@code NativeActivity} lifecycle events and touch input.
+
+
+LOCAL_STATIC_LIBRARIES := android_native_app_glue
+
+
+The final line tells the build system to build this static library.
+The {@code ndk-build} script places the built library
+({@code libandroid_native_app_glue.a}) into the {@code obj} directory
+generated during the build process. For more information about the {@code android_native_app_glue}
+library, see its {@code android_native_app_glue.h} header and corresponding {@code .c}source file.
+
+
+
+
+$(call import-module,android/native_app_glue)
+
+
+For more information about the {@code Android.mk} file, see
+Android.mk.
+
+
+Application.mk
+
This line defines the minimum level of Android API Level support.
-APP_PLATFORM := android-10
-
Because there is no ABI definition, the build system defaults to
-building only for armeabi.
-main.c
+
+
+APP_PLATFORM := android-10
+
+
+Because there is no ABI definition, the build system defaults to building only for
+{@code armeabi}.
+
+main.c
This file essentially contains the entire progam.
+
The following includes correspond to the libraries, both shared and static,
-enumerated in Android.mk.
-#include <EGL/egl.h>
+enumerated in {@code Android.mk}.
+
+
+#include <EGL/egl.h>
#include <GLES/gl.h>
#include <android/sensor.h>
#include <android/log.h>
#include <android_native_app_glue>
-
android_native_app_glue calls the following function,
+
+
+The {@code android_native_app_glue} library calls the following function,
passing it a predefined state structure. It also serves as a wrapper that
-simplifies handling of NativeActivity callbacks.
-void android_main(struct android_app* state) {
-Next, the program handles events queued by the glue library. The event
+simplifies handling of {@code NativeActivity} callbacks.
+
+
+void android_main(struct android_app* state) {
+
+
+Next, the program handles events queued by the glue library. The event
handler follows the state structure.
-struct engine engine;
+
+
+struct engine engine;
-// Make sure glue isn't stripped by suppressing link-time optimization that
-removes unreferenced code.
+
+// Suppress link-time optimization that removes unreferenced code
+// to make sure glue isn't stripped.
app_dummy();
@@ -110,21 +175,29 @@ state->userData = &engine;
state->onAppCmd = engine_handle_cmd;
state->onInputEvent = engine_handle_input;
engine.app = state;
-
The application prepares to start monitoring the sensors, using the
-APIs in sensor.h.
- engine.sensorManager = ASensorManager_getInstance();
+
+
+The application prepares to start monitoring the sensors, using the
+APIs in {@code sensor.h}.
+
+
+ engine.sensorManager = ASensorManager_getInstance();
engine.accelerometerSensor =
ASensorManager_getDefaultSensor(engine.sensorManager,
- ASENSOR_TYPE_ACCELEROMETER);
+ ASENSOR_TYPE_ACCELEROMETER);
engine.sensorEventQueue =
ASensorManager_createEventQueue(engine.sensorManager,
- state->looper, LOOPER_ID_USER, NULL, NULL);
-Now, a loop begins, in which the application polls the system for
+ state->looper, LOOPER_ID_USER, NULL, NULL);
+
+
+Next, a loop begins, in which the application polls the system for
messages (sensor events). It sends messages to
-android_native_app_glue, which checks to see whether they match
-any onAppCmd events defined in android_main. When a
+{@code android_native_app_glue}, which checks to see whether they match
+any {@code onAppCmd} events defined in {@code android_main}. When a
match occurs, the message is sent to the handler for execution.
-while (1) {
+
+
+while (1) {
// Read all pending events.
int ident;
int events;
@@ -135,7 +208,7 @@ match occurs, the message is sent to the handler for execution.
// If animating, we loop until all events are read, then continue
// to draw the next frame of animation.
while ((ident=ALooper_pollAll(engine.animating ? 0 : -1, NULL,
-&events,
+ &events,
(void**)&source)) >= 0) {
@@ -165,9 +238,12 @@ match occurs, the message is sent to the handler for execution.
return;
}
}
-Once the queue is empty, and the program exits the polling loop, the
+
+
+Once the queue is empty, and the program exits the polling loop, the
program calls OpenGL to draw the screen.
- if (engine.animating) {
+
+ if (engine.animating) {
// Done with events; draw next animation frame.
engine.state.angle += .01f;
if (engine.state.angle > 1) {
@@ -179,16 +255,5 @@ program calls OpenGL to draw the screen.
// is no need to do timing here.
engine_draw_frame(&engine);
}
-}
-
-
-
-
-
1.8.5
-