当前位置: 首页 > 知识库问答 >
问题:

如何阻止Gradle for Android在每个构建上构建*All*Library模块构建类型?[复制]

齐望
2023-03-14

我确信这以前被问过,但我只是没有找到正确的关键字来寻找答案,所以...

当我请求构建一种构建类型时,如何阻止Gradle for Android(在Android Studio内部或外部)构建库模块的所有构建类型?注意,如果我正在构建调试,我如何防止Gradle for Android也构建发布

对于那些有其他想法的人来说,背景故事是:

假设我有两个Android Studio项目,A和B。每个项目都有两个模块:一个Android库模块和一个依赖于该库的演示应用程序。我一共有四个模块:

  • AL:项目A的库
  • AD:项目A的演示应用程序
  • BL:项目B的库
  • BD:项目B的演示应用程序

只要A和B没有关系,生活就是美好的。

但是如果我想让BL依赖于AL呢?

对于发布,如果我希望这些库放在Maven风格的工件存储库中,我需要BL发布变体依赖于AL的已发布工件。这样,我的BLPOM具有正确的依赖信息。

对于debug,如果BL可以依赖于AL的工作副本,那将是理想的。虽然设置有点复杂,但我可以让它工作。

但是,如果我向AL添加一些东西,例如一个新的Java类,并且我尝试从BL使用它,我就无法构建。我的debug构建非常好AFAICT。然而,即使我现在真的真的不想做发布构建,Gradle for Android仍然坚持做发布构建:

$ gradle assembleDebug
:demo:preBuild UP-TO-DATE
:demo:preDebugBuild UP-TO-DATE
:demo:compileDebugNdk UP-TO-DATE
:demo:checkDebugManifest
:demo:preReleaseBuild UP-TO-DATE
:richedit:compileLint
:richedit:copyReleaseLint UP-TO-DATE
:richedit:mergeReleaseProguardFiles UP-TO-DATE
:richedit:preBuild UP-TO-DATE
:richedit:preReleaseBuild UP-TO-DATE
:richedit:checkReleaseManifest
:richedit:prepareReleaseDependencies
:richedit:compileReleaseAidl UP-TO-DATE
:richedit:compileReleaseRenderscript UP-TO-DATE
:richedit:generateReleaseBuildConfig UP-TO-DATE
:richedit:generateReleaseAssets UP-TO-DATE
:richedit:mergeReleaseAssets UP-TO-DATE
:richedit:generateReleaseResValues UP-TO-DATE
:richedit:generateReleaseResources UP-TO-DATE
:richedit:packageReleaseResources
:richedit:processReleaseManifest UP-TO-DATE
:richedit:processReleaseResources
:richedit:generateReleaseSources
:richedit:compileReleaseJava

(其中,richedit是BLdemo是BD在我上面的术语中)

我要求汇编debugbuild,但它仍然编译releasebuild。而releasebuild无法编译,因为我试图让BL使用AL中未发布的新内容。

我有相当的信心,尽管不是100%确定,如果Gradle for Android在我试图构建调试时只是轻率地忽略发布,我会处于良好状态。

当然,也有可能的解决办法:

