这几天看JNI,没有基础,那真是难受……把看到的相关资料记录一下,也分享给刚開始学习的人。
‘ndk-gdb’ Overview
重要:假设你要调试线程相关的程序。请阅读以下的‘Thread Support’部分。
1.使用方法:
-------------
android r4引入了一个叫着‘ndk-gdb’的脚本。可以很easy的为NDK生成的机器码启动一个debugsession。
这个脚本位于NDK的顶层文件夹下,它必须从你应用程序的文件夹或者子文件夹下。用命令行的方式来调用。比如:
cd $PROJECT
$NDK/ndk-gdb
$NDK指向你NDK的安装路径。你能够创建一个别名或者把$NDK增加到你的环境变量PATH中,这样能够避免每次都要输入完整的路径名。
重要:本地调试仅仅有在下面全部条件都满足时才干工作:
1.你的应用程序必须用‘ndk-build’脚本编译。
用之前的方式‘make APP=<name>’编译,NDK是不支持的。
2.你的应用程序必须是可调试的:
换句话说,AndroidManifest.xml的<application>必须设置android:debuggable为true。
3. 你的应用程序必须执行在Android 2.2或者更高的版本号中:
ndk-gdb执行在Android 2.2版本号之前是不行的。
这并不意味着。你的应用程序的目标API必须是2.2+。仅仅是debugging
session仅仅能执行在2.2+的设备或者模拟器上。
很很很重要!!
假设你使用Eclipse ADT插件编译应用程序,必须确保使用0.9.7或之后的版本号。
假设你使用‘ant’编译工具,必须确保使用的是SDK平台组件的最新版本号。
以下是最低版本号的要求:
Android 1.5 r4
Android1.6 r3
Android2.1 r2
Android2.2 r1
这些都能够通过SDK的更新来获得。
假设这些条件不满足,生成的apk将不会包括必要的支持文件,本地调试将不能工作。
假设发现了问题。‘ndk-gdb’会处理很多错误情况和存储错误信息。比如:
-检查adb是否在你的path中。
-检查你的应用程序在manifest中是否声明了debuggable。
-检查设备上已经安装的具有同样包名的应用程序是否是可调试的。
默认情况下,ndk-gdb会搜索已经正在执行的应用程序进程,假设没有找到的话会报错。可是你能够在启动debugging session之前,使用--start或--launch=<name>选项来自己主动启动activity。
当gdb成功attach到你应用程序的进程中,在session建立后,ndk-gdb会有一个GDB提示:在生成的本地库中查找源文件和symbol/debug
versions。
你能够用‘b <location>’设置断点,用‘c’(continue)继续运行。很多其它的命令请查看GDB手冊。
重要:当退出GBD提示。应用程序的调试进程就会停止!这是gdb的一个限制。
重要:当gdb找不到系统库(如libc.so, libstdc++.so, liblog.so, libcutils.so等)的时候,GDB停止退出前。会列出一长串的错误信息。
这是正常的。由于在你的开发机器上,没有这些库的symbol/debug versions来相应你的目标设备。
你能够安全的忽略这些信息。
2. 选项:
------------
你能够用‘ndk-gdb --help’命令列出这些选项:
--verbose:
打印native debuggingsession启动时的具体信息。
当你不能连接、ndk-gdb打印的错误信息不够的时候,才须要它来调试问题。
--force:
默认情况下,假设发现另外一个nativedebugging session执行在同一台设备上。ndk-gdb会崩溃。使用--force会kill掉那个session,然后启动一个新的session替换它。
注意调试的程序不会被kill,将会再一次stopped。
--start:
默认情况下。ndk-gdb会试图attach到一个正在执行的应用程序的实例上。你能够在debugging sessiong之前,使用--start来显示的启动你的应用程序。
注意:这个选项会启动manifest中第一个launchable的activity,使用--launch=<name>能够启动其它的activity。--launch-list能够列出全部这种activity。
--launch=<name>:
除了能够启动指定的activity外。其它的和start类似。
假设你的manifest定义了非常多launchable的activity,这个选项是比較实用的。
--launch-list:
列出manifest中全部launchable的activity。使用--start时。第一个launchable的activity被启动。
--project=<path>:
指定应用程序的project所在文件夹。假设你不想cd到你project的文件夹中,这个选项是比較实用的。
--port=<port>
默认情况下,ndk-gdb使用本地TCPport5039连接到debugged的应用程序。通过使用不同的port。在同一台开发机器中。能够在不同的设备/模拟器上执行调试程序。
--adb=<file>:
假设不在你的path中,能够指定adb工具的路径。
-d,-e,-s <serial>
这些标志和ADB类似。能够处理多台设备/模拟器连接到你机器上的情况。
-d:连接到一个单独的物理设备
-e:连接到一个单独的模拟
-s:连接到<serial>指定的真机或者模拟器,<serial>是用‘adb
devices’命令列出的设备 的名称。
你也能够定义ADB_SERIAL环境变量来指定你的设备。不须要使用这个选项。
--exec=<file>:
-x<file>:
连接到调试进程后,会执行在<file>文件里找到的GDB初始化命令。当你要做一些反复的事情,这是很实用的。比如建立一序列的断点,然后自己主动恢复执行。
3.必要条件
---------------------
眼下‘ndk-gdb’须要执行在Unix shell上。这意味着在Windows系统中必须执行在Cygwin上。我们希望在以后的NDK版本号中可以摆脱这个限制。
NDK的其它要求:比如 GNU Make3.81或更高版本号。
4. 线程支持:
------------------
假设你的应用程序执行在Android 2.3之前。ndk-gdb不能正确的调试本地线程,debug的时候仅仅能把断点打在主线程中,全然会忽略其它线程的执行。
造成这个问题的最初原因是非常复杂的。本质上是在这个平台上不幸有一个bug,而这个是近期才发现的。
执行时。NDK自带的gdbserver二进制文件有特殊的代码来检測这个条件,而且会自己主动调整它的行为(换句话说,当编译代码的时候。你不须要不论什么的特殊操作)。
这意味着在实践中:
- 假设你执行在Android 2.3。或者2.3之前的平台可是已经修复了这个bug。你能够自己主动的调试本地线程。
- 假设不是。你仅仅能在主线程中调试(像前面所说的)。当启动ndk-gdb(在gdb prompt之前)。你会看到以下的信息:
Thread debugging is unsupported on this Android platform!
假设你在非主线程中运行的函数打了断点,程序会退出。同一时候GDB会输出下面信息:
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.