summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorElliott Hughes <enh@google.com>2014-11-27 18:57:00 +0000
committerAndroid Git Automerger <android-git-automerger@android.com>2014-11-27 18:57:00 +0000
commit07b4a291319ec48a272451789ab0fbbf8d55a050 (patch)
treec01735448e0fd151748ed82c61a897f05b8a402b
parent09eeab7cbffae64add657f1a1e7ab6c7f20b6d9b (diff)
parent3e2848d249cafbf1cc79b600eab9bce055adcf8e (diff)
downloadframeworks_base-07b4a291319ec48a272451789ab0fbbf8d55a050.zip
frameworks_base-07b4a291319ec48a272451789ab0fbbf8d55a050.tar.gz
frameworks_base-07b4a291319ec48a272451789ab0fbbf8d55a050.tar.bz2
am 3e2848d2: am 8fc88562: am 85e21bd5: Mention ProGuard in the JNI documentation.
* commit '3e2848d249cafbf1cc79b600eab9bce055adcf8e': Mention ProGuard in the JNI documentation.
-rw-r--r--docs/html/training/articles/perf-jni.jd26
1 files changed, 17 insertions, 9 deletions
diff --git a/docs/html/training/articles/perf-jni.jd b/docs/html/training/articles/perf-jni.jd
index 1a40f62..5a9fa1e 100644
--- a/docs/html/training/articles/perf-jni.jd
+++ b/docs/html/training/articles/perf-jni.jd
@@ -635,20 +635,31 @@ avoid some problems.
<a name="faq_FindClass" id="faq_FindClass"></a>
<h2>FAQ: Why didn't <code>FindClass</code> find my class?</h2>
+<p>(Most of this advice applies equally well to failures to find methods
+with <code>GetMethodID</code> or <code>GetStaticMethodID</code>, or fields
+with <code>GetFieldID</code> or <code>GetStaticFieldID</code>.)</p>
+
<p>Make sure that the class name string has the correct format. JNI class
names start with the package name and are separated with slashes,
such as <code>java/lang/String</code>. If you're looking up an array class,
you need to start with the appropriate number of square brackets and
must also wrap the class with 'L' and ';', so a one-dimensional array of
-<code>String</code> would be <code>[Ljava/lang/String;</code>.</p>
+<code>String</code> would be <code>[Ljava/lang/String;</code>.
+If you're looking up an inner class, use '$' rather than '.'. In general,
+using <code>javap</code> on the .class file is a good way to find out the
+internal name of your class.</p>
+
+<p>If you're using ProGuard, make sure that
+<a href="{@docRoot}tools/help/proguard.html#configuring">ProGuard didn't
+strip out your class</a>. This can happen if your class/method/field is only
+used from JNI.
<p>If the class name looks right, you could be running into a class loader
issue. <code>FindClass</code> wants to start the class search in the
class loader associated with your code. It examines the call stack,
which will look something like:
<pre> Foo.myfunc(Native Method)
- Foo.main(Foo.java:10)
- dalvik.system.NativeStart.main(Native Method)</pre>
+ Foo.main(Foo.java:10)</pre>
<p>The topmost method is <code>Foo.myfunc</code>. <code>FindClass</code>
finds the <code>ClassLoader</code> object associated with the <code>Foo</code>
@@ -656,12 +667,9 @@ class and uses that.</p>
<p>This usually does what you want. You can get into trouble if you
create a thread yourself (perhaps by calling <code>pthread_create</code>
-and then attaching it with <code>AttachCurrentThread</code>).
-Now the stack trace looks like this:</p>
-<pre> dalvik.system.NativeStart.run(Native Method)</pre>
-
-<p>The topmost method is <code>NativeStart.run</code>, which isn't part of
-your application. If you call <code>FindClass</code> from this thread, the
+and then attaching it with <code>AttachCurrentThread</code>). Now there
+are no stack frames from your application.
+If you call <code>FindClass</code> from this thread, the
JavaVM will start in the "system" class loader instead of the one associated
with your application, so attempts to find app-specific classes will fail.</p>