IssueTracker

can you share your android studio version

Is this happening with Studio 3.0?

Note: This worked for me on Windows 7 Pro 32-bit (with Android Studio 2.3.3). Seems like an issue with adt-branding module (which should contain the "/idea/AndroidStudioApplicationInfo.xml" resource).

Hi, also happened on Mac Book Pro 15 retina mi-2015
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

Thank you for this feedback. Your feedback helps make sure Android development tools are great! Given your issues has been resolved I am closing this issue.

Yes, I also think this is important. I had a short chat with Xavier on G+ already:

https://plus.google.com/u/0/117307683192872253846/posts/X1VXFtSBme9

Here's a sample project to test this issue:

https://github.com/dhelleberg/GradleBuildSampleApp

Here is a gradle android plugin that supported scala.  It has been discontinued.  Please incorporate it.
 https://github.com/jvoegele/gradle-android-plugin

That plugin does things very differently. I cannot be "incorporated", as it just wouldn't work. It's not a matter of doing a bit of work to make it happen. Major changes need to happen inside Gradle itself. It's a work in progress and we'll get there soon.

Also, we do not go in and grab other people's work to put it in our tools. It would have to be contributed by the author.

To add to what Xavier said, the Gradle Android plugin that was developed as a community effort was entirely built around interfacing with the command line tools, which is extremely brittle. Interfacing with the CLI is possibly the worst extension point to choose from (in contrast, the maven plugin uses the DDMS JAR.)

Regardless, I think reaching interface parity with the Java plugin is important, and it's good to hear that the tools team is aware of this and working toward a solution.

Thank you for working on this.  

In the meantime I might be able to work around it by having a scala module that produces a jar, then have an android module that consumes it and has the AndroidManifest, resources, etc.

I also need to run JUnit tests with Robolectric and Scala.

what about this : http://sethrylan.org/2013/07/14/gradle-android-findbugs.html ,  but I meet some problem : findbugs cannnot success complied ,  pmd & checkestyle works, but there is no result in the report file .  

Thank you very much for working on this issue!

Any updates on this ?

I think there is a fundamental misunderstanding here: The 'java' plugin is an opinionated plugin which prescribes that there is a main and a test sourceSet and that the project builds one jar. This just does not apply to Android projects.

The plugin you are looking for is called 'java-base', which introduces the concept of sourceSets without any opinion on which sourceSets you should have. The Android plugins extend the 'java-base' plugin and add a sourceSet for each flavor.

The problem is not with Android, but with the other plugins which have a hard dependency on the 'java' plugin. They should instead depend on the 'java-base' plugin.

In my opinion, this issue should be closed. Instead, users should open issues for the plugins that depend on 'java' instead of the more flexible 'java-base'.

Gradle core plugins like checkstyle, findbugs and pmd already integrate with the 'java-base' plugin, so they should work just fine.

Correcting my statement above: The Android plugin has its own sourceSet concept and does not populate the sourceSet collection of the java-base plugin. This is probably because the Android plugin wants to pick the compiler itself, while java-base always creates a javac task.

So applying a plugin like 'checkstyle' will do nothing by default. But it would be very simple to build an android-checkstyle roughly like this (untested pseudo code, just looking at the APIs ;):


apply plugin: 'checkstyle'

android.variants.all { variant ->
  task "checkstyle${variant.capitalize()}"(type: Checkstyle) {
    source variant.javaCompiler.source
    classpath variant.javaCompiler.classpath
  }
}

So I still stand by my comment that this is not a problem with Android. Plugins that want to support Android will have to build a small wrapper like I just demonstrated with checkstyle. I did the same for the Xtext Gradle plugin too. It has a variant that integrates with 'java' and one that integrates with Android. They share 95% of their code.

Please don't invade this issue and suggest it should be closed WNF. We don't care what line of code gets changed, but if Google is interested in having a dev environment that doesn't make us tear our hair out they should find a way. We don't care if they find a proper way to get it done in the Android plugin or they make commits to the repos for these other plugins.

Modular, componentized platforms seem fantastic from an engineering perspective but those of us that have to use them the "pass the bug" mindset doesn't get us any closer to getting our work done.

actually the last comment was made by a Gradle employee, not a Google employee. Having said that, I agree with what Stefan says.

Although we would love to fix this, it really is difficult to go and fix other plugin code on the fly.

"Really difficult" isn't a good reason to close a bug. If you think it'll be hard, imagine how hard it's going to be for us to resolve these issues.

Yes I realize who made the comment.

For the record, there already is such a "wrapper plugin" that makes Findbugs, Checkstyle and PMD work with Android projects: https://github.com/dlabs/soter