Develop Reference

What’s the use of the coroutines dependencies on an Android app?

My question is what’s the use of the coroutines dependencies on an Android app?
Specifically the following dependency that is mentioned in the Android Developers site
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9'
(or the newer version 1.6.4)
Seems to me that everything that is related to coroutines, works fine even without this dependency. So what is the purpose of adding this dependency to an Android project?
The rest of the dependencies of the Android project
implementation 'androidx.core:core-ktx:1.8.0'
implementation 'androidx.appcompat:appcompat:1.5.1'
implementation 'com.google.android.material:material:1.6.1'
implementation 'androidx.constraintlayout:constraintlayout:2.1.4'
implementation "androidx.recyclerview:recyclerview:1.3.0-alpha02"
implementation 'androidx.legacy:legacy-support-v4:1.0.0'

Just for your information: coroutines are already included in libraries:
dependencies {
implementation('androidx.appcompat:appcompat:1.5.1'){
exclude group: 'org.jetbrains.kotlinx', module: 'kotlinx-coroutines-core-jvm'
exclude group: 'org.jetbrains.kotlinx', module: 'kotlinx-coroutines-android'
exclude group: 'org.jetbrains.kotlinx', module: 'kotlinx-coroutines-core'
}
//implementation 'com.google.android.material:material:1.7.0' <- include coroutines
//implementation 'androidx.constraintlayout:constraintlayout:2.1.4' <- include coroutines
testImplementation 'junit:junit:4.13.2'
androidTestImplementation 'androidx.test.ext:junit:1.1.4'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.0'
}
That's why you see and can use coroutines features.

According to the docs:
This gives you access to the Android Dispatchers.Main coroutine dispatcher and also makes sure that in case of a crashed coroutine with an unhandled exception that this exception is logged before crashing the Android application, similarly to the way uncaught exceptions in threads are handled by the Android runtime.
So if you don't use Dispatchers.Main and don't want exceptions to be logged, you can remove this dependency. And make sure to test the app after removing it.

I'm adding another answer because this is a broader issue with Android libraries in general, not just the coroutines library, so you need to be mindful of it. The libraries you use have their own dependencies, so they pull in certain versions of other libraries that they require.
These additional dependencies are called transitive dependencies, and it's why you can use e.g. LiveData without adding the androidx.lifecycle:lifecycle-livedata-ktx package - it's because something else is pulling in a version of that library, e.g. the activity library. You'll often see these dependency versions mentioned in the changelogs for a library, like this activity one:
Version 1.5.1
July 27, 2022
Dependency update
The Activity library now depends on the Lifecycle 2.5.1.
What this means is using version 1.5.1 of the activity library will pull in version 2.5.1 of the lifecycle libraries. That's the most recent dependency version bump, so that goes for the newer versions of activity too.
But often those transitive dependencies will be outdated - libraries usually won't require new versions of another dependency unless they've made significant changes that require an upgrade. Generally, they're not requiring the most recent versions of other libraries.
This means if you want to use newer versions of those libraries, you need to explicitly add them as dependencies yourself. For a long time, activity would pull in a really old version of lifecycle - if you wanted to use the newer features, you had to import lifecycle yourself, using the version number you wanted. When a dependency is declared multiple times with different versions, Gradle picks the highest version (unless you explicitly take steps to prevent that).
If you want to see the dependency tree for your app, you can run the dependencies Gradle task - it'll show you what dependencies each library requests, their version numbers, and whether they're the version that's ultimately being selected or if they're being superseded by another declaration elsewhere in the tree. You can do that with this button in the Gradle window:
and running gradle app:dependencies (or using gradlew from the command line). There's some info about interpreting the output here.

Android Architecture Components: Gradle sync error for dependency version

I'm trying to add ViewModel and LiveData to a Kotlin app. I have the following dependencies added to my module's build.gradle:
implementation "android.arch.lifecycle:extensions:1.1.1"
kapt "android.arch.lifecycle:compiler:1.1.1"
testImplementation "android.arch.core:core-testing:1.1.1"
I'm given the following error:
Android dependency 'android.arch.lifecycle:runtime' has different version for the compile (1.0.0) and runtime (1.1.1) classpath. You should manually set the same version via DependencyResolution
Removing the first line (extensions) fixes the issue, indicating that the error is coming from there, but I can't figure out why.

As #RedBassett mentions Support libraries depends on this lightweight import (runtime library) as explained at android developers documentation.
This is, android.arch.lifecycle:runtime:1.0.0 is spreading up in the dependency tree as a result of an internal api (transitive) import so in my case I only had to include extensions library as "api" instead of "implementation" so that it will override its version to the highest (1.1.1).
In conclusion, change
implementation "android.arch.lifecycle:extensions:1.1.1"
to
api "android.arch.lifecycle:extensions:1.1.1"

