JNI 笔记

  • C/C++中写的程序可以避开JVM的内存开销过大的相知、处理高性能的计算、调用系统服务等,但是java调用jni空方法和java调用java方法相比,性能非常低的。所以一般只用来处理一些对运算有要求,或者需要对接口隐蔽的功能。

  • JNI 一般编写流程 其实就是为了避免一些错误 用javah生成jni函数名,还是值得推荐使用的。验证过,可以生成。比较使用的小技巧。

JNI 笔记_第1张图片
image.png

javac src/com/example/com/enjoy/test/test.java -d ./bin
javah -jni -classpath ./bin -d ./jni com.example.com.enjoy.test.test

JNI 笔记_第2张图片
image.png
  • apk crash 有log 可以定位,程序的anr 会在记录在/data/anr/traces.txt mtk aee log也有。
    但是NDK Crash 定位就很难了 ,容易出错的地方有 内存地址访问错误 使用野指针  内存泄露  堆栈溢出  初始化错误  类型转换错误 数字除0(11/0) 等等

使用ndk-stack 进行定位到行。


JNI 笔记_第3张图片
image.png
  • 因为 Java 默认使用 Unicode 编码,而 C/C++默认使用 UTF 编码,所以在本地代码中操作字符串的时候,必须使用合适的 JNI 函数把 jstring 转换成 C 风格的字符串。 JNI 支持字符串在 Unicode和 UTF-8 两种编码之间转换,GetStringUTFChars 可以把一个 jstring 指针(指向 JVM 内部的 Unicode字符序列)转换成一个 UTF-8 格式的 C 字符串。
    -调用完 GetStringUTFChars 之后不要忘记安全检查,因为 JVM 需要为新诞生的字符串分配内存空间,当内存空间不够分配的时候,会导致调用失败,失败后 GetStringUTFChars 会返回 NULL,并抛出一个 OutOfMemoryError 异常。JNI 的异常和 Java 中的异常处理流程是不一样的,Java 遇到异常如果没有捕获,程序会立即停止运行。而 JNI 遇到未决的异常不会改变程序的运行流程,也就是程序会继续往下走
  • 接口找不到
    在Java中调用JNI接口时,出现异常,察看日志,发现有如下错误:
    WARN/dalvikvm(422): No implementation found for native Lcom/whty/wcity/HelixPlayer;.setDllPath (Ljava/lang/String;)V
    检查了几遍代码,Cpp中确实定义了这个接口,而且仔细对照了Java的包名、类名,确实没有错误,那为什么会出现这种问题呢。后来突然想到,JNI接口 都是以C的方式定义的,现在使用C++实现,函数定义前是否需要加上extern "C"呢?为此定义了一个头文件,在CPP文件中include该头文件,头文件加上如下代码片断:

ifdef __cplusplus

extern "C" {

endif

endif

...

ifdef __cplusplus

}
再次尝试,调用成功!

  • MTK flash tool 刷机问题 ubuntu 下刷机 出现了异常。
    BROM ERROR : STATUS_ERR (-1073676287)
    STATUS_BROM_CMD_SEND_DA_FAIL
    chip mismatch MT0000

这几个问题  直接用ok机器的
/etc/udev/rules.d/  目录下文件全部替换即可

jni读写文件 open 时候出错 fd 返回-1 文件节点权限是666
刚开始以为是权限问题,chmod 666后发现还是不行使用java 文件流进行读写 发现读是ok的
写时候出现异常 后面公司大神改了下驱动  将模块驱动中映射的open函数直接返回0
还是不行 。
最后自己怀疑是selinux 问题

JNI 笔记_第4张图片
image.png

我的avc 异常:
[ 138.125449] <6>.(6)[283:logd.auditd]type=1400 audit(1496479197.368:93): avc: denied { read write } for pid=3144 comm="m.enjoy.testjni" name="ttctl" dev="tmpfs" ino=11250 scontext=u:r:system_app:s0 tcontext=u:object_r:ttctl_device:s0 tclass=chr_file permissive=0
修改: 
/alps/device/mediatek/common/sepolicy/system_app.te
+allow system_app ttctl_device:chr_file { read write ioctl open };
还没验证  下周再验证吧。编译实在是太慢了。
周一了周六遗留的问题解决了看log很重要,但是ioctl 返回值-1剩下就要看驱动了。

-在framework PowerManger中添加 接口,update-api 发现mmm但编译之后 一直报方法未重写,但实际已经重写,不明原因,直接根目录下全编一次就好了。

  • 报checkJni错误一般在jni映射函数中出错了,比如返回类型没写对

你可能感兴趣的:(JNI 笔记)