>

  • 我可以放弃这些是独立图书馆的想法,把它们合并成一个图书馆。我可能会这么做。但我确实觉得我要做的应该是可能的。

    在发布AreleaseAL之前,我无法尝试使用AL更改,在这种情况下,BL可以依赖于发布的工件进行debugrelease。然而,这似乎会在a项目中造成大量补丁级的混乱,因为我的这个新a功能的主要消费者“用例”是B。仅仅因为我在a中有通过仪器测试的更改,并不意味着它们将是B所需要的,直到我能用a中的更改构建B,我才知道这一点。

    上述解决方法的一个变体可能是SNAPSHOT发行版,在这里,我将以某种方式启用SNAPSHOT发行版的debug检查,但不启用release或其他内容。然而,Maven、Gradle、Android和SNAPSHOT的组合似乎都没有得到充分的记录,我不知道这是否是我应该追求的东西。而且,与前面的项目一样,这仍然会导致不必要地构建发布;在我的情况下,构建会成功。

    我缺少的某个地方是否有一些适用于Android的Gradle设置说debug意味着debug


  • 共有2个答案

    计均
    2023-03-14

    这里有一个bug:https://code.google.com/p/android/issues/detail?id=52962

    评论#35是否即

    尝试在依赖项项目中设置此选项

    android {
        publishNonDefault true
        ...
    }
    

    这在使用它的项目中

    dependencies {
        releaseCompile project(path: ':theotherproject', configuration: 'release')
        debugCompile project(path: ':theotherproject', configuration: 'debug')
    }
    

    摘自这里:https://code.google.com/p/android/issues/detail?id=66805

    为你工作?似乎是大多数人认为有效的方法,我还没有亲自尝试过。

    艾意蕴
    2023-03-14

    https://stackoverflow.com/a/27278352/535762如果你解决了你的问题,我很想知道如何解决,因为它肯定还没有完全功能,只考虑调试就使用gradle构建。

    以下是关键部分:

    在左侧的“Build Variants”面板窗口中,您应该看到两个模块,以及它们旁边当前的“active”变体。例如

    app debug 
    custom_lib debug
    
    Build > Make Project
    

    正在构建项目中的每个模块

    https://code.google.com/p/android/issues/detail?id=52962需要建造

    使用下面的选项

     类似资料:
    • 模块标记 coolie-cli 的模块构建方式应该是比较特殊的一类,与 webpack 一样,都是另辟蹊径。 webpack:依赖模块放到数组里,数组索引值就是模块 ID。 coolie-cli:依赖模块全局标记 ID(三十六进制)。 coolie-cli 可以将长长的物理路径压缩成最短的字符,达到压缩率最大化,而不是将模块直接合并。 // module1.js define(function(r

    • 3.4.2 构建类型 默认情况下,Android plugin 会自动的设置工程,构建 release 和 debug 两个版本。 他们主要的差异主要在于是否可以在设备上调试应用以及APK如何签名。 debug 版本会被使用已知的名称/密码自动生成的密钥/证书签名。release 版本在构建过程中不会被签名,需要构建后再签名。 这些配置可以通过一个叫 BuildType 配置。默认情况下,已经创建

    • 公共模块 在介绍分块模块之前,来说些公共模块。 当一个项目逐渐壮大的时候,势必会出现一些公共模块。 如何分配和处理这些公共模块,需要全局考虑,是一个不小的利弊权衡。 如工程里共有 20 个入口模块, 5 个入口模块引用了同一个模块 a, 10 个入口模块引用了同一个模块 b, 15 个入口模块引用了同一个模块 c, 20 个入口模块引用了同一个模块 d。 如何分配这 4 个公共模块呢? 全部打包在

    • 问题内容: 我在Jenkins中建立了一个大型Maven多模块构建。它是为增量构建而设置的。 触发后,它将解析所有POM并弄清楚需要构建什么。 当前已将其设置为触发SCM更改。 我想进行此构建,以便可以执行以下操作: 仍然手动启动它。当我这样做时,它的增量构建行为将像今天一样起作用。 从Subversion提交钩子触发构建 。我想知道,如果我通过出色的指令来设置提交挂钩的麻烦,那将不会导致构建过程

    • 默认情况下,Android Plugin 会自动给项目构建 debug 和 release 版本。两个版本的区别在于能否在安全设备(非 dev)上调试,以及 APK 如何签名。debug 使用通过通用的 name/password 对生成的密钥证书进行签名(为了防止在构建过程中出现认证请求)。release 在构建过程中不进行签名,需要自行签名。 这些配置是通过 BuildType 对象来完成的。

    • 每个Gradle构建都包括三个基本的构建块:项目(projects)、任务(tasks)和属性(properties),每个构建至少包括一个项目,项目包括一个或者多个任务,项目和任务都有很多个属性来控制构建过程。 Gradle运用了领域驱动的设计理念(DDD)来给自己的领域构建软件建模,因此Gradle的项目和任务都在Gradle的API中有一个直接的class来表示,接下来我们来深入了解每一个组