Develop Reference

AndroidX Jetifier unable/failed to transform 3rd-party transitive dependency that still use Support Library

I've recently migrated my project to use AndroidX
My apps crashes, after I migrate to AndroidX, due to library still using Support Library. Here's a list of my 3rd-party dependencies/library, that failed to transform into AndroidX:
com.clevertap.android:clevertap-android-sdk:3.4.2
com.readystatesoftware.chuck:library:1.1.0
com.ncapdevi:frag-nav:2.4.0
jp.wasabeef:recyclerview-animators:2.3.0
com.github.chivorns:smartmaterialspinner:1.1.6
com.facebook.android:facebook-android-sdk:5.0.1
com.github.PierfrancescoSoffritti:AndroidYouTubePlayer:7.0.1 (I still cannot upgrade it to 10.x.x, because major API changes)
com.github.nikartm:image-support:1.0.5
My Setups:
AS & AGP: 3.6.2
targetSdk: 29
minSdk: 16
Data & View Binding: Both enabled
Gradle DSL: Kotlin
Gradle: gradle-6.0.1-all
What I've done so far:
Using Refactor -> Migrate to AndroidX tools from Android Studio, but ended-up force close it, because takes a long time
android.enableJetifier=true & android.useAndroidX=true
Using the shell scripts to manually mapping artifact, class and imports from Support Library to AndroidX, thanks #Danlew, also #Danlew mentioned in ADS '19 talks here
Already checked my :app:dependencies that 3rd-party dependencies already migrated to use AndroidX artifacts, but only a few of them (failed for the above dependencies list)
Deleting ./root_project/.idea, ./root_project/.gradle & ~/.gradle/caches (to fix compile-error/IDE error, references: AndroidX migrate dependency / libraries
Understanding the jetifier: What is Jetifier? & official android docs
Did a workaround to use AndroidX for annotation processor like: Glide & Dagger
Checking the ~/.gradle directories for the jetified-* libs the jetified aar exist, unfortunately it's failed for clevertap & others libs listed above.
My conclusions, the jetifier works by rewriting the binary .class of our 3rd-party library if Support Library imports/class detected, and modify (jetified/mapping it) into AndroidX respectively.
But in my case, the dependencies listed above doesn't use correct AndroidX imports and resulting runtime crash, due to having a transitive dependent for Support Library.
Does jetifier currently doesn't support transitive dependency inside 3rd-party library as well? But, strangely it works for a few library (unlisted from above)
[UPDATED 1]
In the meantime (quickfix):
I did downloading all the transitive dependencies of the libraries exhaustively one-by-one
Using jetifier-standalone commands instead for the libraries aar
Manually adding the libraries aar and its dependencies to app/build.gradle.kts as flatDirs
Is this really a workaround, is there anything better I can do?
[UPDATED 2]
I've using a maintained version of chuck as well. But found this same issue as well:
cannot generate view binders com.sun.tools.javac.code.Symbol$CompletionFailure: class file for android.support.v7.widget.AppCompatImageView not found
After checking my 3rd-party libs, I also ended-up manually adding the aar after I use jetifier-standalone for this library:
com.clevertap.android:clevertap-android-sdk:3.4.2
com.github.nikartm:image-support:1.0.5
Many also recommends to use api instead of implementation but for me, I don't want to bloated my project with transitive dependency
In other SO also recommends below:
either remove the library,
forked it to support androidx / waiting for the author to upgrade it
manually using jetifier-standalone for those specicif libs, and include as local aar (this is my best approach, right now)
Unless the jetifier able to state this into official documentation, for its limitation: https://developer.android.com/jetpack/androidx/releases/jetifier
Seems like there's the least we can do, and hope, many of the 3rd-party authors will upgrade to AndroidX soon.
Here's a bonus article for references:
You can use can-i-drop-jetifier libs to detects does your libs (transitively) needs jetifier enabled or not
The time is right to migrate to AndroidX with this baby-steps
Better structure packaging with AndroidX and also a headache along the way

Turns out my current workaround was using this approach: https://github.com/bumptech/glide/issues/3080#issuecomment-495430590
Magical regex to turns a blacklist into a whiteliset
android.jetifier.blacklist=^(?!.*[\\\\/](com\\.github\\.bumptech\\.glide|com\\.clevertap\\.android|com\\.facebook\\.android|com\\.github\\.nikartm|com\\.github\\.PierfrancescoSoffritti|com\\.github\\.prolificinteractive)[\\\\/]).*$
If NoClassDef exceptions thrown, then I add the library package name into the android.jetifier.blacklist to whitelisted them.
In the above cases, I'm trying to whitelist:
glide
clevertap
nikartm
facebook-sdk
YoutubeAndroidPlayer (v7) still not using v10
prolificinteractive

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.

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

Android gradle JAR dependency ends up declared as native

In my Android projects build.gradle file I have:
dependencies {
compile 'org.apache.directory.studio:org.apache.commons.io:2.4'
compile 'org.apache.commons:commons-collections4:4.0'
}
When I run aapt dump badging I see:
native-code: 'commons-io-2.4.jar'
Clearly commons-io is not native code but the Android Gradle plugin thinks it is. How can I tell the Android Gradle plugin this library does not contain native code? Also curious how did it decide what architecture this library is? It seems to have picked some variety of arm since the APK won't install on a intel-based Android emulator, it gives the error: INSTALL_FAILED_CPU_ABI_INCOMPATIBLE.

You may be using the incorrect Commons IO library. Try:
http://mvnrepository.com/artifact/commons-io/commons-io/2.4
The version you're using seems to be specific to Apache Directory Studio 2.4 which seems to be a desktop app.

I once had troubles introducing a dependency on commons-io:2.4 into my build code. The problem is that Gradle itself comes with a version of commons-io. In my case it could be fixed with this:
sourceSets {
main {
compileClasspath = configurations.compile.minus files("$gradle.gradleHomeDir/lib/commons-io-1.4.jar")
}
}
I took this snippet from My Gradle project depends on commons-io 2.4, but Gradle puts $GRADLE_HOME/commons-io-1.4.jar into the classpath, causing failures
But be aware that it is not recommended to use different versions of libraries to come with Gradle.
You can find more information about this here: https://discuss.gradle.org/t/unable-to-use-commons-io-2-4-because-gradle-forces-the-loading-of-commons-io-1-4/8021
This might aswell be completely unrelated :)

How to use forked git project in Android Studio

I am switching from Eclipse to Android Studio. I have couple of 3rd party libraries that I have added features or modified a little bit. Since the libraries in Eclipse are also projects and we can access the code, I had no problem.
In Android Studio compile tag in dependencies is great but in my case I cannot use it unfortunately.
I fork the project and made necessary changes and add the project as a module in Android Studio. Since the library project already has settings.gradle and example and library modules, there is a mess in my project and it does not compile at all.
Has anybody experienced such a problem? What to do and what is the correct way to forked libraries?

What we've done in my project is create gradle scripts for our dependencies that don't have them, and modify the gradle scripts for dependencies that do have them. Gradle does not play very well with modular dependencies, unfortunately: Each sub-project must know its place in the larger overall project. Since you've already forked the github project, modifying it further shouldn't be a problem.