Thoughts on Android Studio


If you follow Android you will probably already know Google deprecated Eclipse and Android Studio is now the recommended IDE for Android development. I migrated all of my current clients’ projects last December. I hadn’t previously migrated them as I have a policy of not using beta tools on client projects – more to conserve development time as opposed to avoid introducing problems. I had used Android Studio, as a learning exercise, for some simple personal projects but had held back writing about the problems until v1.0 shipped and I had more experience of using Android Studio across several client projects. I am at that point now so here are my latest impressions.

The Good

  • First of all and importantly, it’s very easy to import Eclipse based projects.
  • IntelliJ IDEA has far superior code completion. It’s a lot quicker to code when you don’t have to go to other files/places to determine APIs and constants. It also seems to be very intelligent at offering a sorted list of the most likely code completions with the most likely first.
  • It’s good to now be able to easily create custom variants of apps via Gradle.
The Bad
  • It has poor NDK support for non-trivial NDK builds. You end up having to not use the built in Android Studio support for the NDK and instead configure Gradle to do a separate NDK build. This makes using NDK code less integrated and less visible in the IDE than it was with Eclipse. One of my client projects makes extensive use of the NDK so this issue is a larger problem for me.
  • Unlike Eclipse, you can’t have more than one project (that generates an apk) open at once thus making switching between projects inconvenient. To be fair, there’s less need to switch between projects now that it’s easier to have build variants.
  • Some run configuration parameters aren’t persistent between successive Android Studio sessions. Specifically, if a particular device is selected for debugging this isn’t saved between Android Studio invocations. You will be asked again next time.
  • There are still some bugs in frequently used features. For example, on loading an existing project, some projects refuse to see the ‘app’ part of the project until there has been a Gradle sync.
  • Unlike Eclipse, Android Studio doesn’t ‘compile as you go’ to produce issues in the ‘problems’ tab. Instead you have to build to see problems. This is a backward step. There’s a 3rd party plugin that enables auto-compilation if you dare (it hasn’t been updated for a long long while).

The integration with ADB is poorer than with Eclipse…

  • The logcat Window seems to periodically stop working and ends up in another logcat Window somewhere deep in the Android DDMS Window hierarchy. If you have multiple monitors and are used to dragging the logcat window out to a separate screen you will soon be frustrated when the logcat stops and ends up coming out in some other window. I’d say this is the most annoying problem of all.
  • There’s no ADB file explorer. You can now use the separate ‘Android Monitor’ application that gives essentially what you had under Eclipse. However, using this cuts off the ADB connection in Android Studio as only one thing can have a debug connection at any one time.
  • Selecting Stop doesn’t kill the app being debugged. You have to manually do this via the device Android task manager (or use ‘adb shell am force-stop <packagename>’ for Honeycomb and above).

Unfortunately, there’s more bad than good. As ex-Googler Jean-Baptiste Queru said yesterday "Working with Google tools: there’s the one that’s deprecated (Eclipse ADT) and the one that’s not ready yet (Android Studio)."

If you are interested in the ‘Present and the Future of Developer Tools for Android’ you might also like to read a very recent interview with Tor Norbye.