Direct local .aar file dependencies are not supported when building an aar解决方案

运行环境

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: 'aar', ext: 'aar')