compileOnly 依赖 的作用与 已废弃的 provided 依赖 类似 , 都是 将依赖库添加到编译路径中 ; 在 根目录的 build.gradle 顶层构建脚本 中的 buildScript 脚本块 中 , 使用了 classpath 依赖 , 该类型的依赖只应用在 buildScript 脚本块 , 其作用也是 将依赖库添加到编译路径中 , 与 compileOnly 依赖 和 provi...
implementation:作用是编译同时打包,且当前mudule打包的aar或jar, 不能被引用当前module 的模块引用。 api:作用是编译同时打包,且当前mudule打包的aar或jar, 能被引用当前module 的模块引用。 compileOnly:作用是只编译不打包。 比如项目中要引用aarA,如果项目中 其他模块已经引用打包过了aarA,则需要使用compileOnly And...
compileOnly:只在编译时有效,不会参与打包。可以在自己的module中使用该方式依赖一些如com.android.support这些常用的库,避免冲突。 testImplementation:只在单元测试代码的编译和最终打包测试apk时有效。 谢谢阅读
api:跟2.x版本的 compile完全相同 implementation:只能在内部使用此模块,比如我在一个libiary中使用implementation依赖了gson库,然后我的主项目依赖了libiary,那么,我的主项目就无法访问gson库中的方法。这样的好处是编译速度会加快,推荐使用implementation的方式去依赖,如果你需要提供给外部访问,那么就使用api依赖即可 还不...
compile已被弃用,被implementation和api替代 provided已被弃用,被compileOnly替代 testCompile已被弃用,被testImplementation替代 androidTestCompile已被弃用,被androidTestImplementation替代 它们决定了依赖的可见范围。如: implementation:使用该命令编译的依赖,仅仅对当前的Module提供接口。将该依赖隐藏在内部,而不对外部公开,...
provided(compileOnly) 只在编译时有效,不会参与打包 可以在自己的moudle中使用该方式依赖一些比如com.android.support,gson这些使用者常用的库,避免冲突。 apk(runtimeOnly) 只在生成apk的时候参与打包,编译时不会参与,很少用。 testCompile(testImplementation) ...
releaseCompile(releaseImplementation) Release compile仅仅针对Release模式的编译和最终的Release apk打包。 参考链接: Android Studio3.x新的依赖方式(implementation、api、compileOnly) 还再用compile依赖?那你就落后啦 android gradle tools 3.X 中依赖,implement、api 指令 ...
implementation api compileOnly runtimeOnly annotationProcessor。 常用的依赖配置是implementation、api、compileOnly。 一、implementation 依赖不可传递 会将对应的依赖添加到编译路径,并将依赖打包输出 假设项目下有两个模块A(app)、B,A依赖B,A可以访问B,B使用implementation方式依赖C,B可以访问到C,但是A是无法访问到...
依赖配置方式还有：provided、api、apk、compileOnly、runtimeOnly、渠道名+Compile，差异主要在于构建内容和参与构建的时机，多样的配置方式满足了开发者的花样需求，具体区别如下 implementation依赖包中依赖的library只能在依赖包内部使用，主工程无法访问依赖包依赖的library中的类和方法。使用场景：SDK开发中对第三方library...
修改自定义lint规则的Java库的build.gradle(这里是上文的Java lib库),注意到要将implementation改为compileOnly。 applyplugin:'java-library' dependencies { implementationfileTree(dir:'libs', include: ['*.jar']) //将implementation改为compileOnly,不然报错 ...