【发布时间】:2015-12-21 14:18:12
【问题描述】:
模块的build.gradle 文件是否有一种相当简单的方法来指示应排除依赖项中的某些文件?我对从 AAR 中排除某些资源特别感兴趣。
LeakCanary 是一个有趣的库,用于帮助追踪内存泄漏。但是,它具有 21 或更高的 compileSdkVersion 的未记录要求。虽然大多数项目不应该有这个问题,但图书馆在没有充分理由的情况下要求某个compileSdkVersion 是不合适的。作为一般政策的一部分,开发团队可能冻结了他们的compileSdkVersion,只在他们的应用程序或其他内容的主要版本更新中更改这些类型的设置。
在这种情况下,至少对于 v1.3.1 的 LeakCanary,需要 compileSdkVersion 的唯一原因是 AFAICT,因为 AAR 有一个 res/values-v21/ 目录,其中包含一个从 Theme.Material 继承的主题定义。此主题由诊断活动使用。最终用户永远不会看到该活动,只有 debug 构建中的开发人员才能看到。坦率地说,那个活动看起来像什么,就主题而言,并不重要。强制compileSdkVersion 21 只是为了让诊断活动有一个特定的主题,恕我直言,愚蠢。
如果作为compile 指令的一部分,我们可以说“嘿,请跳过此AAR 中的res/values-v21/,好吗?”。由于-v21 主题只是提供了在别处定义的主题的替代定义,因此删除-v21 主题不会在运行时破坏构建或破坏事物,而只会给我们一个Holo-主题诊断活动。
我看不到 this answer 如何处理依赖项。我也不确定if it is complete, and it certainly does not appear to be supported。它也并不真正符合“简单”的条件——我不希望有人尝试将其放入 build.gradle 文件中,只是为了阻止来自 LeakCanary 等诊断库的单个文件。
那么,有没有比这更简单的东西可以与当前版本的 Android Plugin for Gradle 一起使用?
【问题讨论】:
-
我认为,LeakCanary (github.com/square/leakcanary) 的解决方法是分叉它并使用适当的
compileSdkVersion编译您自己的版本。我不确定它是否可以算作问题的答案。 -
@KonstantinLoginov:LeakCanary 似乎有相当多的相互连接的移动部件,这就是为什么我怀疑分叉会这么简单。我做了足够多的探索以确定唯一的 Android 5.0+ 功能是
Theme.Material,这就是导致我提出这个问题的原因。虽然我在 LeakCanary 的背景下提出了这个问题,但这个问题超越了那个图书馆。 -
如果 google 当前的 gradle 插件源是公开的就好了。 DSL 源代码 [1] 的标签远远落后于发布标签 [2]。 [1]android.googlesource.com/platform/tools/gradle/+refs [2]jcenter.bintray.com/com/android/tools/build/gradle
标签: android android-gradle-plugin