Android 主Module引用依赖Module,却无法使用里面的依赖库

如果模块化开发中遇到

多模块的AndroidManifest.xml没有合并
or
多模块的资源文件没有合并
or
模块A include了模块B，而无法使用模块B内依赖的其他aar包中的类的时候
or
提示Support包版本不一致
这篇文章可能就是你要的解决方案~

举个栗子：

比如我们现在有一个App模块设计为：
主工程： app
模块: ui , framework

引入模块的方式：在settings.gradle中，指定正确的模块路径

1include ':app', ':framework', ':ui'
2project(':framework').projectDir = new File('../framework')
3project(':ui').projectDir = new File('../ui')

如果现在framework引入了一些依赖库，假设如下：

1// Retrofit 网络框架依赖
2implementation "com.squareup.retrofit2:retrofit:2.5.0"
3
4// Gson 依赖
5implementation 'com.google.code.gson:gson:2.8.5'
6
7// ARouter解耦框架
8implementation 'com.alibaba:arouter-api:1.4.1'
9annotationProcessor 'com.alibaba:arouter-compiler:1.2.2'

如果这样写的话，主工程app中将无法调用到这些依赖库中的类。
因为implementation声明的依赖只能在本module模块内使用,跨module使用就要使用api声明（其实就是曾经的compile，但是如果设置成compile，AS又要给你叫叫叫）！！改成如下即可

1// Retrofit 网络框架依赖
2api "com.squareup.retrofit2:retrofit:2.5.0"
3
4// Gson 依赖
5api 'com.google.code.gson:gson:2.8.5'
6
7// ARouter解耦框架
8api 'com.alibaba:arouter-api:1.4.1'
9annotationProcessor 'com.alibaba:arouter-compiler:1.2.2'

同理，这是模块里引用别的aar，这样配置完了，那么紧接着需要在依赖framework的app模块中，
在build.gradle的依赖处加入对应的引入哈。

api project(":framework")

当然如果全部做完，由于很多aar里使用了不一样的support版本，一定会提示版本不兼容了（其他aar不兼容的解决方案一样哈），在主工程app的build.gradle中指定：

1android {
2    .....
3    .....
4//指定jdk版本
5    compileOptions {
6        sourceCompatibility JavaVersion.VERSION_1_8
7        targetCompatibility JavaVersion.VERSION_1_8
8    }
9
10    // 如果提示多个重复文件，加这属性
11    packagingOptions {
12        exclude 'META-INF/proguard/androidx-annotations.pro'
13    }
14}
15
16// 用于指定所有aar引用同样版本的support包
17configurations.all {
18    resolutionStrategy.eachDependency { DependencyResolveDetails details ->
19        def requested = details.requested
20        if (requested.group == 'com.android.support') {
21            if (!requested.name.startsWith("multidex")) {
22                details.useVersion '28.0.0'
23            }
24        }
25    }
26}

————————————————
版权声明：本文为CSDN博主「胖虎」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ljphhj/article/details/86262031