I too am satisfied with Eclipse for Android development. It does what I need and I'd like to stay with it for a while longer.

Android Studio is fanciful, I used it for months during the beta. There is one gotcha which leads me to prefer Eclipse. In Eclipse, the compile process is much more integrated with the IDE. The compile step appears to happen inside the IDE app/process tree/whatever. In JetBrains, the compile process is a separate process, much more disconnected from the IDE. Hence JetBrains takes more memory and is slower and running a project build and getting errors back into the IDE. I can appreciate an external build process being flexible for Jetbrains to use their IDE with nearly any language/compiler, but Eclipse worked much faster overall on a 4GB ram setup.

You're right. This is also a problem with Eclipse over the IntelliJ toolchain, in general.

Eclipse has it's own compiler and it uses that to build from within the IDE. Since this is not using Javac, it means that you might and very likely will not have equivalent binaries. Not specific to Android, but this also meant that when a new version of Java is released, IntelliJ can immediately take advantage, but you will be stuck waiting on Eclipse (and NetBeans).

Personally, I prefer the IntrlliJ approach since the IDE, javac on my workstation, and javac on the build server can output identical binaries, I trust the results even more so.

My understanding has always been that you can have Eclipse invoke an external build. However, if you use its compiler you do get quite a few niceties. Largest being that it can let you debug partially broken code. (You just can't call a method that was unable to compile.)

Also, if I am not mistaken, IDEA has its own compiler, as well. It just doesn't emit bytecode.

I only tried Android Studio a bit, but I had a similar impression. Eclipse for Android works very well. I'm already familiar with Eclipse.

Are you doing something really specific with the build tool? What testing tools do you use? Do you use the NDK?

Gradle covers the 80% use case really well. Everyone new to Android should use Studio + Gradle, no question. Dependencies are a breeze, the integration between Gradle & Studio is wonderful, the syntax is super simple, and the plugin handles most things by default pretty well. There are several things like build variants & package name interpolation that were impossible with Ant, difficult with Maven, and are trivial with Gradle.

The intermediate level stuff is more of a mixed bag. Some tests work well with Gradle, others (like Robolectric) are more of a pain. The NDK support isn't worked out yet. Some of the more fringe plugins like code coverage and formatting aren't plugged in yet. Here you will probably have to understand a bit about Gradle, but the tools team is making progress fixing the issues. What was a problem 2 months ago just works out of the box today with no Gradle specific knowledge.

For advanced things like writing your own plugins, then you have to know the respective build system. I don't know Maven well enough to write my own plugins. I have written a couple Gradle plugins. I have one that uploads APKs at the end of the build to various distribution APIs, one for secure signing, and one for bumping the versions whenever I want to. It was pretty straightforward to figure out.

No, I wouldn't say I'm doing anything specific. No on NDK. It's simply that Eclipse/Maven serve me well (I'm even able to create/run Android unit tests with the android-maven-plugin). In short, so far my entire workflow is well-served by Eclipse/Maven.

I'd concede that Studio/Gradle is the future, and that Gradle is more powerful than Maven; my "issues" are purely emotional :) With all that there is to learn and explore in this world, I don't want to have to spend time on another Java build tool when I already know 2 good ones (Ant and Maven).

Totally understand the sentiment, but given Gradle's rising popularity, it will probably be difficult for us Java (and especially Android) devs to avoid it. Might as well give in and pick it up now.

It already works for simple builds. It's a bit harder if you have many MK files for various libraries. I migrated my Cocos2d-X game to Gradle a while ago and I could only solve the problem through a gradle exec task. Still, the build is already much saner than the Maven version. I just wish they would give the NDK more attention, because the problem exists for well over a year.

Its only a build tool. Maybe Maven has damaged you and you expect a build tool to require a significant time investment.

The Gradle documentation is 66 chapters [1].

Sixty-six.

I would certainly not call Gradle easy nor fast to learn.

[1] https://www.gradle.org/docs/current/userguide/userguide.html

That's a feature not a bug. Gradle has phenomenally good documentation. I wish Google kept that level of documentation up for their plugin, or for any part of Android in general. Large swaths of the Gradle user guide are not applicable to the Android plugin because they are for other language specific plugins. The core of the user guide is only a few chapters long and well worth reading.

The Android specific ones are here:

* http://developer.android.com/tools/building/configuring-grad...

* http://tools.android.com/tech-docs/new-build-system/user-gui...

I was actually excited when I saw the size of the documentation. I really was, and I read it several times over the year.

And then one day, I realized that the web site that I always get back to in order to fix my build files is Stack Overflow, not gradle.org.

The fact that the documentation is so big is an issue, not a feature, because at this size, it's just too big to navigate, contains extreme amounts of redundancies between sections and basically, is not usable in this form.

You know your tool has a problem when the only way to fix problems is to search Stack Overflow.

This. Like most folks here, I like learning new things. I learned Ant a long time ago, and then Maven (to GP's point, learning Maven was NOT trivial). When I started through the Gradle docs and realized that it's a DSL written in Groovy, I had to open a new tab in my browser and start learning Groovy. Now I'm thinking to myself: "Great. In order to really grok Android Studio, I need to learn Gradle. To grok Gradle, I need to learn Groovy." As I mentioned in a previous comment, with all there is in this life to learn, I just can't bring myself to learn Gradle when I already know 2 other Java build tools :)

You're quite right to avoid learning Groovy, especially with its lack of documentation, but Gradle doesn't really use Groovy. It bundles Groovy, and the Gradle build scripts you write are parsed as Groovy code, but typical build scripts only use a small subset of the gigantic Groovy grammar. I've yet to see an open source project's build script, even Groovy's itself, that drops out of the Gradle DSL syntax to do something procedural using Groovy. The whole point of Ant, Maven, etc is to do build declaratively instead of procedurally. In the small number of instances where you do need to, you're better off using Java or any other JVM language you want to configure the build via the Gradle API.

Not only that, but I suspect Gradle won't use Groovy to parse the build scripts for much longer. Those scripts conform to a rough CSS-style syntax that Gradleware could easily replace with their own custom lightweight parser calling Java 8 lambdas. Given that they replaced virtually all the Groovy in their codebase with Java when they upgraded to Gradle 2.0, the next logical step is to eliminate dependence of the Groovy parser as soon as they can.

Gradle documentation is 66, but Android's gradle plugin is only a subset. Plus, gradle _is_ simple and easy to use in the standard scenario of a run-of-the-mill Android app.

It's when your app becomes more complicated (product flavor's for example), that you need to read and understand the gradle documentation. If this is the case, then you are not a novice and 66 chapters of docs is a blessing not a curse.

and Again _the Android gradle plug-in only supports a subset of gradle_!

I was under the impression that the "Android Gradle plugin" is a plugin to extend Gradle's behavior? So really you're dealing with 66 chapters plus Google's wildly-insufficient Android-plugin documentation.

Maybe XML has damaged me, but I am quite happy with Ant and Maven.

FWIW: I'm assuming this intel-j based apps, like phpStorm will have emacs key binding. Not emacs obviously but it works pretty well.