Develop Reference

Firebase-core 17.0 dependency conflicts with Appcompat-v7 [duplicate]

This question already has an answer here:
Manifest merger failed : Attribute application#appComponentFactory cant solve this
(1 answer)
Closed 3 years ago.
Dependencies using groupId com.android.support and androidx.* can not
be combined but found
IdeMavenCoordinates{myGroupId='com.android.support',
myArtifactId='slidingpanelayout', myVersion='28.0.0', myPacking='aar',
myClassifier='null'} and
IdeMavenCoordinates{myGroupId='androidx.versionedparcelable',
myArtifactId='versionedparcelable', myVersion='1.0.0',
myPacking='aar', myClassifier='null'} incompatible dependencies
less... (Ctrl+F1) Inspection info: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).
That error is showing on implementation 'com.android.support:appcompat-v7:28.0.0' when i use implementation 'com.google.firebase:firebase-core:17.0.0'

Firebase migrated to androidx with latest release, so you should either use androidx in your project or simply use older version, for example:
implementation 'com.google.firebase:firebase-core:16.0.9'
About migrating to androidx: https://developer.android.com/jetpack/androidx/migrate

Check the release notes of firebase libraries:
---------------------------------------------------------------
| Service | Gradle dependency |
---------------------------------------------------------------
| Firebase Core | com.google.firebase:firebase-core:17.0.0 |
---------------------------------------------------------------
This release is a MAJOR version update and includes breaking changes.
With this release, libraries are migrated from the Android Support Libraries to the Jetpack (AndroidX) Libraries.
The updated libraries will not work unless you make the following changes in your app:
Upgrade com.android.tools.build:gradle to v3.2.1 or later.
Upgrade compileSdkVersion to 28 or later.
Update your app to use Jetpack (AndroidX); follow the instructions in Migrating to AndroidX.

Migrating support to Android X: Are versions consistent across Modules?

I am migrating a big project to AndroidX.
On my former project, on the top build.gradle, I have defined a variable with the support library version so the 30+ child build.gradle's include the desired support version:
ext {
supportLibraryVersion = "28.0.0"
buildToolsVersion = "28.0.3"
googleServicesVersion = "15.0.0"
}
My question is, now that I have run the Android X refactoring, I see that dependencies have been converted to different packages under the Android X namespace and even out of it:
implementation "androidx.appcompat:appcompat:1.0.0'
implementation "androidx.percentlayout:percentlayout:1.0.0"
implementation 'androidx.palette:palette:1.0.0'
implementation 'com.google.android.material:material:1.0.0'
My question is if now with Android X all module versions are synchronized so it makes sense doing in the top gradle:
ext {
androidXLibraryVersion = "x.x.x"
}
My guess is that modules outside the Android X namespace will have their own version schedule, but I am not even sure that the modules under AndroidX namespace will use common versions.
What do you think?

In the AndroidX world, every group (i.e., the part before the first : such as androidx.appcompat) can have a separate version as per the AndroidX Overview:
Unlike the Support Library, AndroidX packages are separately maintained and updated. The androidx packages use strict Semantic Versioning starting with version 1.0.0. You can update AndroidX libraries in your project independently.
As seen on the AndroidX releases page, they absolutely do upgrade at different rates, but the semantic versioning requirement ensures that stable versions of the libraries will continue to work together.

How to get the latest Room version?

Would you know where to get the latest version for Room ?
On this Android Studio page, it is quoted that the latest Room version is 2.1.0-alpha3 but when I put this version in my build.gradle file, the project cannot compile and the following error is shown :
ERROR: Failed to resolve: android.arch.persistence.room:runtime:2.1.0-alpha3
Show in Project Structure dialog
Affected Modules: app

it is quoted that the latest Room version is 2.1.0-alpha3
It is.
when I put this version in my build.gradle file, the project cannot compile and the following error is shown
Your version is fine. Your artifact is the problem.
All new libraries are AndroidX. Your choices are:
Stick with whatever version you are using right now and keep your android.arch.persistence.room:runtime artifact and its classes, or
Migrate to AndroidX, in which case you would use androidx.room:room-runtime as the artifact, and need to change your code to reference the androidx classes for Room and everything else

The thing is, if you'r using AndroidX then the latest is 2.1.0-alpha3, or, if you are using Support libraries then it's 1.1.1 or whatever is latest and that's what mentioned in the documentation. As mentioned by CommonsWare, it's the artifact, and to find out the mappings, see this mapping documentation. And AndroidX is:
The AndroidX library contains the existing support library and also
includes the latest Jetpack components.
Example using support libraries:
dependencies {
// Other libraries...
implementation 'android.arch.persistence.room:runtime:1.1.1'
annotationProcessor 'android.arch.persistence.room:compiler:1.1.1'
}

The solution is to check AndroidX when starting a new project in Android Studio, then in the App Module Build.Gradle file the following works perfectly :
def room_version = "2.1.0-alpha03"
implementation "androidx.room:room-runtime:$room_version"
kapt "androidx.room:room-compiler:$room_version" // use kapt for Kotlin

Android dependency is set to compileOnly/provided which is not supported

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.

How does gradle handle multi modules with different support library v4 revisions?

I have an Android project which depends on different modules and each modules depends on different revision of the android support-v4 library
1) My app also depends on the latest android support-v4 library (revision 21) so in this build.gralde I put a line like that:
dependencies {
compile 'com.android.support:support-v4:21.0.0'
}
2) Facebook SDK (v.3.15) module that also depends on the android support library v4, but revision 13 and its build.gradle file says:
dependencies {
compile 'com.android.support:support-v4:13.0.+'
compile files('../libs/bolts.jar')
}
3) and one more module that, we can call Module3 in that case, also depends on the support-v4 but with a different revision than the other modules, like that:
dependencies {
compile 'com.android.support:support-v4:19.0.+'
compile files('../libs/bolts.jar')
}
Questions:
1) How does gradle handle different support-v4 library revisions?
2) What does it do exactly?
3) What does it mean in terms of apk size?

In this case Gradle will fail the build (tested on my skin and I did not find other solutions)
"Unfortunately" you have to use the same version of support on any module.
From docs.gradle.com:
Gradle offers the following conflict resolution strategies:
Newest: The newest version of the dependency is used. This is Gradle's default strategy, and is often an appropriate choice as long as versions are backwards-compatible.
Fail: A version conflict results in a build failure. This strategy requires all version conflicts to be resolved explicitly in the build script. See ResolutionStrategy for details on how to explicitly choose a particular version.
While the strategies introduced above are usually enough to solve most conflicts, Gradle provides more fine-grained mechanisms to resolve version conflicts:
Configuring a first level dependency as forced. This approach is useful if the dependency in conflict is already a first level dependency. See examples in DependencyHandler.
Configuring any dependency (transitive or not) as forced. This approach is useful if the dependency in conflict is a transitive dependency. It also can be used to force versions of first level dependencies. See examples in ResolutionStrategy
Dependency resolve rules are an incubating feature introduced in Gradle 1.4 which give you fine-grained control over the version selected for a particular dependency.