Android Studio is a new IDE that Google has released into Early Access Preview. It is based on the popular IntelliJ editor; the existing development environment relied on an Eclipse plugin.
This was really exciting news for SEP engineers that have done Android development. In addition to more the powerful refactoring tools that come with IntelliJ, Android Studio had the kind of tight integration that you would expect from a specialized IDE – things like a much improved UI designer and automation of tedious tasks like generating string resources. Android Studio also went hand-in-hand with a change to the build system, from Ant to Gradle.
Sadly, Android Studio is not ready for primetime, at least on SEP projects as of October 2013. Obviously, one expects some issues with a tool that is still in alpha, but there are too many things to overcome for us to start using it on client projects.
The main complaints are centered around testing, which is not given the same amount of attention as other platforms. The official way to test Android applications relies on running essentially Selenium-style automated tests on the emulator (or plugged-in device). As you might guess, these Instrumentation tests are slow and brittle. They make TDD nearly impossible and often fail intermittently on the build server (which leads to a lack of trust that a failing build means something is broken). Thankfully, an open source project called Robolectric has emerged as a very viable alternative. By allowing you to run unit tests on your local JVM (instead of the emulator or a device), everything is fast and we have much better control over the execution of the code (we can call methods directly, instead of being limited to saying “touch this button”). Big win, right?
Support for Robolectric is not built into Android Studio, instead you are left to try piecing together various open-source Gradle plugins or snippets from StackOverflow. But, with enough time and patience, you can get the Robolectric tests running…you just have to run them from the command line and view the results in a local HTML file. Not great, but maybe workable? Unfortunately, I was not able to get a project that used Robolectric to play nicely when we also wanted to use Android’s Instrumentation tests. Ideally, we want to write happy path feature-level tests that perform user actions on the actual emulator and then lots of fast unit tests to handle the edge cases.
Much of the trouble with Android Studio stems from the move to Gradle. Gradle has it’s own build settings for usage on the command line, which are kept in sync with Android Studio’s settings. So when you make a change to a Gradle config file, Android Studio makes the appropriate changes in it’s own internal representation of your project. At least that is the theory…in practice, not everything is fully wired up yet. You can get some aspects working by tweaking settings in the IDE, only from them to be wiped out when the project runs any Gradle commands. This puts us in a very frustrating situation where, e.g. Robolectric tests work fine when run from the Gradle command line, but Android Studio cannot even detect that the library exists (so no autocomplete support or ability to use the debugger).
You can try many of the work-arounds online (most of which involve “tricking” Android Studio into thinking your Robolectric tests are really Instrumentation tests and then not running them from the IDE) – but every approach we tried got us 90% of the way there before hitting a brick wall.
So how can you achieve The Holy Grail of running fast unit tests and happy path instrumentation tests? Surprisingly, it was easy in Eclipse.
We ended up with a project structure that had three Eclipse projects. One for the application code, one for Instrumentation tests (setup with the built-in Eclipse “Add new Android Test Project”), and one for Robolectric tests (following this guide). Instead of trying to use Gradle or Maven, we decided it made more sense to just use JARs for external libraries – instead of including them as part of the build process. Everything works correctly without any hacky workarounds and both test suites can be run, debugged, and report results all through the IDE. As uncool as Eclipse is, at least it works!
I am very excited about the future of Android Studio (and Gradle!), but until a few more revisions have been released, I cannot recommend using it for serious projects that value practices like testing. If you are just throwing together a sample app to get a feel for Android, by all means give Android Studio a go – the initial setup process and overall usage out-of-the-box beats Eclipse.
But if you are trying to ship a professional, production Android application – Eclipse is your only option for now.
