我编码JNI应用程序。 logcat的指示日志文件存在的数据/日志/ dumpstate_app_native.txt 同样的东西，在系统的墓碑。当我访问了三星的Infuse作为媒体设备我没有看到任何这样的文件。事实上，我没有看到我的应用程序的数据文件要么？他们在哪里，我看到其他的应用程序包，但没有太多的数据段下。以下是我在logcat中看到：

dumpstate /data/log/dumpstate_app_native.txt 复制/数据/墓碑/ tombstone_01到DropBox的（SYSTEM_TOMBSTONE） 写堆栈跟踪到/data/anr/traces.txt

我做搜索设备作为媒体设备的* .TXT和一无所获。

解决方案

您将无法读取该墓碑文件，除非您使用的是仿真器或根电话。 它的logcat调试级别打印出来的墓碑（那就是大核心转储复制墓碑消息前右）。应该有一个部分，看起来是这样的：

  01-18 16：28：04.334 16759 16759我DEBUG：SCR 80000012
01-18 16：28：04.334 16759 16759我DEBUG：
01-18 16：28：04.384 16759 16759我DEBUG：＃00件00007f84 /data/data/com.myapp/lib/myjnilib.so
01-18 16：28：04.384 16759 16759我DEBUG：＃01件00008f80 /data/data/com.myapp/lib/myjnilib.so
01-18 16：28：04.394 16759 16759我DEBUG：＃02件00002c6a /data/data/com.myapp/lib/myjnilib.so
01-18 16：28：04.394 16759 16759我DEBUG：＃03件00002ea8 /data/data/com.myapp/lib/myjnilib.so
01-18 16：28：04.394 16759 16759我DEBUG：＃04件00003178 /data/data/com.myapp/lib/myjnilib.so
01-18 16：28：04.394 16759 16759我DEBUG：＃05件00011e74 /system/lib/libdvm.so
...
 

这是缩写的堆栈跟踪。你需要使用addr2line工具NDK的判断函数，文件和行号，这些十六进制地址是指。在我的OSX系统中，命令获取堆栈跟踪的第一行看起来是这样的：

/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/$p$pbuilt/darwin-x86/bin/arm-linux-androideabi-addr2line -f -e myJNIproject / OBJ /本地/ armeabi / myjnilib.so 0x00007f84

其中的 myJNIproject / OBJ /本地/ armeabi / myjnilib.so 的是包含行号信息的 myjnilib.so 的版本。

I'm coding JNI application. Logcat indicates that log files exist data/log/dumpstate_app_native.txt Also stuff in system tombstones. When I access the Samsung Infuse as media device I don't see any such files. In fact I don't see my application data files either? Where are they, I do see other application packages but not much under data period. Here is what I see in logcat:

dumpstate /data/log/dumpstate_app_native.txt copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE) Wrote stack traces to '/data/anr/traces.txt

I did search on device as media device for *.txt and found nothing.

解决方案

You won't be able to read the tombstone files unless you are using an emulator or a rooted phone. Logcat does print out the tombstone at debug level (it's that big core dump right before the "copying tombstone" message). There should be a section that looks something like this:

01-18 16:28:04.334 16759 16759 I DEBUG   :  scr 80000012
01-18 16:28:04.334 16759 16759 I DEBUG   : 
01-18 16:28:04.384 16759 16759 I DEBUG   :          #00  pc 00007f84  /data/data/com.myapp/lib/myjnilib.so
01-18 16:28:04.384 16759 16759 I DEBUG   :          #01  pc 00008f80  /data/data/com.myapp/lib/myjnilib.so
01-18 16:28:04.394 16759 16759 I DEBUG   :          #02  pc 00002c6a  /data/data/com.myapp/lib/myjnilib.so
01-18 16:28:04.394 16759 16759 I DEBUG   :          #03  pc 00002ea8  /data/data/com.myapp/lib/myjnilib.so
01-18 16:28:04.394 16759 16759 I DEBUG   :          #04  pc 00003178  /data/data/com.myapp/lib/myjnilib.so
01-18 16:28:04.394 16759 16759 I DEBUG   :          #05  pc 00011e74  /system/lib/libdvm.so
...

This is the abbreviated stacktrace. You'll need to use the addr2line tool in the NDK to determine the function, file and line number that those hex addresses refer to. On my OSX system, the command to get the first line of the stacktrace looks like this:

/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-addr2line -f -e myJNIproject/obj/local/armeabi/myjnilib.so 0x00007f84

where myJNIproject/obj/local/armeabi/myjnilib.so is the version of myjnilib.so that contains line number information.