转载请注明来源：http://blog.csdn.net/goldenfish1919/article/details/33729679
用eclispe打包的时候报错：
[2014-06-23 13:44:35 - Dex Loader] Unable to execute dex: Cannot merge new index 66195 into a non-jumbo instruction!
[2014-06-23 13:44:35 - tao_apad_2.0] Conversion to Dalvik format failed: Unable to execute dex: Cannot merge new index 66195 into a non-jumbo instruction!
參考：http://www.cnblogs.com/frydsh/archive/2013/02/20/2918969.html
最新的ADT和SDK Tool在将jar转化成dex的时候，可能会合并类的代码，这将导致巨大的类；类中的每个方法都分配有一个id，字节码中以id标识和调用方法；早期的Dalvik VM内部使用short类型变量来标识方法的id，最大值限制在65535；综合上述因素，代码在安装的时候，不能通过验证，所以安装失败。
最新的Android可能已经攻克了这个问题，可是更早的Android版本号可能仍然存在此问题。
因此，因为大量遗留机器的存在，这个问题是不能彻底解决的，一个暂时的解决方式是：删掉没有实际使用的代码，或者使用ProGuard处理代码（能够减小代码体积）。
一个不幸的推论是：随着一个软件功能的添加，代码的膨胀，APK包终将超出能够处理的范围，或许就是8M（指APK包里面的classes.dex）.
參考：https://code.google.com/p/android/issues/detail?id=40409
While the Dalvik team works on a fix, I'm going to allow disabling of the new dex merger features. Builds will be slower (actually back like they were before) but they'll work at least. We were looking at a 21.0.1 release so I'm going to do this now and make sure this gets in.
然后，改动project.properties，加入一行：dex.disable.merger=true，居然能够了。
文中还有，也是猜的，没有依据：
@18: i think you're confused. there are probably multiple bugs. as i explained in comment 7, the original error is caused by out-of-order annotations. the number of annotations isn't relevant to that bug;all that matters is whether the method indexes they refer to happen to come out in order or not when the merge basically appends them without sorting. (you are though correct that the annotations problem has nothing to do with jumbo mode --- it's the merge step that's the problem.)
looking at libdex, the reason for your new error is a bit more obscure. it seems to mean that there are references to more than one class in a class_data_item. my assumption is that that means thatone of the fields or methods referred to in the class_data_item doesn't belong to the class we're supposedly defining.i'm afraid i don't know enough about the merge process to know how/why that might happen.
我们这个问题的解决办法大概是：
Ufnortunately method call is encoded with a method_id being a short int (so only 65535 different methods), unlike const string access.
So, to summarize, even though the .dex specs allows more than 65535 classes and methods, the vm doesn't support large number of classes/methods, there wasn't any explicit error message.
一个vm最多仅仅能有65536个方法！
dex.force.jumbo是干嘛的？
To my knowledge, dex.force.jumbo activates the const-string-jumbo opcode which allows to refer to static strings when you have more than 65k strings in your dex file.
假设超过了65k个字符串，启用dex.force.jumbo这个參数才干够引用到全部的字符串。
usually, dx will use the shortest instruction it can. this can make merging impossible if an instruction would need to be widened to fit more bits of string index (or whatever). dex.force.jumbo says "always use the wide form, even if you don't need to", to improve the chances of being able to merge later.
dex.disable.merger的官方解释參考：http://blog.toolib.net/tools/sdk/eclipse-adt.html：
Added a flag to disable dex merging to deal with cases where merging could generate a broken dex file. If this happens to your project, add the following setting to your project.properties file: dex.disable.merger=true。This setting causes the build system to revert to the older, slower dex processing that does not pre-dex libraries.
也就是说merge可能会出问题，详细啥问题，没说，非常操蛋！
昨天还试验出了一种方法，在project.properties文件里加入以下两个选项也是能够的：
manifestmerger.enabled=true
dex.force.jumbo=true
Automatic merging of library project manifest files into the including project's manifest. Enable with the manifestmerger.enabled property.
If you want to merge android library project manifest and your current project manifest, you can add manifestmerger.enabled=true in your project.properties file where you referred your library project. But, you should be confirmed some point like ADT version, Also Minimum and target SDK should be same as library project.
因此，这样的方式是有局限性的，Minimum和target SDK须要同样才干够。