用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可能会出问题，具体啥问题，没说，很操蛋！