最近的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的版本号。



更多相关文章

  1. Android(安卓)无cp命令 mv引起cross-device link
  2. android adb 命令不能用
  3. Android(安卓)Gradle 指定 Module 打包
  4. andriod 4.0以上版本不调用onConfigrationChange方法的解决办法
  5. 为Android应用程序读取/dev下设备而提权
  6. flutter的AndroidX版本适配
  7. android 与C/C++混合编程小例子讲解o
  8. MonoAndroid打包成apk实机无法运行
  9. Walle —— Android多渠道打包神器

随机推荐

  1. Android上实现MVP模式的途径
  2. Android(安卓)使用基于位置的服务(一)
  3. Android获取ROOT权限
  4. Android搜索建议(搜索联想)
  5. Android 7.0 移除设置中的某些项(辅助功能
  6. Android --- 图片的特效处理
  7. HTML5 开发 Mobile Web App
  8. 第15天android:使用sqlite
  9. Android判断应用是否存在 及 Android 关
  10. Android NDK Eclipse 集成