In your main build.gradle file
allprojects {
...
configurations {
all {
resolutionStrategy {
force "android.arch.lifecycle:runtime:1.1.1"
}
}
}
}
This will enforce version 1.1.1

Apparently support-v4 was causing the conflict. In the case of this question, the Gradle dependency task wasn't working correctly, but for anyone else who runs into this issue:
./gradlew :app:dependencies will show the sub-dependencies used by your dependencies. Search the output of this command (changing app for your module name) for the dependency causing the conflict.

#RedBassett is right. However I was still having some problem excluding android.arch.lifecycle related sub dependencies.
In my case the conflict was caused in com.android.support:appcompat-v7:27.1.1.
This is how my gradle dependency looks like after excluding it.
implementation ('com.android.support:appcompat-v7:27.1.1') {
exclude group: 'android.arch.lifecycle'
}
api "android.arch.lifecycle:runtime:1.1.1"
kapt "android.arch.persistence.room:compiler:1.1.1"
Also, you will have to add this exclude in every imported module.

I searched for all dependencies with ./gradlew :app:dependencies as #RedBassett mentioned. I noticed the incompatible version of android.arch.core:runtime that Gradle was complaining about was stemming from my version of com.android.support:appcompat-v7, so I just updated that version to the latest and everything worked.

Library dependency issues with gradle 3.0.0-alphaX

I have a library project with submodules that include many dependencies that I'd like to pass to the developer's application. For example, module A may include all the necessary appcompat dependencies.
With the migration changes, I've updated all compile cases to api, which should not affect anything. However, I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.
Is there any way around this?
One of the build gradle files of my library submodules can be found here for reference.
The dependencies:
dependencies {
api "org.jetbrains.kotlin:kotlin-stdlib:${KOTLIN}"
api "com.android.support:appcompat-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:support-v13:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:design:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:recyclerview-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support:cardview-v7:${ANDROID_SUPPORT_LIBS}"
api "com.android.support.constraint:constraint-layout:${CONSTRAINT_LAYOUT}"
api "com.mikepenz:iconics-core:${ICONICS}#aar"
api "com.mikepenz:google-material-typeface:${IICON_GOOGLE}.original#aar"
api "com.afollestad.material-dialogs:core:${MATERIAL_DIALOG}"
api "com.jakewharton.timber:timber:${TIMBER}"
api "org.jetbrains.anko:anko-commons:${ANKO}"
}
Edit:
To clarify, the sample project in the module actually does build properly, but there's an issue with using the dependencies in any other app, where it pulls from jitpack. See this gradle as an example that won't build.
I've tried using combinations of api, implementation, #aar, and transitive.
Come to think of it, this may be a jitpack issue and not a gradle issue, but if anyone else has a resolution I'd like to hear it.

I no longer have access to any of the libraries dependencies. I can only use code and references from my library itself.
It is correct.
From the gradle docs :
dependencies {
api 'commons-httpclient:commons-httpclient:3.1'
implementation 'org.apache.commons:commons-lang3:3.5'
}
Dependencies appearing in the api configurations will be
transitively exposed to consumers of the library, and as such will
appear on the compile classpath of consumers.
Dependencies found in the implementation configuration will, on the
other hand, not be exposed to consumers, and therefore not leak into
the consumers' compile classpath. This comes with several benefits:
dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive
dependency
faster compilation thanks to reduced classpath size
less recompilations when implementation dependencies change: consumers would not need to be recompiled
cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that
distinguish exactly between what is required to compile against the
library and what is required to use the library at runtime (in other
words, don't mix what is needed to compile the library itself and what
is needed to compile against the library).

The issue seems to be related to the android-maven-gradle-plugin
Issue Report

It's has been fixed in version "2.0" of android-maven-gradle-plugin
just update to
dependencies {
classpath 'com.github.dcendents:android-maven-gradle-plugin:2.0'
}
or using the new syntax since Gradle 2.1
plugins {
id "com.github.dcendents.android-maven" version "2.0"
}
using api in your library module allows you to access the transient dependencies only in your library code; not the apps that consume it.
so to achieve the desired effect you need to change in your sample module.
implementation project(':core')
to
api project(':core')
note you don't need to use api in your library it's better to use implementation as it speeds up your build.

What is "implementation" in Kotlin Gradle dependencies?

