运行环境
gradle 版本 8.0
as 版本 2022.3
问题描述:
app工程依赖module工程，module工程依赖libs下的aar，引入方式为implementation fileTree(dir: 'libs', include: ['.jar','.aar'])
这里打包分为三个概念
- 直接以debug模式点击as的绿色三角按钮运行apk
- module 工程 assemble 打aar
- app 工程 assemble 打release apk
其中只有debug模式运行可以成功，另外两种打包均失败，报Direct local .aar file dependencies are not supported when building an AAR错误，也就是module工程不支持直接引入本地aar， (但是把aar放在app工程的lib下却可以打包
fuck!)。
解决方案
网上的方案总结如下
- 将module的aar引入方式改为compileOnly, 复制一份到app的lib下
此方案我直接放弃，因为我的项目架构可能有module1，module2 ... module 20...，一共包含N个aar或jar，每次打包app工程会依赖其中一个或者多个module，这样做不仅每个aar有两份，还会让app工程的依赖管理和切换非常麻烦。 - 为aar新建module，新建build.gradle
添加如下配置
configurations.maybeCreate("default")
artifacts.add("default", file('xxx.aar'))
此方案我也放弃，因为项目module太多，aar太多，不想增加这么多build.gradle文件，不想明明一个module能解决的事要搞成2个或以上module。 - 自建maven
在项目本地或者公司服务器建个maven仓库，以在线依赖的形式引入aar。
此方案是可以解决问题的，麻烦的是每个aar要设置命名规则发布到maven以及旧aar的管理。 - 设置flatDir
repositories {
flatDir { dirs 'libs' ,"module1/libs","module2/libs"}
}
implementation(name: 'aar包名', ext: 'aar')
此方案是我想要的方案，首先各个module的libs是完全隔离的，不会产生冲突。而且更新module的依赖方便，假设moduleA的1.0版本依赖了10个aar，更新为2.0时需要依赖8个aar，那么只需要无脑删除这10个aar，然后把新的8个aar 丢进moduleA的libs即可，比起maven的发布和旧aar管理是容易许多。
方案4虽然是我想要的 但是在高版本gradle中写法已经变化了，自己鼓捣了一会，发现flatDir 需要在settings.gradle中设置。
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
maven { setUrl("https://jitpack.io") }
google()
mavenCentral()
gradle.settingsEvaluated {
flatDir {
dirs(rootProject.children.map { it.name + "/libs" }.toTypedArray())
}
}
}
}
以上为kts的gradle的文件，groovy写法也差不多。这里我做了一个优化，不用声明各个子module的libs路径，直接遍历rootProject的子module的libs添加进去， 但遍历的时机需要在settings的include全部执行完毕。
不过module工程还是不能直接以fileTree形式依赖所有aar，要使用单个依赖的方式。
implementation(name: 'aar1', ext: 'aar')
implementation(name: 'aar2', ext: 'aar')
1.jpg
