I have a project which has had checkstyle configured and working for a long time, but now it's suddenly complaining of
[ant:checkstyle] C:\foo.java:23: Missing a Javadoc comment.
for every file.
It's correct that we are missing it, but the rules weren't supposed to be checking that and previously hadn't been.
Checked and tried:
Tried re-configuring the "Javadoc" modules in checkstyle.xml, but it get's automatically overwritten as soon as I attempt to build again.
Deleting the whole config directory containing the checkstyle.xml file, and it get's automatically recreated.
Verified there is absolutely no reference to checkstyle in the build.gradle file
Tried specifically including a blank checkstyle field to build.gradle, still same error
checkstyle {
sourceSets = []
}
What could I be missing?
Using Android Studio 1.4 - 1.5.1
Found it.
Though I wasn't directly including checkstyle, I had a line
apply from: 'http://apps.tapadoo.com/quality/quality.gradle'
which contains all the lint configuration, including checkstyle.
Related
I'm configuring an Android multi-module Gradle project that uses Kotlin for both the app AND the Gradle build files (gradle.build.kts).
I'm using Gradle 7.3.3.
First I add the Jacoco plugin to the module-level build.gradle.kts:
...
plugins {
...
jacoco
}
...
Then I click the icon in Android Studio to "sync project with gradle files."
Next, I find the debug build type and add this:
isTestCoverageEnabled = true
When I subsequently run ./gradlew testDebugUnitTest, a file is generated in the module at <MODULE>/build/outputs/unit_test_code_coverage/debugUnitTest/testDebugUnitTest.exec.
If, however, I don't add the line isTestCoverageEnabled = true, or if I set isTestCoverageEnabled = false, a coverage results file is generated in the module at <MODULE>/build/jacoco/testDebugUnitTest.exec.
When I generate each .exec file's HTML report, the "Total" rows at the bottom have matching counts.
Are these two files equivalent, but just located in different directories depending on the value of isTestCoverageEnabled?
If so, it seems that, as long as jacoco is included in the plugins, coverage results are generated regardless of whether the isTestCoverageEnabled = true line is added. Does isTestCoverageEnabled do anything else besides change the output directory? What am I missing?
I have struggled with this issue for 3 years across multiple projects, but I have a solution (or rather someone who resolved my issues).
The Android-Root-Coverage-Plugin can be used to combine both jUnit and instrumented tests in a Java and/or Kotlin multi module project without any great need to configure anything else. It resolved my following issues:
Getting coverage in multi module project
Incorrect coverage in Kotlin
Combining both jUnit & Instrumented test coverage
It has been confirmed that the cause of my issues were due to a bug in the android gradle plugin and as of Aug, 2022 it has yet to be resolved.
Specific to your question, isTestCoverageEnabled is used to configure the embedded JaCoCo in the android gradle plugin, which as stated above, is known to be buggy. Using the JaCoCo plugin can be configured in the gradle file but does not utilise the embedded JaCoCo in AGP
In recent release of our library we decided to add some kotlin-dsl features to our build, though for now we've added buildSrc build.gradle.kts and Dependencies.kts file containing libraries versions for easier use across all modules.
The problem is that this version builds successfuly on jitpack, but downloaded jars are empty. How do I fix this? Also all the resource files are present. The build log file also differs much from previous ones.
Problematic build log file
Working build log file
A link to library on jitpack: https://jitpack.io/#netigenkluzowicz/api_android
Github link
branch to reproduce these build problems is feature/kotlin, we're working to fix it on fix/jitpack-build branch
To Reproduce
Add this dependency to an Android project, sync and check classes.jars
implementation 'com.github.netigenkluzowicz:api_android:2.4.1'
What we did before this problem started to occur:
Added buildSrc directory with build.gradle.kts and Dependencies.kts.
We also extracted android { } block from our modules build.gradle files, it is now applied from android.gradle file.
I've already went through jitpack issues on github, all I found so far are build errors with kotlin-dsl from late 2018. Was following this guide to make a use of kotlin-dsl, though due to having issues with android { } block I didn't migrate all of our gradle files.
I am trying to convert my Android app to JAR.
While clicking the build option in the GRADLE toolbar, it shows this error:
Fix the issues identified by lint or add the following to your build script to proceed with errors:
...
android {
lintOptions {
abortOnError false
}
}
Now I added these lines to my build.gradle but JAR has not been created and not showing any errors too. Pls help
try using the creteFullJarDebug or createFullJarRelease that are located in the other on the same tab
Apparently, there is a bug with fetching lintOptions. Maybe your problem is related to that. Try to change the order of repositories, move google() to the top in your project gradle and app gradle(if it exists) as well.
When I try to run my android application on an Android device, the gradle console reports the following error:
Error:Execution failed for task ':app:transformClassesWithJarMergingForDebug'.
> com.android.build.api.transform.TransformException: java.util.zip.ZipException: duplicate entry: com/loopj/android/http/AsyncHttpClient$1.class
When I search for the "AsyncHttpClient" class, I see that it's indeed being found in two separate locations:
/Users/Afflatus/.gradle/caches/modules-2/files-2.1/com.loopj.android/android-async-http/1.4.9/5d171c3cd5343e5997f974561abed21442273fd1/android-async-http-1.4.9-sources.jar!/com/loopj/android/http/AsyncHttpClient.java
/Users/Afflatus/.ideaLibSources/android-async-http-1.4.9-sources.jar!/com/loopj/android/http/AsyncHttpClient.java
The first path seems to suggest it's a "cache" file... so I've tried invalidating & restarting my cache, but both files are still there after the gradle gets rebuilt and I try to run the application. I've read in alternate posts that it can be resolved by deleting one of the files... So I went to the cache location and deleted all the files found in the "1.4.9" folder... unfortunantly after reopening Android Studio, a new cache file gets created and I get the same error.
Other posts (here, here,here, and here) suggest if I add "./gradlew clean" to the root directory it would rebuild the gradle again just for the run (as far as I understand). So I tried doing that as well:
Which made my app's folder look like this:
But unfortunantly, that didn't help things I still get the same error. What am I doing wrong? What should I be doing?
I added this line to my gradle.properties file and my app worked
android.enableJetifier=true
Sometimes duplicate classes exception means that one of your dependencies uses implicitly the older or newer (with +) version of some library you also use in your project,
To resolve this issue you may add such block of code (put your library version after 'force') to your build.gradle file (Module:app):
configurations {
all {
resolutionStrategy {
// do not upgrade above 3.12.0 to support API < 21 while server uses
// COMPATIBLE_TLS, or okhttp3 is used in project
force 'com.squareup.okhttp3:okhttp:3.12.0'
force 'com.squareup.okhttp3:logging-interceptor:3.12.0'
}
}
}
You may also exclude some group from your dependencies.
For a single dependency you way write:
dependencies {
// example
implementation('log4j:log4j:1.2.15') {
exclude group: 'javax.jms', module: 'jms'
}
}
Tested to work on Android Studio with Gradle Plugin version 3.4.2 and Gradle version 5.4.1.
Credits go to Dimitar Dimitrov and Schalk Cronjé from gradle org discussion group
That's because you have added some library two times in libs folder, this could happen sometimes when you have multiple versions of the same library in the libs folder. Check it and remove any duplicate jar files.
And the second option could be you have also added the dependency in gradle.build and also have a jar in libs folder.
So check both places and remove duplicate entries and then clean and build APK again.
Delete files with duplicate jar extensions in the libs folder. However, if there are no duplicate files and there is still a "Duplicate classes" error, look for the name in the rest of the "Duplicate classes ...." clause in the error section. For example, "duplicated classes 'dagger' bla bla". Delete the file named 'dagger' from the libs folder. (Be careful not to delete it with shift.)
In my case, I am using sensorocloud.jar and the compile 'com.loopj.android:android-async-http:1.4.9' in my gradle which caused the same error as yours. Because sensoro cloud SDK used loopj's async-http.
I managed to solve it by manually removing the duplicate .class files in the jar file. (i.e.
changing the extension from jar to zip
extract it
remove the com.loopj.android .class files)
(P.S. I have tried to search through the web to see if I could exclude certain class of a jar in gradle, but not succeed, e.g. I referenced this SO post)
This error can be caused by several things;
misconfigured package name
Activity views that is not well binded. - simply go to your launcher activity view and ensure context is defined well e.g "com.yourdomain.package"
Re-create your BuildConfig and set it up well.
Check if your project build.gradle. There it might be some maven duplicate dependency
Here's another situation that can cause duplicate class during the mergeDexClasses task. This can happen with later versions of android gradle.
If your build.gradle.kts script has a dependency in the form:
implementation(project(":mylib", configuration="default"))
that can cause duplicate classes. The correction is simple. Just change it to:
implemenation(project(:mylib"))
Here's the Android Studio's Team explanation:
Having both project(":lib") and project(path: ":lib", configuration: "default") in the runtime classpath means that AGP gets both build/classes/java/main and build/libs/lib.jar (run ./gradlew :lib:outgoingVariants --all to verify). Because paths differ, we'll get 2 dexing transforms happening: 1 incremental that produces dex per class under build/.transforms (the one processing dir) and another one which produces single dex (the one processing jar). Later on during merging this causes failure.
AGP never publishes to the default configuration, in fact java-library plugin does it only so it does not break older build scripts. Having an explicit configuration name used in the dependency declaration is discouraged and Gradle attributes should be used instead.
In an older version of AGP, I ran into a problem where adding the configuration value "default" fixed some issue I was having. Well that no longer works, and adding the "default" configuration you can get duplicate classes.
I'm trying to use Checkstyle on an Android project. I figured Googles java coding conventions would be good to use. I'm getting an error when parsing this file:
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
I've looked this error up on stack overflow and it has come up once before, How to compile project with Google Checkstyle rules with gradle?
It seems the error is an older version of checkstyle is pulled down when using gradle. So my question is, is there just an older checkstyle configuration file I can use that's made for the current version of checkstyle pulled down by gradle? Should I even be using Googles java guidelines for an Android project? Is there a better default file to work with? I really don't want to import a new version of checkstyle into my project as mentioned in the answer of the other SO question.
You should always specify the exact version of Checkstyle that you want to use. The Checkstyle guys often make breaking changes which would fail your build unless you set a specific fixed version. For example:
checkstyle {
configFile file('downloaded_google_checks.xml')
toolVersion '6.9' // set Checkstyle version here
showViolations = true
}
Then, you can also use the right configuration file for your version, for example: https://github.com/checkstyle/checkstyle/blob/checkstyle-6.9/src/main/resources/google_checks.xml. Note the version number in the URL - this can be adjusted to the version you selected in your Gradle config.
Do not use the latest configuration file from the master branch, as this matches the current code on the master branch (which is not released yet).
The above allows you to adjust the configuration as necessary. If you are certain that you want the original rule file, you may also follow #BenMane's suggestion from his comment, which is to reference the bundled google_checks.xml directly.