JNI 笔记
-
C/C++中写的程序可以避开JVM的内存开销过大的相知、处理高性能的计算、调用系统服务等，但是java调用jni空方法和java调用java方法相比，性能非常低的。所以一般只用来处理一些对运算有要求，或者需要对接口隐蔽的功能。
-
JNI 一般编写流程 其实就是为了避免一些错误 用javah生成jni函数名，还是值得推荐使用的。验证过，可以生成。比较使用的小技巧。
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
image.png
- apk crash 有log 可以定位，程序的anr 会在记录在／data/anr/traces.txt mtk aee log也有。
但是NDK Crash 定位就很难了 ，容易出错的地方有 内存地址访问错误 使用野指针 内存泄露 堆栈溢出 初始化错误 类型转换错误 数字除０（１１／０） 等等
使用ndk-stack 进行定位到行。
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
这几个问题 直接用ｏｋ机器的
/etc/udev/rules.d/ 目录下文件全部替换即可
jni读写文件 open 时候出错 fd 返回-1 文件节点权限是666
刚开始以为是权限问题，chmod 666后发现还是不行使用java 文件流进行读写 发现读是ok的
写时候出现异常 后面公司大神改了下驱动 将模块驱动中映射的open函数直接返回０
还是不行 。
最后自己怀疑是selinux 问题
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映射函数中出错了，比如返回类型没写对
