mao
mao
jar的有点问题，主要是.class跟.dex转换带来的差异。先对jar混淆转成dex文件，然后把dex转换成jar当成lib给人调用可能问题少些。
windows下可能文件系统问题，还有你再打包用的软件问题搞不明白可以参照build-src.sh里面所用的命令。修改so名称，java源码也要相应改变，具体可以看注释。
and cannot be nativeized. If you must do this, you can extract some instructions to generate a method similar to myinit0, and then convert myinit0 to native, and the method...
这个odex问题没处理过，我看了下分析很有用。enum导致脏问题之前遇到类似的就是方法返回boolean,使用jvalue.z接收结果，而if-get这类指令使用int,然后判断总会随机出错。晚上我试试生成native方法时加上强制类型转换。
vmInterpret返回的是jvalue, 然后会依据native函数返回类型生成不同的返回代码（比如 return value.z,return value.i）。我写了两个测试函数，一个直接reutrn value.i，一个reutrn (jint) value.i，然后反编译so对比一下汇编代码发现没区别。按理有返回值的native函数不会调用vmInterpret后直接返回，而是会处理返回值。
代码生成模板是 ``` jvalue value = vmInterpret(env, &code, &dvmResolver); //清理内存等相关 ... return value.i; ``` 我测试使用jvalue.i这类返回可以正确处理数据类型问题，我看你文章中会反编译出现调用vmInterpret后直接不处理返回值不知道是不是和编译器优化有关。 好，我去下载样本试试。
> > 代码生成模板是 > > ``` > > jvalue value = vmInterpret(env, &code, &dvmResolver); > > //清理内存等相关 > > ... > > return value.i; > > ``` > > >...
``` jvalue value = vmInterpret(...); ... return value.i; ``` 上面代码我debug编译我看汇编还能正确处理，release就会被优化掉，我专门加上return (jint) value.i;也会被优化，所以给jvalue value;加上volatile保证不会被优化。vmInterpret内部不太好修改，不然把所有数据按jlong处理应该也没问题。
那个问题我看过，我查过谷歌的issue，应该compose的问题。它错误实现某些接口，但可能因为一般情况没加载那些错误类不报错，但依然有概率触发，而对compose加固可能导致会强行加载那些类文件而报错。 绕过那些错误类就行，项目是处理字节码的，除了后面新加的几个新字节码不支持不能转化那些方法，其他的问题应该不大。还有不要去加固开源库，纯粹给逆向送子弹，别人只需要拿开源库的字节码跟你随机化后的进行对比就能搞清楚你opcode映射，完全绕过分析vm。
具体原因没实际测试，但报错看着是compose错误实现某些接口导致不兼容，这个哪怕不额外处理dex，compose也有几率报错。