運行環(huán)境

gradle 版本 8.0
as 版本 2022.3

問題描述:

app工程依賴module工程，module工程依賴libs下的aar，引入方式為implementation fileTree(dir: 'libs', include: ['.jar','.aar'])
這里打包分為三個概念

1. 直接以debug模式點擊as的綠色三角按鈕運行apk
2. module 工程 assemble 打aar
3. app 工程 assemble 打release apk

其中只有debug模式運行可以成功，另外兩種打包均失敗，報Direct local .aar file dependencies are not supported when building an AAR錯誤，也就是module工程不支持直接引入本地aar， (但是把aar放在app工程的lib下卻可以打包
fuck!)。

解決方案

網(wǎng)上的方案總結(jié)如下

1. 將module的aar引入方式改為compileOnly, 復制一份到app的lib下
   此方案我直接放棄，因為我的項目架構(gòu)可能有module1，module2 ... module 20...，一共包含N個aar或jar，每次打包app工程會依賴其中一個或者多個module，這樣做不僅每個aar有兩份，還會讓app工程的依賴管理和切換非常麻煩。
2. 為aar新建module，新建build.gradle
   添加如下配置
   configurations.maybeCreate("default")
   artifacts.add("default", file('xxx.aar'))
   此方案我也放棄，因為項目module太多，aar太多，不想增加這么多build.gradle文件，不想明明一個module能解決的事要搞成2個或以上module。
3. 自建maven
   在項目本地或者公司服務器建個maven倉庫，以在線依賴的形式引入aar。
   此方案是可以解決問題的，麻煩的是每個aar要設置命名規(guī)則發(fā)布到maven以及舊aar的管理。
4. 設置flatDir
   repositories {
   flatDir { dirs 'libs' ,"module1/libs","module2/libs"}
   }
   implementation(name: 'aar包名', ext: 'aar')
   此方案是我想要的方案，首先各個module的libs是完全隔離的，不會產(chǎn)生沖突。而且更新module的依賴方便，假設moduleA的1.0版本依賴了10個aar，更新為2.0時需要依賴8個aar，那么只需要無腦刪除這10個aar，然后把新的8個aar 丟進moduleA的libs即可，比起maven的發(fā)布和舊aar管理是容易許多。

方案4雖然是我想要的 但是在高版本gradle中寫法已經(jīng)變化了，自己鼓搗了一會，發(fā)現(xiàn)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寫法也差不多。這里我做了一個優(yōu)化，不用聲明各個子module的libs路徑，直接遍歷rootProject的子module的libs添加進去， 但遍歷的時機需要在settings的include全部執(zhí)行完畢。

不過module工程還是不能直接以fileTree形式依賴所有aar，要使用單個依賴的方式。
implementation(name: 'aar1', ext: 'aar')
implementation(name: 'aar2', ext: 'aar')

1.jpg