maven（android-maven-plugin3.8.0）打包apk无法启动，apklib依赖包的资源索引出错（R文件与主模块冲突）问题解析

近期在用maven，遇到了一个问题，用maven打出的apk有问题无法启动，但是用idea打包的就是正常的。

日志中显示的问题是，一个apklib形式的依赖包中的一个资源出现了问题。反编译对比maven包和idea包，找到了问题所在。

假设： 主模块包名为com.android.main

apklib依赖包包名为com.android.apklib

出问题的资源(layout)名为MyView

问题： apk打包后apklib依赖包的资源文件会与主模块的资源整合到一起，依赖包引用资源实际上是在主模块的R文件中查找对应资源。

1）maven包中：
在com.android.main下的R文件中MyView的值为0x7f050001；而在com.android.apklib下的R文件中MyView的值为0x7f070001，而且程序内使用该资源时的索引也是0x7f070001。这样程序运行到这段代码时，会去主模块的R文件中找0x7f070001，然而主模块中0x7f070001对应的资源并不是一个layout，所以就会出错。

2）idea包中：俩个R文件中MyView的值相同，所以能够正确的找到资源，程序不会出错。

这样就知道了问题，但是问题是如何出现的？

经过对maven打印日志查看，整理了一个打包的过程如下：

1）将所有依赖包拷贝到项目 /target/unpacked-libs 下，整合资源文件，然后生成主模块和各依赖包的R.java等文件

2）编译class文件，包括刚才生成的对应包的R文件。注意：编译com.android.apklib下的java文件时，代码中对应资源的索引与（1）生成的com.android.apklib包下的R文件一致

3）生成dex

4）生成apk

（maven打包可以用"mvn clean package"即可。不过也可以像上面那样细分成四步"mvn clean android:generate-sources compile android:dex
android:apk"）

这样我们就注意到，虽然运行时依赖包会在主模块R文件中查找资源，但是编译时还是会根据自己包下的R文件来编译。

用maven只处理资源（mvn clean android:generate-sources），以便查看生成的R.java文件，发现问题产生的原因：

生成的R.java文件，主模块与依赖包是有冲突的，同一个资源对应不同的索引。这样编译的时候依赖包代码中的资源索引就是有问题的，就会导致问题的出现。那么说明maven在生成R.java文件时是有问题的。

继续查看maven打印日志，找到了生成R,java文件对应的日志部分，是执行了aapt的命令。如下：

aapt.exe package --non-constant-id -m -J D:\项目目录\target\generated-sources\r --custom-package 主模块包名 -M D:\项目目录\target\unpacked-libs\依赖包名\AndroidManifest.xml -S D:\项目目录\res -S D:\项目目录\target\unpacked-libs\依赖包名\res --auto-add-overlay -A D:\项目目录\target\unpacked-libs\依赖包名\combined-assets -I D:\AndroidSDK\sdk\platforms\android-16\android.jar;

多加了主模块的res进去，这样其实生成的依赖包R文件与主模块的是一摸一样的，里面包含了所有资源，并不仅仅是依赖包的资源。这样再编译就不会有冲突的现象。

但是这仅仅是在命令层面解决问题，maven打包使用的是android-maven-plugin（com.jayway.maven.plugins.android.generation2），上面的命令都是由这个插件来执行的。不过还好这个插件是开源的，在github上可以找到。在github上找到这个开源项目，找到对应部分的代码后发现构建的命令是正确的，原来已经有高手在5月中旬解决这个问题了。。。

原来是我的插件版本落后了，去中心仓库查看发现android-maven-plugin最新版本是3.9.0-rc.3，这个版本已经解决该bug了。更新一下打包测试，一切正常。

虽然最后只是更新一下版本就解决了，但是也学到了不少东西，熟悉了打包流程，另外有兴趣的话可以看看github上对应部分的代码，