I'm using Android Studio 3.0 Preview to start new Kotlin project. As I try to add dependencies in build.gradle I saw implementation scope instead of usual compile.
androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
implementation 'com.android.support:appcompat-v7:25.3.1'
testImplementation 'junit:junit:4.12'
There's also androidTestImplementation and testImplementation scope.
In the end, I add compile to add third party dependencies and it works.
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'
So my questions are..
What is implementation, androidTestImplementation, and testImplementation scope?
Is it any different than compile, testCompile, and androidTestCompile?
Which one I should use for my Kotlin project?
Edit:
My bad, this question is not Kotlin specific. It's the new Android Gradle Plugin configuration.

This is not specific to Kotlin, but has to do with the new Gradle plugin for Android.
compile, provided and apk are now deprecated.
Use implementation or api instead of compile, compileOnly instead of provided, and runtimeOnly instead of apk.
The reason for this is to speed up multi-module builds. Given module A which depends on module B which in turn depends on module C, a change in module C would trigger a recompile of module A as well. If A does not use C directly, there is no need for A to recompile when C changes.
The implementation configuration ensures exactly this: if you specify implementation project(':C') in B, you cannot access C from A and you avoid building unnecessary modules. In a large multi-module project this can save a lot of time.
See Migrate to the new Gradle plugin for more information.

Earlier version of gradle v3.0.0-alpha1 used to use compile but it has been deprecated now on.
Why?
Dependencies appearing in the compile configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath.
Let's take an example to understand this. Let's say, I created a Library_Image_Upload that supports Image uploading to the server. I used Library_Network lib in Library_Image_Upload that supports all the network operations. My library only makes use of image uploads and provide a convenient way of uploading images. Now as i used Library_Network lib in my Library_Image_Upload project, everyone using this lib will have functionality of Image Uploading along with all network operations that someone may also use(Important). Later on i thought there is a better alternative to Library_Network as Library_Magic_Image and used it. So all the API functions exposed by Library_Network are gone and whoever is using those functions has broken build.
implementation comes with several benefits:
Dependencies do not leak into the compile classpath of consumers anymore, so you will never accidently depend on a transitive dependency
Faster compilation thanks to reduced classpath size
Less recompilations when implementation dependencies change: consumers would not need to be recompiled
Cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).
To learn more read The Java Library Plugin
So i think you have the answer of all three questions.
I hope it helps.

android gradle 4.0 compile dependency deprecated- how does new api configuration visibility work? [duplicate]

I'm trying to figure out what is the difference between api and implementation configuration while building my dependencies.
In the documentation, it says that implementation has better build time, but, seeing this comment in a similar question I got to wonder if is it true.
Since I'm no expert in Gradle, I hope someone can help. I've read the documentation already but I was wondering about an easy-to-understand explanation.

Gradle compile keyword was deprecated in favor of the api and implementation keywords to configure dependencies.
Using api is the equivalent of using the deprecated compile, so if you replace all compile with api everything will works as always.
To understand the implementation keyword consider the following example.
EXAMPLE
Suppose you have a library called MyLibrary that internally uses another library called InternalLibrary. Something like this:
// 'InternalLibrary' module
public class InternalLibrary {
public static String giveMeAString(){
return "hello";
}
}
// 'MyLibrary' module
public class MyLibrary {
public String myString(){
return InternalLibrary.giveMeAString();
}
}
Suppose the MyLibrary build.gradle uses api configuration in dependencies{} like this:
dependencies {
api(project(":InternalLibrary"))
}
You want to use MyLibrary in your code so in your app's build.gradle you add this dependency:
dependencies {
implementation(project(":MyLibrary"))
}
Using the api configuration (or deprecated compile) you can access InternalLibrary in your application code:
// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());
// Can ALSO access the internal library too (but you shouldn't)
System.out.println(InternalLibrary.giveMeAString());
In this way the module MyLibrary is potentially "leaking" the internal implementation of something. You shouldn't (be able to) use that because it's not directly imported by you.
The implementation configuration was introduced to prevent this.
So now if you use implementation instead of api in MyLibrary:
dependencies {
implementation(project(":InternalLibrary"))
}
you won't be able to call InternalLibrary.giveMeAString() in your app code anymore.
This sort of boxing strategy allows Android Gradle plugin to know that if you edit something in InternalLibrary, it must only trigger the recompilation of MyLibrary and not the recompilation of your entire app, because you don't have access to InternalLibrary.
When you have a lot of nested dependencies this mechanism can speed up the build a lot. (Watch the video linked at the end for a full understanding of this)
CONCLUSIONS
When you switch to the new Android Gradle plugin 3.X.X, you should replace all your compile with the implementation keyword *(1). Then try to compile and test your app. If everything it's ok leave the code as is, if you have problems you probably have something wrong with your dependencies or you used something that now is private and not more accessible. *Suggestion by Android Gradle plugin engineer Jerome Dochez (1))
If you are a library mantainer you should use api for every dependency which is needed for the public API of your library, while use implementation for test dependencies or dependencies which must not be used by the final users.
Useful article Showcasing the difference between implementation and api
REFERENCES
(This is the same video splitted up for time saving)
Google I/O 2017 - How speed up Gradle builds (FULL VIDEO)
Google I/O 2017 - How speed up Gradle builds (NEW GRADLE PLUGIN 3.0.0 PART ONLY)
Google I/O 2017 - How speed up Gradle builds (reference to 1*)
Android documentation

