Some dependencies like com.android.support libraries must use the same versions in all libraries. The lint error GradleCompatible states that there can be runtime crashes if the versions differs.
This Lint check has been around for a while, I did no see it in the project I work on until recently, maybe support lib 25.0
The dependencies may not always be in sync with the version in the main project and eachother. This is a problem where the dependencies cannot be controlled.
In the project RunnerUp there are two projects that are open source and can be compiled manually (MapBox, GraphView) - assuming that the dependencies can be updated or downgraded. However there are two Google dependencies that uses separate versions: com.google.android.support:wearable:1.4.0 (23.0.1) and com.google.android.gms:play-services-wearable:10.0.1 (24.0.0)
How should GradleCompatible be handled, is there any solution or should the error just be suppressed?
A little more info in a pull request for an attempt to workaround (maybe without any effect).
https://github.com/jonasoreland/runnerup/pull/519
Edit: It seem like adding the offending support libraries will cause the libraries to be compatible.
Snippet (see PR for details).
app:
//support-v4 is not used by app source but wearable, mapbox
//force same version as in the app
latestCompile "com.android.support:support-v4:${rootProject.ext.supportLibrary}"
Related
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.
I made a library, but when I tried to use it with implementation 'com.example:mylibrary:1.3.0' in my app's build.gradle, I keep getting an error saying the ConstraintLayout dependency (which the library uses but not the app) is not found. However it was explicitly defined in the library's build.gradle with implementation.
When I ran gradlew app:dependencies on the terminal, it shows that the library has no dependencies, even though it actually has 2. This seems to be the source of the problem, Gradle can't detect the dependencies of the library.
I didn't run into this problem for a while but when I decided to remove the ConstraintLayout dependency from my app an error appears during build.
When you're using implementation for the dependencies in your library, the project which is dependent with it will not see the dependencies. You need to use api instead of implementation.
I'm using com.android.tools.build:gradle:3.1.1 with the latest Gradle version (https://services.gradle.org/distributions-snapshots/gradle-4.8-20180417000132+0000-all.zip).
When I use compileOnly dependencies some of them won't compile, some will.
E.g.
compileOnly "com.android.support:support-v4:27.1.1"
works perfectly while
compileOnly "com.facebook.stetho:stetho:1.5.0"
gives a compile error:
Android dependency 'com.facebook.stetho:stetho:1.5.0' is set to compileOnly/provided which is not supported
I was under the impression than any dependency can be compileOnly. Nothing indicates otherwise (https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations). Both of these libraries have transitive dependencies.
Any help would be greatly appreciated.
As an experiment, I created a new Android Studio 3.1.1 project. Then, I added a lib module to it as a plain Java library module. I could add compileOnly project(":lib") to the app module, and it compiled. I changed the lib module to be an Android library module (apply plugin: 'com.android.library') with a minimum manifest, and now compileOnly project(":lib") gets the error that you do: "Android dependency 'project :lib' is set to compileOnly/provided which is not supported".
Since there were no other material changes in the lib module, the compileOnly limitation is on Android library modules.
My guess is that it is unclear what "compile only" means for manifest entries, resources, assets, etc. So, they officially punted.
I filed an issue, requesting documentation of this limitation. My requests for documentation usually fall on deaf ears.
At the dawn of "Dynamic feature modules", compileOnly Android library modules could make sense, to allow easy access to the feature module from the base app when it is installed.
That's why I created this feature request: https://issuetracker.google.com/issues/109894265
Feel free to star it and comment with your use cases.
I had a similar issue on a project with many libraries.
I have a libX that I implement in debug with debugImplementation project(':libX') to work with sources, but in release build I target published version releaseImplementation "com.company:libX:1.0.0".
After a refactor, I got a similar error during a release sync about my libX.
Android dependency 'com.company:libX:1.0.0' is set to compileOnly/provided which is not supported.
However, I wasn't using any compileOnly...
The problem was due to one lib which was using libX always as source, (implementation project(':libX')). So in release, gradle was confused as it was implementing libX as sources in some libs, and as published lib in other.
Previously my gradle used to look like this and worked fine (apart from few registered bugs)
implementation 'com.dji:dji-sdk:4.3.2'
Now, after changing to
implementation 'com.dji:dji-sdk:4.4.0'
the Camera and other files cannot be recognized anymore. I am attaching a screenshot of the unrecognized imports.
However when I am trying to add
//dji-drones-sdk
implementation 'com.dji:dji-sdk:4.4.0'
provided 'com.dji:dji-sdk-provided:4.4.0'
I am getting "could not download dji-sdk-provided.jar"
Screenshot attached
All the examples and github codes are in version 4.3.2. Can anyone help me out?
Here is the link to the dji sdk
I have found the issue. After Gradle 3.4, the "provided" is replaced by "compileOnly"
I quote,
Gradle adds the dependency to the compilation classpath only (it is not added to the build output). This is useful when you're creating an Android library module and you need the dependency during compilation, but it's optional to have present at runtime. That is, if you use this configuration, then your library module must include a runtime condition to check whether the dependency is available, and then gracefully change its behavior so it can still function if it's not provided. This helps reduce the size of the final APK by not adding transient dependencies that aren't critical. This configuration behaves just like provided (which is now deprecated).
Hence using compileOnly in place of provided will do the trick.
Here is a link to the gradle changes documentation
Let say I have added Facebook and Twitter dependencies in my app.
com.facebook.android:facebook-android-sdk:4.22.1
com.twitter.sdk.android:twitter:2.1.0
When i look at Gradle tree, They come up with bunch of other transitive dependencies.
Now If Facebook uses com.android.support:support-annotations:24.1.1 and twitter uses com.android.support:support-annotations:25.0.3
Then which version gradle will use.
In gradle tree, It shows -> in front of older version of dependency. I learnt that this means gradle will use the newer version, and will not use the older version.
But this can be a problem, because some libraries are meant to run on the specific versions, and i have faced this problem.
In one of article i found out how npm manages these dependencies conflicts, but i am still unsure how gradle will manage between different version of same library.
You can't have different versions of the same library inside an apk.
As you mentioned, by default, Gradle puts the newest one to the build. If you want to specify a concrete version of the library that should be used in your project, you can add a direct compile (or implementation / api for Android Gradle Plugin v3+) statement with a required version to get one.
Also, you can force version using a special syntax, but it can lead to some problems later. You can find more information about version conflicts resolution in this post