最近的cocos-Lua项目，打包android apk的时候老是失败，主要是dex过程中报错以下错误：

-dex:
      [dex] input: D:\projecty\projects\MonsterRun\trunk\MonsterRun\frameworks\runtime-src\proj.android\bin\classes
      [dex] input: D:\projecty\projects\MonsterRun\trunk\MonsterRun\frameworks\cocos2d-x\cocos\platform\android\java\bin\classes.jar
      [dex] input: D:\projecty\projects\MonsterRun\trunk\MonsterRun\frameworks\runtime-src\proj.android\libs\SDK__fat.jar
      [dex] Pre-Dexing D:\projecty\projects\MonsterRun\trunk\MonsterRun\frameworks\cocos2d-x\cocos\platform\android\java\bin\classes.jar -> classes-94a403c7f61e5d2c23fce32f778410b5.jar
      [dex] Pre-Dexing D:\projecty\projects\MonsterRun\trunk\MonsterRun\frameworks\runtime-src\proj.android\libs\SDK__fat.jar -> SDK__fat-93bf3f9d975b6198d3f96d98441a23d2.jar
       [dx] 
       [dx] trouble processing:
       [dx] bad class file magic (cafebabe) or version (0033.0000)
       [dx] ...while parsing com/squareup/okhttp/Address.class
       [dx] ...while processing com/squareup/okhttp/Address.class
       [dx] 
       [dx] trouble processing:
       [dx] bad class file magic (cafebabe) or version (0033.0000)
       [dx] ...while parsing com/squareup/okhttp/Authenticator.class
       [dx] ...while processing com/squareup/okhttp/Authenticator.class
       [dx] 
       [dx] trouble processing:
       [dx] bad class file magic (cafebabe) or version (0033.0000)
       [dx] ...while parsing com/squareup/okhttp/Cache$1.class
       [dx] ...while processing com/squareup/okhttp/Cache$1.class

我看到，全是okhttp的报错，那么就需要翻看okhttp首页看看，它对jdk是否有所要求。

OkHttp supports Android 2.3 and above. For Java,the minimum requirement is 1.7.

所以我认为一定是因为java jdk的版本导致的，因为我在导出sdk的jar包的时候，有指定了jdk的版本，而cocosIde的项目也有设置jdk的选项。

我在打包sdkjar包中的混淆中指定了javac编译java文件的版本：

而在cocosIDE中也有设置jdk的环境变量：

由此我就猜想，可能与java的jdk的版本有关。因为java的jdk版本对工程的使用往往都出现很多坑，例如在eclipse中用jdk7打的jar包，可能无法被在jdk6环境下的eclipse加载。因此，我把打jar包的命令升至1.7，重新打jar包。但是，问题依然存在。

jdk一致之后，问题仍然存在。问题一定是与dx命令有关的东西了。什么与dx命令有关呢？dx命令在哪里？所以我们有必要了解cocosIDE对android的apk的打包过程何时使用了dx，怎么使用dx。

1.回顾整个打包过程。

在Cocos-IDE的系统输出窗口可以到整个apk的打包过程，首先先是ndk-build打包so文件，然后就是Lua文件编译，再之后就进行android打包。

从中，我们看到在Lua文件编译完成之后，进行了android apk的打包。

其中打包命令在build.xml中。为了确定打包命令在其中，我们在cmd命令行中cd到该目录下，运行ant. 结果cmd中的输出内容和系统输出窗口的内容一致，证明该build文件是我们android打包apk的命令文件。

2.打开文件，找到打包的命令

打开对应的android工程下的build.xml，看到以下一句命令:

主要的打包命令是依赖了androidsdk文件夹下面的tools里面的ant命令。

3. 接着打开tools/ant/build.xml

终于，找到了cocos-IDE中打包android——apk包时使用的打包命令了，其使用的是androidsdk中带的build命令。

那么dx命令在哪里呢？

4. 为了找到dx命令的调用，我回到IDE打包的系统输出窗口，我们找到这样的输出（这个输出是后来成功打包的输出）：

我看见了输出了build Tools的版本号，心里想，莫非是因为androidSDK的build-tools版本太低了吗？因为据我运用编译与反编译的多年经验来看，android的build-tools的版本对android工程的编译有着很大的影响。所以我赶紧打开SDK MAnager更新了build-tools.(以下图片都是后面已经更新好的截图)

5.更新完build-tools之后，再在cocos-IDE中打包apk,发现问题依然存在。

所以再次翻看ant/build.xml命令，看dx工具究竟在哪里被运用了。

回到文件头部的位置，我们可以看到，ant命令中主要引入那些文件夹里面的工具库：

看到没有，build命令里面，压根就没有调用build-tools文件夹的文件，它用了tools下面的dx命令和platform-tools下的adb。所以就再去更新tools吧。

6.把tools更新到25.0.0版本之后，再进行打包。终于可以了。

综上所述，如果dx出错，最好就更换一个合适的版本，因为dx的版本也会随着android-tools的版本作出更新，具体你们可以把dx文件命令配置到path中，通过cmd命令：

dx --version ， 看到dx的版本号。