I like to think about an api dependency as public (seen by other modules) while implementation dependency as private (only seen by this module).
Note, that unlike public/private variables and methods, api/implementation dependencies are not enforced by the runtime. This is merely a build-time optimization, that allows Gradle to know which modules it needs to recompile when one of the dependencies changes its API.

Consider you have app module which uses lib1 as a library and lib1 uses lib2 as a library. Something like this: app -> lib1 -> lib2.
Now when using api lib2 in lib1, then app can see lib2 code when using: api lib1 or implementation lib1 in the app module.
BUT when using implementation lib2 in lib1, then app can not see the lib2 code.

Please refer the link: Android Studio Dependency Configuration available at android developers' official site.
Inside the dependencies block, you can declare a library dependency using one of several different dependency configurations (such as implementation shown above). Each dependency configuration provides Gradle with different instructions about how to use the dependency.
implementation
Gradle adds the dependency to the compile classpath and packages the dependency to the build output. However, when your module configures an implementation dependency, it's letting Gradle know that you do not want the module to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime.
Using this dependency configuration instead of api or compile (deprecated) can result in significant build time improvements because it reduces the number of modules that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.
api
Gradle adds the dependency to the compile classpath and build output. When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that dependency to other modules, so that it's available to them at both runtime and compile time.
This configuration behaves just like compile (which is now deprecated), but you should use it with caution and only with dependencies that you need to transitively export to other upstream consumers. That's because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build time. Unless you want to expose a dependency's API to a separate module, library modules should instead use implementation dependencies.

From gradle documentation:
Let’s have a look at a very simple build script for a JVM-based project.
plugins {
id 'java-library'
}
repositories {
mavenCentral()
}
dependencies {
implementation 'org.hibernate:hibernate-core:3.6.7.Final'
api 'com.google.guava:guava:23.0'
testImplementation 'junit:junit:4.+'
}
implementation
The dependencies required to compile the production source of the project which are not part of the API exposed by the project. For example the project uses Hibernate for its internal persistence layer implementation.
api
The dependencies required to compile the production source of the project which are part of the API exposed by the project. For example the project uses Guava and exposes public interfaces with Guava classes in their method signatures.

Answers from #matpag and #dev-bmax are clear enough to make people understand different usages between implementation and api. I just want to make an extra explaination from another angle, hopes to help for peoples that have the same question.
I created two projects for testing :
project A as a java library project named 'frameworks-web-gradle-plugin' depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE'
project B depends on project A by implementation 'com.example.frameworks.gradle:frameworks-web-gradle-plugin:0.0.1-SNAPSHOT'
The dependencies hierarchy descripted above looks like:
[project-b] -> [project-a] -> [spring-boot-gradle-plugin]
Then I tested following scenarios:
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by implementation .
Run gradle dependencies command in a terminal in poject B root dir，with following screenshot of output we can see that 'spring-boot-gradle-plugin' appears in runtimeClasspath dependencies tree, but not in compileClasspath's, I think that's exactly why we can't make use of library that declared using implementation, it just won't through compilation.
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by api
Run gradle dependencies command in a terminal in poject B root dir again.
Now 'spring-boot-gradle-plugin' appears both in compileClasspath and runtimeClasspath dependencies tree.
A significant difference I noticed is that the dependency in producer/library project declared in implementation way won't appear in compileClasspath of consumer projects, so that we can't make use of corresponding lib in the consumer projects.

One more technical note regarding api vs implementation. Suppose you have following dependencies:
dependencies {
api "com.example:foo:1.0"
implementation "com.example:bar:1.0"
}
If you install a generated jar file in your local Maven repository (with help of maven-publish plugin) you will see that generated pom.xml file will look like this:
<dependency>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>bar</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
Note: api was converted to compile scope and implementation - to runtime scope.
That allows for consumers of this library to avoid having runtime dependencies in their compile classpath.

Now there is good explanation in the documentation
The api configuration should be used to declare dependencies which are
exported by the library API, whereas the implementation configuration
should be used to declare dependencies which are internal to the
component.