如何定位Android NDK开发中遇到的错误
我的图书馆
如何定位Android NDK开发中遇到的错误
NDK是什么？
NDK 是在SDK前面又加上了“原生”二字，即Native Development
Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C /
C++之类的原生代码语言执行部分程序。NDK包括：
/ C++生成原生代码库所需要的工具和build files；
将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application
packages files ，即.apk文件）中；
支持所有未来Android平台的一系列原生系统头文件和库。
为何要用到NDK？概括来说主要分为以下几种情况：
代码保护，由于APK的Java层代码很容易被反编译，而C/C++库反汇难度较大；
在NDK中调用第三方C/C++库，因为大部分的开源库都是用C/C++代码编写的；
便于移植，用C/C++写的库可以方便地在其他的嵌入式平台上再次使用。
JNI与NDK的关系
Interface（JNI）标准是Java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口，它使得在Java虚拟机（VM）内部运行的Java代码能够与用其它编程语言（如C、C++和汇编语言）编写的应用程序和库进行交互操作。
简单来说，可以认为NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so需要大量操作，而NDK的作用则是简化了这个过程。
哪些常见的NDK类型异常会导致程序Crash？
NDK编译生成的.so文件作为程序的一部分，在运行发生异常时同样会造成程序崩溃。不同于Java代码异常造成的程序崩溃，在NDK的异常发生时，程序在Android设备上都会立即退出，即通常所说的闪退，而不会弹出“程序xxx无响应，是否立即关闭”之类的提示框。
NDK是使用C/C++来进行开发的，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存无效访问、无效对象、内存泄露、堆栈溢出等常见的问题，最后都是同一个结果：程序崩溃。例如我们常说的空指针错误，就是当一个内存指针被置为空（NULL）之后再次对其进行访问；另外一个经常出现的错误是，在程序的某个位置释放了某个内存空间，而后在程序的其他位置试图访问该内存地址，这就会产生无效地址错误。常见的错误类型如下：
初始化错误；
访问错误；
内存泄露；
参数错误；
堆栈溢出；
类型转换错误；
数字除0错误。
如何发现并解决NDK错误？
利用Android
NDK开发本地应用时，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android
NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，如何通过两种不同的方法，来定位错误的函数名和代码行。
首先，来看看我们在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），下面代码中：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中，
std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。我们记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。
下面我们来看看发生崩溃（闪退）时系统打印的logcat日志：
如果你看过logcat打印的NDK错误的日志就会知道，我省略了后面很多的内容，很多人看到这么多密密麻麻的日志就已经头晕脑胀了，即使是很多资深的Android开发者，在面对NDK日志时也大都默默地选择了无视。
其实，只要你细心的查看，再配合Google
提供的工具，完全可以快速地准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。
第一种方法：ndk-stack
这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk
–stack命令也有两种方式
使用方法：
你的代码必须是使用ndk build打包出来的。这样地址信息就会是
$PROJECT_PATH/obj/local/&abi&
&abi& 是根据你的手机的ABI来的。（比如：’armeabi‘就是默认值）
打开你的控制台，输入（$NDK是你的环境变量，指向NDK目录）：
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
大工完成。
实时分析日志
在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：
当崩溃发生时，会得到如下的信息：
我们重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，因此会发现如下关键信息：
回想一下我们的代码，在JNI_OnLoad()函数中（第61行），我们调用了willCrash()函数；在willCrash()函数中（第69行），我们制造了一个错误。这些信息都被准确无误的提取了出来！是不是非常简单？
先获取日志再分析
这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。
第二种方法：使用addr2line和objdump命令
这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。
先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel
x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。
在NDK中自带了适用于各个操作系统和CPU架构的工具链，其中就包含了这两个命令，只不过名字稍有变化，你可以在NDK目录的toolchains目录下找到他们。以我的Mac电脑为例，如果我要找的是适用于armeabi架构的工具，那么他们分别为arm-linux-androideabi-addr2line和arm-linux-androideabi-objdump；位置在下面目录中，后续介绍中将省略此位置：
假设你的电脑是Windows系统，CPU架构为mips，那么你要的工具可能包含在一下目录中：
接下来就让我们来看看如何使用这两个工具，下面具体介绍。
找到日志中的关键函数指针
其实很简单，就是找到backtrace信息中，属于我们自己的so文件报错的行。
首先要找到backtrace信息，有的手机会明确打印一行backtrace（比如我们这次使用的手机），那么这一行下面的一系列以“#两位数字
pc”开头的行就是backtrace信息了。有时可能有的手机并不会打印一行backtrace，那么只要找到一段以“#两位数字 pc
”开头的行，就可以了。
其次要找到属于自己的so文件报错的行，这就比较简单了。找到这些行之后，记下这些行中的函数地址。
使用addr2line查找代码位置
执行如下的命令，多个指针地址可以在一个命令中带入，以空格隔开即可
结果如下：
从addr2line的结果就能看到，我们拿到了我们自己的错误代码的调用关系和行数，在hello-jni.cpp的69行和61行（另外两行因为使用的是标准函数，可以忽略掉），结果和ndk-stack是一致的，说明ndk-stack也是通过addr2line来获取代码位置的。
使用objdump获取函数信息
通过addr2line命令，其实我们已经找到了我们代码中出错的位置，已经可以帮助程序员定位问题所在了。但是，这个方法只能获取代码行数，并没有显示函数信息，显得不那么“完美”，对于追求极致的程序员来说，这当然是不够的。下面我们就演示一下怎么来定位函数信息。
首先使用如下命令导出函数表：
在生成的asm文件中查找刚刚我们定位的两个关键指针0004f58：
从这两张图可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系统中，asm文件的格式不是完全相同，但都大同小异，请大家仔细比对），这两个指针分别属于willCrash()和JNI_OnLoad()函数，再结合刚才addr2line的结果，那么这两个地址分别对应的信息就是：
相当完美，和ndk-stack得到的信息完全一致！
Testin崩溃分析如何帮开发者发现NDK错误
以上提到的方法，只适合在开发测试期间，如果你的应用或游戏已经上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。
目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，国内的Testin和国外的crittercism都可以提供类似服务。
Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等，SDK将这些信息上报至Testin云服务平台，在平台进行唯一性的处理、并可以自定义时段进行详尽的统计分析，从多维度展示程序崩溃的信息和严重程度；最新版本还支持用户自定义场景，方便开发者定位问题所在。
从用户手机上报的堆栈信息，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传，就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次开发者编译之后都会改变，很有可能我们发布之后就已经变了，因为开发者会修改程序。在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。
TA的最新馆藏Android之NDK开发一第一个测试
前两天研究了一下NDK开发，然而没有成功。今天兴趣盎然，再试试，不知道会不会成功，我将记录我在学习过程中遇到的一些困难，以及成功后的效果。我当前的状态是以及学习了一段时间开发，用的环境是Android Studio（2.1.1），所以jdk与Android studio 的配置就不描述了，从NDK开始。
第一步：安装NDK
选择NDK点击应用，开始下载。
解压，卡这儿半小时了，怎么办？
停止，重新下载，还是卡这儿，好吧，安装软件有时候也得看运气，把安装的删除了，然后重启电脑，再下载，睡觉，第二天醒来，装好了，继续出发。
第二步：修改gradle
修改APP的gradle
//ndk编译生成.so文件
moduleName &hello_jni&
//生成的so名字
abiFilters &armeabi&, &armeabi-v7a&, &x86&
//输出指定三种abi体系结构下的so库。
我这样修改，后面的不加，看会出现什么情况：
defaultConfig {
applicationId &com.example.hj.hellojni&
minSdkVersion 18
targetSdkVersion 23
versionCode 1
versionName &1.0&
moduleName=&hello_jni&
}//主要是这句话
buildTypes {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
出错了，出现了如下错误：
Error:(15, 0) Gradle DSL method not found: 'ndk()'
Possible causes:
The project 'HelloJNI' may be using a version of Gradle that does not contain the method.
The build file may be missing a Gradle plugin.
好吧，网上搜了一下，好像应该这样写：
defaultConfig {
applicationId &com.example.hj.hellojni&
minSdkVersion 18
targetSdkVersion 23
versionCode 1
versionName &1.0&
moduleName=&hello_jni&
}//写在这个地方
这次还是出错了，不过错误不一样：
Error:(13, 0) NDK integration is deprecated in the current plugin.
按照意思添加即可，在gradle.properties中添加android.http://blog.csdn.net/qq_/article/details/useDeprecatedNdk=true
好了，不报错了，开i始编写代码：
第三步：添加代码
在MainActivity这样写：
public class MainActivity extends AppCompatActivity {
System.loadLibrary(&hello_jni&);
//加载so库,这儿的名字要与gradle声明的相同
private native String getJNIString();//声明本地方法
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextView textview =(TextView)findViewById(R.id.hellowjni);
textview.setText(getJNIString());
Toast.makeText(MainActivity.this, getJNIString(), Toast.LENGTH_SHORT).show();
好了，activity的编写就完成了，接下来该编写C语言代码了。
第四步：编写C语言代码并运行
前面声明本地方法后，方法名会高亮，如下：
vcjnz8LQp7n7o6y74dfUtq+0tL2o0ru49s7EvP6jrL7NysfS1MztvNO+ssystPrC67/pyrG1xNfWt/u0rs6qw/ujrM7Sz+vTprjDQVO74daxvdPJ+rPJuq/K/bXEo6y1q8rHsqLDu9PQo6y/ycTcu7nDu7j80MKwyaOsu/LV387StcSw5rG+09C147XNo7o8YnIgLz4NCjxpbWcgYWx0PQ=="这里写图片描述" src="/uploadfile/Collfiles/24.png" title="\" />
先不管，我们自己来写，再回到MainActivity中，将鼠标放在方法名上：如下
这就是我们的C语言函数名，我们需要在前面生成的c文件中写程序。
具体如下：
jstring _com_example_hj_hellojni_MainActivity_getJNIString( JNIEnv* env,jobject thiz ) {
return (*env)-&NewStringUTF(env, &Hello JNI !&);
好了，C语言的编写也完成了，我们开始运行吧，运行结果如下，成功：
1、我们的so库到哪去了？
运行成功，在工程中搜索so,找到了so文件的目录：
前面是这样配置gradle的:
moduleName=&hello_jni&
}//主要是这句话
默认生成所有CPU平台的so库，所以这儿生成的so库比较多。
现在我们这样配置：
//ndk编译生成.so文件
moduleName &hello_jni&
//生成的so名字
abiFilters &armeabi&, &armeabi-v7a&, &x86&
//输出指定三种abi体系结构下的so库。
运行后得到的so库是这样的：
这儿lib与obj下都是so库，这儿找到了这样一句话：
As part of the build process, the files in the libs folder have been stripped of symbols and debugging information. So you'll want to keep two copies of each of your .so files: One from the libs folder to install on the Android device, and one from the obj folder to install for GDB to get symbols from.
也就是说，libs目录下生成的库是剥离了符号表与调试信息的，而obj下的库是带有调试信息的，我们都可以使用。
2、其他人怎么使用我写的so库？
记得使用百度地图sdk的时候导入过so库，好像记得是导入到libs下面。
照着它的样子，导入自己写的so库。
新建的一个module，取名test，它的MainActivity的代码和上面一个的相同，其他什么都不用管，包名是package com.example.。
然后运行，程序崩溃，报错如下：
09-09 09:38:26.361 /com.example.test E/art: No implementation found for java.lang.String com.example.test.MainActivity.getJNIString() (tried Java_com_example_test_MainActivity_getJNIString and Java_com_example_test_MainActivity_getJNIString__)
找不到本地方法的实现，看报错的原因，它在找本地方法时是根据新建的module的包名找方法的。
so库中的方法名是Java_com_example_hj_hellojni_MainActivity_getJNIString
而在现在的module中找的是
Java_com_example_test_MainActivity_getJNIString
好吧，想想造成这个的原因是，新module的中调用本地方法时，会根据自己的包名来找本地方法，与so库中的方法名不同，当然就找不到本地方法的实现了，先这样做一个测试。
so库测试一
首先，建一个module，取名testLib,这个module不是app，而是Android Library，建成后，
第一步修改gradle，和上面相同，添加：
//ndk编译生成.so文件
moduleName &hello_jni&
//生成的so名字
abiFilters &armeabi&, &armeabi-v7a&, &x86&
//输出指定三种abi体系结构下的so库。
第二步创建类：
package com.example.
public class InitLib {
System.loadLibrary(&hello_jni&);
//加载so库,这儿的名字要与gradle声明的相同
public native String getJNIString();//声明本地方法
第三步创建C语言代码：步骤、代码和前面的都相同，注意c语言中的函数名即可。
第四步修改前面的test，将其中的MainActivity修改，注意testLib的引包：
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
TextView textview = (TextView) findViewById(R.id.hellowjni);
String s = new InitLib().getJNIString();
textview.setText(s);
Toast.makeText(MainActivity.this, s, Toast.LENGTH_SHORT).show();
运行，想要的结果又出来了。
来看看我们的testLib
这儿它又生成了so库， 调用时，就是调用的这儿的so库，别人想用so库，只要把library的module给他，让他引入，然后就像test的MainActivity那样调用就行了。
但是，还没完，记得使用百度地图时，百度给的是so库和jar包， 给的不是library，想想也是，不是开源的，就应该给so库和jar包，而不是library。
现在，我们再做个实验。
so库测试二
将testLib生成的so库拷贝到test的libs下，结果如下：
然后，删除testLib中gradle中添加的代码：
//ndk编译生成.so文件
moduleName &hello_jni&
//生成的so名字
abiFilters &armeabi&, &armeabi-v7a&, &x86&
//输出指定三种abi体系结构下的so库。
删除添加的jni以及C语言文件
再运行试试，报错了&:
09-09 10:25:49.040 /com.example.test E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.example.test, PID: 15302
java.lang.UnsatisfiedLinkError: com.android.tools.fd.runtime.IncrementalClassLoader$DelegateClassLoader[DexPathList[[dex file &/data/data/com.example.test/files/instant-run/dex/slice-support-annotations-23.4.0_0fc70fcbf9af741b0e3a91ead8e096-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_9-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_8-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_7-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_6-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_5-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_4-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_3-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_2-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_1-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-slice_0-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-internal_impl-23.4.0_d11d62ffebc60ff68c1-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-com.android.support-support-vector-drawable-23.4.0_286fb307ef2e5ebb844e-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-com.android.support-support-v4-23.4.0_df88297ba1abd7fa68c5bb15c41f3-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-com.android.support-appcompat-v7-23.4.0_7cb187cf245c4ef9f5bd7bb029aa1-classes.dex&, dex file &/data/data/com.example.test/files/instant-run/dex/slice-com.android.support-animated-vector-drawable-23.4.0_90f456ae3bbbade7285eb6faea927e851bb72c6c-classes.dex&],nativeLibraryDirectories=[/vendor/lib, /system/lib, /vendor/lib, /system/lib]]] couldn't find &libhello_jni.so&
at java.lang.Runtime.loadLibrary(Runtime.java:366)
at java.lang.System.loadLibrary(System.java:988)
at com.example.testlib.InitLib.(InitLib.java:10)
at com.example.test.MainActivity.onCreate(MainActivity.java:22)
找不到so文件，怎么办，百度，找到这么一句话：
apk安装时，会把apk中libs目录下armeabi的SO拷贝到应用的私有目录下。所以libs里没有放入SO，运行时肯定找不到SO。
但是我的确放进去了啊，怎么回事？
回头看看百度地图是怎么使用so库的。
在src/main/目录下新建jniLibs目录，工程会自动加载src目录下的so动态库，放入libBaiduMapSDK_vX_X_X_X.so
哦，原来如此，要放到jniLibs下面啊，那我前面那样做可以吗？可以的，只是工程并不会自动加载libs下的so，需在gradle编译时，通过加入代码： jniLibs.srcDir &libs& 来说明so的路径为该libs路径才可以。
先来试试jniLibs的方法吧，移动文件：
移动后，再次运行，又出错了：
09-09 11:41:08.962 /com.example.test E/art: No implementation found for java.lang.String com.example.testlib.InitLib.getJNIString() (tried Java_com_example_testlib_InitLib_getJNIString and Java_com_example_testlib_InitLib_getJNIString__)
又出现这个错误了，so库是找到了，并且需要的函数名称和我们testLib中的相同，但是找不到函数，唉，可能是编写C语言时直接将jni拷过去，函数名没改，导致函数名错误，不能偷懒啊！重复前面的工作，生成一次so库，删除testLib下的gradle配置，jni，运行成功。
接下来的任务就是将我们的testLib打包成jar就OK了，别人使用时，导入so库和jar文件就可以了。
总结（纯属个人理解，欢迎指教）
NDK开发，就是用C/C++编写代码，使得运行效率更高。编写的代码将打包成so库的形式来供我们使用，加载so库：
System.loadLibrary(&hello_jni&);
在Android中，使用之前需要使用native关键字修饰方法，而C语言中实现，它的函数名是由当前引用的包名+方法名，&.&将用&_&代替来命名。一、常见的几个错误及其解决办法
1. android.mk文件不存在
错误代码形如：
AndroidNDK: Your APP_BUILD_SCRIPT points to an unknown file: ./jni/Android.mk&
/cygdrive/h/heima6/jni2/ziliao/android-ndk-r7b/build/core/add-application.mk:133:*** Android NDK: Aborting...&&& 。 停止。
解决办法：
创建Android.mk文件。
2.android.mk文件的配置信息有错误
错误代码形如：
***Android NDK: Missing LOCAL_MODULE before including BUILD_SHARED_LIBRARY injni/Android.mk&&& 。 停止。
解决办法：
修改Android.mk文件中的错误。有时候可能是一些看不见的特色字符导致，可以删除后重新建立一个。
3.c代码语法出现错误,编译不通过Error1.
错误代码形如：
make:*** [obj/local/armeabi/objs/Hello/Hello.o]Error 1
解决办法：
检查C程序代码
4.java层c代码库没有找到
错误代码形如：
Causedby: java.lang.UnsatisfiedLinkError:Library Hell0 not found静态加载代码库的时候代码库没有找到.(调用库时出错)
解决办法：
检查库库的名字，看是否写错了。看
5.c代码函数签名出现错误(函数名出错)
错误代码形如：
Causedby: java.lang.UnsatisfiedLinkError: hello_from_c
解决办法：
C代码中函数名不合特定规范，改过来就行了。
6. 其他隐含错误
如：在C代码中视图去访问已经释放了的内存空间。
二、查错利器logcat，C代码中一样用
在C代码中同样可以使用logcat来输出错误信息，只需引入一些特定的库与文件即可。
1. 在Android.mk文件增加：
LOCAL_LDLIBS+= -llog & & & &&意思就是引入log库, 库存放在platforms\android-*\arch-arm\usr\lib下。（-l表示引入,log为库名）
2. C代码中增加：
#include&&android/log.h&&&
#define&LOG_TAG&"System.out.c"&&
#define&LOGD(...)&__android_log_print(ANDROID_LOG_DEBUG,&LOG_TAG,&__VA_ARGS__)&&
#define&LOGI(...)&__android_log_print(ANDROID_LOG_INFO,&LOG_TAG,&__VA_ARGS__)&&
使用方法：
在C代码中直接像用printf一样来用LOGI()与LOGD()中任意一个。
代码如下：
JNIEXPORT&jint&JNICALL&Java_com_example_ndkjavadatatoc_NativeDataProvider_subInt(&&
&&&&&&&&JNIEnv&*env,&jclass&cla,&jint&x,&jint&y)&&
&&&&LOGI("x&is&%d",&x);&&
&&&&LOGI("y&is&%d",&y);&&
&&&&return&x&-&y;&&
三、中文乱码问题的解决办法
在NDK开发时，C代码中是不支持中文的。如果写中文的话，输出会是乱码。
解决办法：
1.&只要将C代码存储为UTF-8的编码, 就可以用中文字符。而GBK是不可以的。（这种方法对比较新的NDK版本有效）
2.&低版本（ 如ndk-r4）的NDK用的是iso-8859-1编码，需要进一步转换才能得到中文。
转换方法：NewString(getStringFromC().getBytes(&iso-8859-1&),&utf-8&)。（其中getStringFromC()为native方法，从C代码中取中文字符）
xn4545945收集整理。
转载请注明出处：&&
阅读(...) 评论() &