Develop Reference

Specify Android Lint version

How do I specify the version used for Android Lint? From the lint report: <issues format="5" by="lint 3.5.3">

Lint is a part of ADT(Android Development Tools) and more specifically it depends on the Android Gradle Plugin Version. You cannot change Lint version independently from gradlePluginVersion. When you change gradlePluginVersion, Lint version will be changed automatically to the corresponding one from current version of the plugin.
If you want to disable some checks or write your own rules you may check this. Also you may create your own 'Lint' modules using "com.android.tools.lint:lint-api:$lintApiVersion"
and "com.android.tools.lint:lint-checks:$lintApiVersion" compileOnly dependencies from here
Hope it helps

How does Gradle choose between more than 1 versions of the same library in a gradle tree?

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

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 Databinding build fail after Gradle plugin update with migration to annotationProcessor

To support Instant Run in my version of Android Studio, I needed to upgrade my Gradle plugin from version 2.2.3 to 2.3.3
I'm aware I'm supposed to migrate to annoationProcessor and I believe I've followed that guide correctly
after doing so, the Android DataBinding code generation fails
The migration guide linked earlier states that all I need is to
Make sure you are on the Android Gradle 2.2 plugin or newer
Remove the android-apt plugin from your build scripts
Change all apt, androidTestApt and testApt dependencies to their new format
This should be all that's needed to successfully build the project. Yet it doesn't build.
Build output
Gradle build finished with 101 error(s) and 23 warning(s) in 12s 481ms
All of the errors follow the same pattern:
C:\Users...\FooAdapter.java
error: package com.example.app.databinding does not exist
error: cannot find symbol class ItemFooBinding
An interesting message can be found in the build console:
Warning:The following options were not recognized by any processor: '[android.databinding.minApi, android.databinding.enableDebugLogs, android.databinding.sdkDir, android.databinding.bindingBuildFolder, android.databinding.enableForTests, android.databinding.modulePackage, android.databinding.generationalFileOutDir, android.databinding.xmlOutDir, android.databinding.artifactType, android.databinding.printEncodedErrors, android.databinding.isTestVariant]'
I would like to point out that...
I presume I don't have an error in some XML file, binding expression or a naming issue. The same set of sources and XML build when I switch back to the Git branch with the old gradle plugin version (and all of the other source files up-to-date)
I did increase the limit of output build errors as discussed here, although this doesn't seem to be relevant right now, since as you can see, I currently have "only" 101 errors. :)
Additional info
The following diffs show how I've modified my gradle files:
build.gradle DiffChecker link
app/build.gradle DiffChecker link
Also, as a quick overview, here is the list of some of the "more interesting" plugins & libraries used by the project:
Kotlin
Android DataBinding
Realm
Retrofit
Dagger
ButterKnife (I know...)
Multidex Support Library
Does anyone have a clue what could be the issue? Any help or idea will be greatly apprecitated!

I had exactly the same warning. This line in gradle solved the issue:
kapt "com.android.databinding:compiler:3.0.1"
Hopefully, it will help somebody
Update:
3.0.1 is Android Plugin Version.

When you see innumerable build errors mentioning databinding as in this case, the problem usually lies somewhere else. Databinding just gets stopped in its tracks by unrelated build problems and complains exceedingly loudly. The only way to deal with it is to locate the build errors that are not tied to databinding. Once they are fixed, databinding can do its thing again and be silent. Unfortunately you often have to repeat this approach several times until you have found all non-databinding issues. It's an arduous task for sure, but unfortunately there is nothing else you can do until Google manages to provide a saner build environment.
This is the reason why you are advised to increase the build error limit beyond 100 - you would not see the actual errors causing your problems, because they commonly do not show up early in the list.
I will chance a guess - Dagger 2 is a common source of triggering this problem, which could be related to your annotationProcessor change; so look out for Dagger errors. But your issues could be caused by other things, like other annotation processors as you mentioned - you wouldn't know for sure until you diligently dig through your build errors.

It seems it all comes down to my project using Kotlin. Actually we have it mixed: some classes use plain old Java while others are written in Kotlin. An incomplete migration. :)
I assume that without Kotlin, replacing apt with annotationProcessor would be enough and I wouldn't have ran into this issue at all.
Solution
Annotations need to be processed by both annotationProcessor and kapt, which seems to be Kotlin's own annotation processor.
For each Gradle dependency that uses annotations, you should have both of the following in your app-level build.gradle:
annotationProcessor 'com.example.my.library:x.y.z
kapt 'com.example.my.library:x.y.z

Android grade syntax and build tools compatibility issues

I didn’t work full-time with Android in the last couple of years, and now whenever I try to fork someone code on GitHub I get a lot of errors since android tools and Gradle syntax are changing frequently.
I wonder what is the best way to handle these changes, and be able to upgrade other GitHub projects and some of my old projects to work with the latest Android tools. Here are some of the things that I struggle with:
I noticed some of the issues are related to changes in the Gradle syntax. How can I know what Gradle version the build.grade syntax was written with? and then how to upgrade it to the current version (is there a migration guide for Gradle versions?).
Sometimes I get issues related to tools that are not compatible with others, how can I know which version are compatible with which? and whats the easy way to manage that? here are some of these tools:
Gradle
Android Plugin for Gradle
Build Tools
Android Studio

How can I know what Gradle version the build.grade syntax was written with?
If the project contains a gradle/wrapper/gradle-wrapper.properties file, that is the version of Gradle that the developer of the project is using.
is there a migration guide for Gradle versions?
I am not aware of much Gradle syntax that would have changed that would affect Android developers for garden-variety projects. Most of the changes are from the DSL added via the Gradle for Android plugin. You can find the version of the plugin that the project developer was using via the classpath statement in the project's top-level build.gradle file.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
}
}
The above snippet is requesting version 1.3.0 of the Gradle for Android plugin.
Migration documentation for the Gradle for Android plugin is minimal. What there is can be found up on http://tools.android.com.
how can I know which version are compatible with which?
Here is Google's statement on the issue, though this has not been updated in a few months.
and whats the easy way to manage that?
If the tools complain, change them to a set that you know is good (e.g., by copying values from a known-working project). If you need something that was introduced in a newer version of the tools, change them to a set that you know is good. Otherwise, don't worry about them.