[2014-08-23 13:02:57 - RankListDemo] Proguard returned with error code 1. See console
[2014-08-23 13:02:57 - RankListDemo] java.io.IOException: Can't read [C:\Users\Will\Desktop\storesdk_proguard\store_sdk\LetvStoreSDK\libs\letvstoresdk.jar] (Can't process class [com/letv/tvos/appstore/ranklistsdk/widget/Test.class] (Unknown verification type [11] in stack map frame))
[2014-08-23 13:02:57 - RankListDemo] at proguard.InputReader.readInput(InputReader.java:230)
[2014-08-23 13:02:57 - RankListDemo] at proguard.InputReader.readInput(InputReader.java:200)
[2014-08-23 13:02:57 - RankListDemo] at proguard.InputReader.readInput(InputReader.java:178)
[2014-08-23 13:02:57 - RankListDemo] at proguard.InputReader.execute(InputReader.java:78)
[2014-08-23 13:02:57 - RankListDemo] at proguard.ProGuard.readInput(ProGuard.java:196)
[2014-08-23 13:02:57 - RankListDemo] at proguard.ProGuard.execute(ProGuard.java:78)
[2014-08-23 13:02:57 - RankListDemo] at proguard.ProGuard.main(ProGuard.java:492)
[2014-08-23 13:02:57 - RankListDemo] Caused by: java.io.IOException: Can't process class [com/letv/tvos/appstore/ranklistsdk/widget/Test.class] (Unknown verification type [11] in stack map frame)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.ClassReader.read(ClassReader.java:112)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.FilteredDataEntryReader.read(FilteredDataEntryReader.java:87)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.JarReader.read(JarReader.java:65)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.DirectoryPump.readFiles(DirectoryPump.java:65)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.DirectoryPump.pumpDataEntries(DirectoryPump.java:53)
[2014-08-23 13:02:57 - RankListDemo] at proguard.InputReader.readInput(InputReader.java:226)
[2014-08-23 13:02:57 - RankListDemo] ... 6 more
[2014-08-23 13:02:57 - RankListDemo] Caused by: java.lang.RuntimeException: Unknown verification type [11] in stack map frame
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.createVerificationType(ProgramClassReader.java:890)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.visitFullFrame(ProgramClassReader.java:659)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.attribute.preverification.FullFrame.accept(FullFrame.java:114)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.visitStackMapTableAttribute(ProgramClassReader.java:452)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.attribute.preverification.StackMapTableAttribute.accept(StackMapTableAttribute.java:71)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.visitCodeAttribute(ProgramClassReader.java:422)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.attribute.CodeAttribute.accept(CodeAttribute.java:101)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.visitProgramMethod(ProgramClassReader.java:200)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.io.ProgramClassReader.visitProgramClass(ProgramClassReader.java:142)
[2014-08-23 13:02:57 - RankListDemo] at proguard.classfile.ProgramClass.accept(ProgramClass.java:346)
[2014-08-23 13:02:57 - RankListDemo] at proguard.io.ClassReader.read(ClassReader.java:91)
[2014-08-23 13:02:57 - RankListDemo] ... 11 more
前几天做一个推广SDK 遇到的一个问题，我们的SDK是以Library的形式提供给三方应用的，而代码又不好不进行混淆处理就发给三方应用，所以我们的处理是
把源码也就是src目录下的所有文件导出并做成一个jar包，然后对这个jar包进行混淆，然后再把这个混淆后的jar包放在library的libs目录下面。问题的出现时在
一个三方用户接入后，需要对自己的代码进行混淆，生成一个签名apk的时候。报了类似以上的一个错误，看错误日志，发现Test.class加载不了，也就是说Test.class 这个类
有问题，当我不对我的jar包进行混淆是，就不会报上面的错误。但我明显在对我的jar包混淆的时候keep了这个类，然后我也让接入的哥们，在他们的混淆脚本中以这样的形式 -libraryjars 引入了我们的jar包，并且keep了个jar包下所有的类。 然后我就百度 谷歌 *各种 搜索，搜索到今天我也没有找到解决问题的方法。网络上这个问题抛出来的也很久了，也有很多类似的问题，但问题就是没有一个人真正意思的找到了解决这个问题的办法，基本上都是-libraryjars keep dontwarn 之类的解决办法。然后当时那边也催的紧，当时报错的是一个自定义控件，代码量很多，就放弃了用哪个自定义控件，然后就选择了另外的一种实现方案，后面三方应用接入的时候混淆也通过了。
然后最近这几天也一直被这个问题困扰，然后趁着周末，思来想去还是想一探究竟，那个类到底怎么了。然后就单独把那个类拿出来，做成jar包，然后混淆，然后再以libray的形式提供，然后主工程代码混淆导出签名apk报的是同样的错，然后以大面积注释 掉，然后一块块在放开以这种最笨的方法来找到问题出在哪里。在这样弄了两个多小时后终于找到，我这个工程中导致混淆出错的元凶了。然后写了个测试工程验证了一下之前的错误，发现确实是有问题 代码如下：test函数就是元凶，那个handled作为返回值
在if{}else{}块就等于做了无用功，因为真正能决定handled的是test1() ,但是奇怪的是test1的返回值如果是直接返回true或者false的话，也不会出问题。问题就出在test1的返回值也是得根据传入的i来决定的，
int i;
private boolean test(){
boolean handled=false;
if(i>0){
handled=false;
}else{
handled=true;
}
handled=test1(i);
return handled;
}
private boolean test1(int i){
return i<0?true:false;
}
如果有这样的代码的话，就会出现上述问题，即使你代码混淆的时候keep了这个类，还是会报上面的错误。
但是我刚才又做了一个测试把test1改成如下 test调用的时候test1(handled)
private boolean test1(boolean i){
return i;
}
然而又没有出问题，如果传test(true)的话，还是错问题，所以我觉得应该是不能让test
的if(i>0){
handled=false;
}else{
handled=true;
}
这段代码做无用功，返回值过多过少还是得依赖于if else 块产生的handled ，说实话我也整懵了，编译器的那些事
不是很了解，有谁知道原因的，帮忙在下面留言解答解答。