We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
你好,关于 Lib Module 的 sourceSets ,我觉得通过 Gradle 的 productFlavors 来完成比较好点。
sourceSets
productFlavors
publishNonDefault true flavorDimensions "mode" productFlavors { app { dimension "mode" } lib { dimension "mode" } }
在 App Module 中通过指定 productFlavors 来依赖
if (!isDebug.toBoolean()) { compile project(path: ':business1', configuration: 'libDebug') compile project(path: ':business2', configuration: 'libDebug') } else { compile project(':basicbusiness') }
这样做有个好处是,可以在不同 productFlavors 对应的目录下放置属于各自的资源或者 Java 文件,让 Gradle 自动去合并。一来不用完全拷贝两份 AndroidManifest.xml ,只需要改下特定的部分,放在 src/app/ 目录下的 AndroidManifest.xml,通用部分放在 main 目录下的 AndroidManifest.xml。第二,不会将多余的资源文件打包进去,比如有些文件只需要在 Module 作为 Application 的时候需要的。
src/app/
main
我最近也在做这个模块化,组件化的事情,希望能一起探讨下。
The text was updated successfully, but these errors were encountered:
看起来是个很不错的方式,不过我验证下来 resourcePrefix 和 productFlavors 好像会产生冲突,出现资源文件无法定位的问题。期待进一步沟通~
Sorry, something went wrong.
我这边没出现这个问题,你能描述下问题吗?
No branches or pull requests
你好,关于 Lib Module 的
sourceSets
,我觉得通过 Gradle 的productFlavors
来完成比较好点。在 App Module 中通过指定
productFlavors
来依赖这样做有个好处是,可以在不同
productFlavors
对应的目录下放置属于各自的资源或者 Java 文件,让 Gradle 自动去合并。一来不用完全拷贝两份 AndroidManifest.xml ,只需要改下特定的部分,放在src/app/
目录下的 AndroidManifest.xml,通用部分放在main
目录下的 AndroidManifest.xml。第二,不会将多余的资源文件打包进去,比如有些文件只需要在 Module 作为 Application 的时候需要的。我最近也在做这个模块化,组件化的事情,希望能一起探讨下。
The text was updated successfully, but these errors were encountered: