Cannot remove an external library causing the variation in library version conflict - android

I could not get myself out of this situation. It keeps on showing libraries version must be exact same even if there is no conflicting library in "build.gradle". Possibly because of conflicting version in the External Libraries and I can't remove one.

android {
configurations.all {
resolutionStrategy.force 'libraryname:version'
}
}
That will force it to use a specific version of the library no matter what. Note that this can break their library if there are incompatible changes.

Related

Android dependency has different version for the compile and runtime classpath

I am using a lot of Firebase related libraries in my project. Upon syncing, I am facing the following error.
Android dependency 'com.google.firebase:firebase-iid' has different
version for the compile (17.0.3) and runtime (17.1.1) classpath. You
should manually set the same version via DependencyResolution
The thing is that I have not even declared firebase-iid in my dependencies and this is coming as a transitive dependency from other firebase libraries.
Upon running the dependency chart, I am able to find the following things.
Version 17.0.3 is coming from com.google.android.gms:play-services-measurement-api:16.4.0
Whereas 17.1.1 is coming from com.google.firebase:firebase-messaging:17.5.0
Ideally it should resolve it internally and the higher version should be automatically picked. But this is not happening.
Any idea why this is happening and how to resolve this issue?
There is not updated gradle for com.google.android.gms:play-services-measurement-api:
The latest release is on March 2019, version : 16.4.0 .
So, your implementation is not correct for this measurement-api .
Use :
com.google.android.gms:play-services-measurement-api:16.4.0
com.google.firebase:firebase-messaging:17.5.0
refer this link : https://mvnrepository.com/artifact/com.google.android.gms/play-services-measurement-api/16.4.0
https://mvnrepository.com/artifact/com.google.firebase/firebase-messaging
Yes you are right, gradle should automatically resolve to a single version of a library, but as I experienced sometimes, it does, sometimes, it does not. But when It does not resolve to a single version of same library, we can force it to use a single specific version like explained below.
configurations.all {
resolutionStrategy {
force "com.google.android.gms:play-services-measurement-api:17.1.1"
force "com.google.firebase:firebase-messaging:17.5.0"
}
}
dependencies {
// ... all dependencies here...
}
Try using above code forcing gradle to use a single version. Might help in your case.

All gms/firebase libraries must use the exact same version specification

All gms/firebase libraries must use the exact same version specification (mixing versions can lead to runtime crashes). Found versions 15.0.0, 12.0.1. Examples include com.google.android.gms:play-services-ads:15.0.0 and com.google.android.gms:play-services:12.0.1
There are some combinations of libraries, or tools and libraries, that are incompatible, or can lead to bugs. One such incompatibility is compiling with a version of the Android support libraries that is not the latest version (or in particular, a version lower than your targetSdkVersion).
android studio is giving me this error. How to solve this error? Here is the image of showing error.
You need to add a resolution strategy in your build.gradle file to tell which version of the library need to be used while building your application. The configuration might look something like this.
configurations.all {
resolutionStrategy {
force 'com.android.support:design:25.3.1'
force 'com.android.support:support-v4:25.3.1'
force 'com.android.support:appcompat-v7:25.3.1'
}
}
Modify as per your requirement of the library version.
As it says itself
Found versions 15.0.0, 12.0.1.
You should use same version for all google gms libraries.
Replace this line
compile 'com.google.android.gms:play-services:12.0.1'
with this
compile 'com.google.android.gms:play-services:15.0.0'
First of all use the whole play service is just wrong unless you really need every single sub-package, but from your screenshot you are already using some sub-package. The use of the whole play service package could means you need multi dex support because you include a lot of not needed methods, Proguard is your friend in this case. So my response is: just remove that line.

Correct way to resolve error: all support libraries must use the exact same version

I'm using Tommy Buonomo's excellent library (here on GitHub and this SO question where he introduced it) to add a position indicator to a ViewPager, however I am getting a gradle error about support libraries versions which raises a bigger question for me.
The specific error is:
Error:(39, 20) All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes). Found versions 27.0.0, 25.3.1. Examples include 'com.android.support:support-compat:27.0.0' and 'com.android.support:animated-vector-drawable:25.3.1'
(Note that this is flagged as an Error by Android Studio BUT the app still compiles and runs.)
The bigger question this raises is how do you properly handle conflicts in support library versions like this?
I have added the library simply by adding:
compile 'com.tbuonomo.andrui:viewpagerdotsindicator:1.0.1'
to my dependencies in my app level build.gradle and as I say everything is working well except for the error.
I'd like to keep my app as error and warning free as possible so I'd like to understand what I can do to resolve this.
This is the first time I have used a third party library in one of my projects so this is the first time I have encountered this specific issue.
So, some questions.
Must a library developer create various versions of their library that target specific other support library versions or can they simply create one library that supports all versions up to a specific version? (It would seem impractical to have to create specific versions as you don't know what versions a library user is going to be using).
Is a user usually able to change the version of other support libraries that the third-party library calls? I cannot seem to find anywhere in the external libraries section of the project tree that would let me do this for Tommy's library so I assume many libraries are like this.
Is the only option to wait for the library developer to create a new version that uses the same API level support libraries that my app uses? (Or to change the support library version that my app uses).
Would another option be to fork the library on github and change the support library versions it uses in the new fork? This then raises the issue of learning how to compile and use libraries and to republish them for others to use (maybe as a pull request to the original author so that they could incorporate the changes - this would be most in the spirit of Tommy having released the library anyway) - and would also require an understanding of all of questions 1-3.
I feel like having got this error I have opened a can of worms here, but I would like to understand more about how this should be fixed if I am to do things properly.
(FYI, I am building my app with compile and target SDK v27 in order to follow best practice of targetting latest API level. Tommy's library already has a pull request to support API v26 which is awaiting action)
You can force the dependencies to use specific version of support library, try adding this in your project level build.gradle file:
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "yourSupportLibVersion"
}
}
}
}
If you're using support library version 27.0.0 replace yourSupportLibVersion with 27.0.0
Explanation :
Why're we using subprojects?
In a multi-project gradle build, you have a root project and the subprojects. The root project is where the build starts from. Everything else, either added as a dependency in gradle or external libraries added manually, will be processed as a subproject by gradle.
What's ResolutionStrategy?
Quoting from the docs, ResolutionStrategy defines the strategies around dependency resolution. For example, forcing certain dependency versions, substitutions, conflict resolutions or snapshot timeouts.
Why exclude multidex?
The reason why we've excluded multidex from getting forced to our required version is that,the dependency name for multidex also contains com.android.support, which is com.android.support:multidex:someVersion where someVersion isn't the same as the support lib version, it's independent from it and that's the reason we're excluding it from being forced to the support lib verison. Note : If you've more such dependencies, you should add them in the if condition above.
and after we've insured that the dependency is indeed a support library ,then we're simply telling gradle to use our desired version for it.
The library you mentioned is using v25.3.1 of the appcompat library and hasn't been updated in last 4 months.
To avoid the support library version conflict, I think you should clone/download the library and include it manually as a module dependency in your project so that you can update the version of the appcompat library and use it without any problem.
Clone the git repository into another directory.
In Android Studio choose File → Import Module and choose the module directory (the one containing file build.gradle)
Then right click in your module app → open module settings → dependencies → add module dependency

Duplicate gradle dependencies always compiled?

If i have say the appcompat-v7 dependency in my build.gradle and then I have another dependency that also uses the appcompat-v7 library are both of those compiled or is just one compiled and the other is ignored?
Reason I ask is I ran the gradle command that gives you your dependency tree and there were a lot of duplicated dependencies that are in other libraries but already declared in my app
Gradle resolves the dependencies according to some rules:
If they have the same version number, there is no problem and the dependency is added once with the given version number.
If they are imported twice with different version number, gradle uses a default conflict strategy to choose the "best one".
In all case, a given library is always added only once.

Android support library incompatiblity

I have a jcenter library ToggleButtons I develop that I import into my app. After switching to support 26.1.0 in my app, I receive this error:
All com.android.support libraries must use the exact same version
specification (mixing versions can lead to runtime crashes). Found
versions 26.1.0, 25.3.1
ToggleButtons:
com.android.support:cardview-v7:25.3.1
Main app:
com.android.support:design:26.1.0
I'm using other libraries such as Glide that reference even earlier versions of the support library (I haven't upgraded to 4 yet), but those don't have an issue. Have I designed the library improperly somehow?
This was always a recommendation, now they're making it generate errors.
You absolutely can't run an app with both versions, because that would cause duplicated classes errors. That means you must pick one of those manually now, while previously gradle would automatically choose one for you.
I'd suggest you use the higher number, since doing the opposite risks missing new features/assets that either library or app really depends on.
You can add this between your android and dependencies blocks in your application / library module's build.gradle for each conflict you must manually solve:
def supportLibraryVersion = '26.0.1'
configurations.all {
resolutionStrategy {
force "com.android.support:cardview-v7:$supportLibraryVersion"
}
}
I guess you get the idea of how it works.
Edit:
As noted by #eugen-pechanec the best practice is having all your support libraries with same version throughout all your projects modules. Also, it's best to use the same numbers on build tools (in module's build.gradle, inside android block).
Here's what your app depends on:
+ design:26.1.0
+ appcompat-v7:26.1.0
+ support-v4:26.1.0
+ recyclerview-v7:26.1.0
+ support-v4:26.1.0
Here's what the library depends on:
+ cardview-v7:25.3.1 (i.e. at least 25.3.1)
Here's what it means:
Card view library doesn't have any (runtime) dependency on other support libraries so technically in this case it's safe to use different versions. However this may change at any time.
More importantly your own code does not define cardview-v7 as a dependency so there's no way for gradle to know it should pull updated version as well.
The easiest fix then is just defining the dependency in your build.gradle:
def supportLibraryVersion = '26.0.1'
compile "com.android.support:cardview-v7:$supportLibraryVersion"
No force, nothing special. Upgrading a dependency is not a problem. Only downgrading is.
I still don't understand why Glide doesn't throw this error when they're using support 25.
As hinted above, Glide uses at least support-v4 25.x.x. And because a newer version of support-v4 is already requested by your own module, the dependency gets silently upgraded.

Categories

Resources