am 9ae00645: Merge change 26280 into eclair

Merge commit '9ae0064588a6f922834c8998ef91f04a0d19b1cc' into eclair-plus-aosp

* commit '9ae0064588a6f922834c8998ef91f04a0d19b1cc':
  Another doc update.

1 files changed, 16 insertions, 4 deletions

diff --git a/docs/jni-tips.html b/docs/jni-tips.html
index 30207bf37..13461b55d 100644
--- a/docs/jni-tips.html
+++ b/docs/jni-tips.html
@@ -159,7 +159,9 @@ globalRef = env->NewGlobalRef(localRef);
 </pre>
 
 The global reference is guaranteed to be valid until you call
-<code>DeleteGlobalRef</code>.
+<code>DeleteGlobalRef</code>.  This pattern is frequently used for
+cached copies of class objects obtained from <code>FindClass</code>.
+</p><p>
 </p><p>
 All JNI methods accept both local and global references as arguments.
 It's possible for references to the same object to have different values;
@@ -480,14 +482,24 @@ You can also call <code>System.load()</code> with the full path name of the
 shared library.  For Android apps, you can get the full path to the
 application's private data storage area from the context object.
 </p><p>
-Dalvik does support "discovery" of native methods that are named in a
+This is the recommended approach, but not the only approach.  The VM does
+not require explicit registration, nor that you provide a
+<code>JNI_OnLoad</code> function.
+You can instead use "discovery" of native methods that are named in a
 specific way (see <a href="http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615">
-    the JNI spec</a> for details), but this is a less desirable
-approach.  It requires more space in the shared object symbol table,
+    the JNI spec</a> for details), though this is less desirable.
+It requires more space in the shared object symbol table,
 loading is slower because it requires string searches through all of the
 loaded shared libraries, and if a method signature is wrong you won't know
 about it until the first time the method is actually used.
 </p><p>
+One other note about <code>JNI_OnLoad</code>: any <code>FindClass</code>
+calls you make from there will happen in the context of the class loader
+that was used to load the shared library.  Normally <code>FindClass</code>
+uses the loader associated with the method at the top of the interpreted
+stack, or if there isn't one (because the thread was just attached to
+the VM) it uses the "system" class loader.
+</p><p>
 
 
 </p><h2><a name="64bit"> 64-bit Considerations </a></h2>