Given a project with this set of dependencies:
dependencies {
compile "com.android.support:recyclerview-v7:26.1.0"
compile "com.android.support:support-core-utils:26.1.0"
compile "com.android.support:support-fragment:26.1.0"
compile 'io.reactivex.rxjava2:rxjava:2.1.3'
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'
compile 'android.arch.lifecycle:runtime:1.0.0'
compile 'android.arch.lifecycle:extensions:1.0.0-beta2'
compile 'android.arch.lifecycle:reactivestreams:1.0.0-beta2'
compile "android.arch.persistence.room:runtime:1.0.0-beta2"
compile "android.arch.persistence.room:rxjava2:1.0.0-beta2"
annotationProcessor "android.arch.persistence.room:compiler:1.0.0-beta2"
androidTestCompile "com.android.support:support-annotations:26.1.0"
androidTestCompile 'com.android.support.test:rules:0.5'
androidTestCompile 'android.arch.core:core-testing:1.0.0-beta2'
androidTestCompile "com.android.support:support-core-utils:26.1.0"
androidTestCompile "com.android.support:support-compat:26.1.0"
}
I am getting the following error:
Error:Conflict with dependency 'android.arch.lifecycle:common' in project ':app'. Resolved versions for app (1.0.2) and test app (1.0.0) differ. See http://g.co/androidstudio/app-test-app-conflict for details.
How do I resolve this?
Artifact dependency inconsistencies are a common problem, and I expect this to be a frequent issue with the Architecture Components, given that the versioning of those components is byzantine1.
In this case, there is an undocumented version 1.0.2 of the undocumented android.arch.lifecycle:common artifact.
android.arch.lifecycle:extensions:1.0.0-beta2 and android.arch.lifecycle:reactivestreams:1.0.0-beta2 depend upon this undocumented version 1.0.2 of the undocumented android.arch.lifecycle:common artifact. However, the corresponding test artifact (android.arch.core:core-testing:1.0.0-beta2) depends on version 1.0.0 of android.arch.lifecycle:common. As a result, we get the conflict.
The workaround is to manually request 1.0.2 for the test code, via:
androidTestCompile 'android.arch.lifecycle:common:1.0.2'
Gradle will now use 1.0.2 for both the main code and the test code, and all is well.
1 The term "byzantine" is used to describe something that is unnecessarily complex. The Byzantines might have described complex things with the phrase "like the versioning system of the Architecture Components", had those components existed back then.
Related
I just update my android studio to 3.0 now, but when I try to build apk on my project, it's shows following error:
Project depends on com.google.android.support:wearable:2.0.0, so it must also depend (as a provided dependency) on com.google.android.wearable:wearable:2.0.0
My build.gradle is like that:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile project(':lpd')
compile 'com.google.android.support:wearable:2.0.0-alpha2'
compile 'com.google.android.gms:play-services-wearable:9.4.0'
compile files('libs/zxing_2.3.0.jar')
compile(name: 'hwwearableservice-release', ext: 'aar')
compile 'com.google.android.gms:play-services-appindexing:9.4.0'
}
Anything wrong with it?
As per the new gradle dependency instruction the compile has been deprecated so for libraries use api and use the latest stable lib version as 2.1.0
and since the version is a stable release so
api 'com.google.android.support:wearable:2.1.0'
or it's better to use
implementation 'com.google.android.support:wearable:2.1.0'
implementation
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
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), and you should typically use this only in library
modules. That's because, if an api dependency changes its external
API, Gradle recompiles all modules that have access to that dependency
at compile time
I try to use Dagger2 in my Android project;
When I use apt, every things is right.But apt is not supported in AndroidStudio 3.0, so I use annotation processor.But no Dagger2 code created after I click "Make Project";
And I'm sure the annotetion processing is enable in AndroidStudio,because the Butterknife annotation processor is all right.
the follow is the build.gradle:
dependencies {
annotationProcessor 'com.google.dagger:dagger-android-processor:2.13'
compile 'com.google.dagger:dagger-android:2.13'
compile 'com.google.dagger:dagger-android-support:2.13'
compile 'com.jakewharton:butterknife:8.6.0'
annotationProcessor 'com.jakewharton:butterknife-compiler:8.6.0'
}
use this in android studio 3.0 version
implementation 'com.google.dagger:dagger:2.9'
annotationProcessor 'com.google.dagger:dagger-compiler:2.9'
these are the dependences for dagger2 and butter in andriod studio 3.0
//ButterKniffe
compile "com.jakewharton:butterknife:8.8.1"
kapt "com.jakewharton:butterknife-compiler:8.8.1"
//dagger
compile "com.google.dagger:dagger:$dagger_version"
kapt "com.google.dagger:dagger-compiler:$dagger_version"
It is one of the breaking changes coming with gradle:3.0 that Google announced at IO17 gradle:3.0
the compile configuration is now deprecated and should be replaced by implementation or api
From the gradle docs :
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:
List item 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 compile configuration still exists but should not be used as it will not offer the guarantees that the api and implementation configurations provide.
I just update my android studio to 3.0 now, but when I try to build apk on my project, it's shows following error:
Project depends on com.google.android.support:wearable:2.0.0, so it must also depend (as a provided dependency) on com.google.android.wearable:wearable:2.0.0
My build.gradle is like that:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile project(':lpd')
compile 'com.google.android.support:wearable:2.0.0-alpha2'
compile 'com.google.android.gms:play-services-wearable:9.4.0'
compile files('libs/zxing_2.3.0.jar')
compile(name: 'hwwearableservice-release', ext: 'aar')
compile 'com.google.android.gms:play-services-appindexing:9.4.0'
}
Anything wrong with it?
As per the new gradle dependency instruction the compile has been deprecated so for libraries use api and use the latest stable lib version as 2.1.0
and since the version is a stable release so
api 'com.google.android.support:wearable:2.1.0'
or it's better to use
implementation 'com.google.android.support:wearable:2.1.0'
implementation
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
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), and you should typically use this only in library
modules. That's because, if an api dependency changes its external
API, Gradle recompiles all modules that have access to that dependency
at compile time
I'm using the following dependencies:
compile 'com.android.support:appcompat-v7:25.3.0'
compile 'com.android.support:support-v4:25.3.0'
compile 'com.android.support:recyclerview-v7:25.3.0'
compile 'com.android.support:design:25.3.0'
compile 'com.google.firebase:firebase-core:10.0.1'
compile 'com.google.firebase:firebase-database:10.0.1'
compile 'com.google.firebase:firebase-auth:10.0.1'
compile 'com.google.firebase:firebase-crash:10.0.1'
compile 'com.firebaseui:firebase-ui-database:1.1.1'
compile 'com.firebaseui:firebase-ui-auth:1.1.1'
compile 'com.google.android.gms:play-services:10.0.1'
In the Gradle file an error is shown:
All com.android.support libraries must use the exact same version
specification (mixing versions can lead to runtime crashes). Found
versions 25.3.0, 25.1.0, 24.0.0......
I can't update
com.google.android.gms:play-services:10.0.1
because i get the following error:
Please fix the version conflict either by updating the version of the
google-services plugin (information about the latest version is
available at
https://bintray.com/android/android-tools/com.google.gms.google-services/)
or updating the version of com.google.android.gms to 10.0.1.
When i remove the Firebase dependencies the error is gone. What causes this error and how can i get rid of it?
The com.firebaseui:firebase-ui-auth:10.0.1 library has transitive dependencies on:
com.android.support:cardview-v7:25.1.0
com.android.support:customtabs:25.1.0
You can force use of a newer version by explicitly including it in your dependencies:
compile "com.android.support:cardview-v7:25.3.0"
compile "com.android.support:customtabs:25.3.0"
The other version listed in the warning message, 24.0.0, must be from the Play Services library. In Android Studio, you can open the Gradle window and double-click on :app > Tasks > android > androidDependencies to get a dependency report to find the conflicting libraries.
I would also strongly recommend replacing:
compile 'com.google.android.gms:play-services:10.0.1'
with the specific APIs you need. They are listed here in Table 1. Including the single play-services library pulls in ALL the APIs, needlessly increasing the size of your APK and frequently requiring Multidex.
See this related question for further discussion of this issue.
did you add the classpath 'com.google.gms:google-services:version· to the dependencies and the apply plugin: 'com.google.gms.google-services' to the build.gradle ?
and change the compile 'com.android.support:support-v4:25.3.0' by com.android.support:support-v7:25.3.0'
While setting up Espresso 2.1 and the latest version of the Android Testing Support Library, I encountered the next Warning upon building:
Confilct with dependency 'com.android.support:support-annotations'.
Resolved versions for app and test app differ
My build.gradle file is:
apply plugin: 'com.android.application'
android {
...
defaultConfig {
testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner'
}
...
}
dependencies {
androidTestCompile 'com.android.support.test:runner:0.2'
androidTestCompile 'com.android.support.test:rules:0.2'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.1'
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.1.0'
}
Actually I found an existing issue:
we built against the old 22.0.0 and didn't upgrade to 22.1.0.
The runner depends on com.android.support:support-annotations:22.0.0 which conflicts with the latest support library release (22.1.0)
I told gradle which version of support-annotations it needs to resolve to by adding the following line to my dependencies list:
androidTestCompile 'com.android.support:support-annotations:22.1.0'
and the warning is gone.
#appoll Here Stephan Linzner added workaround for that.
Above I've added his comment to this issue, which explains solution:
we are aware of the issue. The gist is that the runner depends on com.android.support:support-annotations:22.0.0 which conflicts with the latest support library release (22.1.0). The correct way to solve this right now, is to tell Gradle which version of support-annotations it needs to resolve to.