The Android platform provides a great way to deliver rich and highly functional native mobile applications to an ever growing number of smartphone and tablet devices, and soon even your TV. With this platform comes a rich set of development tools, primarily based around the Eclipse development environment, but which also includes command line tools for packaging, installing, and debugging Android applications, as well as helper tasks for Apache Ant which is used for build automation for many enterprise Java projects.

Most development teams working on complex projects in this day and age are going to employ some combination of generally accepted best practices in software engineering to ensure consistency in build quality, automate complex build processes, and automate unit and functional testing to continually ensure quality as development progresses.  Such practices include:

• Automated unit, integration, and functional testing (faciliated by tools such as JUnit and Selenium)
• Build automation (using tools like Ant and Maven)
• Continuous build integration (to ensure build quality and identify conflicts early)
• Code coverage analysis (measuring how much of your application you’ve tested)
• Static code analysis (find common coding errors with tools such as FindBugs)

It is reasonable to assume that a complex Android application would benefit from these practices, especially with a larger development team.

Android provides most of the necessary integration points and tools to implement many of the best practices mentioned above, and allows for automating the several steps required to build an Android application.  However, despite this, there are some key lessons to learn that to learn that separate an Android build process from other Java-based projects.

Java is not Java

First off, let’s get one thing straight.  The Java classes that one writes to implement an Android application compile to the Dalvik VM, not the Java Virtual Machine provided by Sun (now Oracle).  The engineers building the Android platform chose a separate virtual machine implementation for a variety of reasons, but it is arguably the need to slim down and tailor a VM for use on a mobile device, which has very hard limitations on processor resources and memory, that lead to this decision.

Because of the separate VM implementation, the full set of standard Java SE classes is not available.  The Android team has provided a workable subset of the Java SE API with a few notable additions to assist in such things as managing HTTP communication, parsing JSON, and parsing XML.  This distinction leads to one very important point:

Not all Java targeted for the Sun JVM will run in Android.

This is important to note when planning to use 3rd party libraries in an Android application that were not targeted for Android.  While many 3rd party JARs can be included in Android projects, many cannot.  Clearly if the dependencies can be met with the pared down API, the JAR will not work.

Running It

The APIs provided by Android’s augmented subset of the Java SE API are exposed to developer projects (primarily in Eclipse) via the android.jar file.  This JAR provides the interfaces for the Android API, but none of the implementation code.

Why the limitation?

Classes compiled for the Dalvik VM aren’t executed in their .class file bytecode form, but rather must be converted to Dalvik’s Executable format, or dex.  According to this Android page, dex is optimized for a smaller memory footprint, and also to allow multiple VMs to execute efficiently.

What this means for the average developer is that you cannot go to your trusty Eclipse Run As > JUnit Test menu item and fire off unit tests.  All Java code targeted for Android must run within the Android execution environment, compiled as .dex files, in the Dalvik VM.  Without the implementation classes for android.jar being in standard JAR format (they’re buried in .dex files in Android), the best options for running your code during development is either:

• Plugging in your favorite Android phone via USB debugging or
• Running your code in an Android emulator

While there are ways to run the Dalvik VM on the desktop, those methods are not yet integrated into the Android standard toolchain.

Emulating Success

The Android SDK provides a rich set of tools for creating, launching, customizing, and debugging emulated Android devices, known as Android Virtual Devices (AVDs).  These emulator instances can model different hardware configurations as well as different target Android OS versions, which is useful for testing an application across the many deployed versions of Android that exist on the many Android devices that exist today.

The Android emulator, based on QEMU, provides emulated versions of many of the hardware features commonly found on Android devices (from the Android Developer Center):

• An ARMv5 CPU and the corresponding memory-management unit (MMU)
• A 16-bit LCD display
• One or more keyboards (a Qwerty-based keyboard and associated Dpad/Phone buttons)
• A sound chip with output and input capabilities
• Flash memory partitions (emulated through disk image files on the development machine)
• A GSM modem, including a simulated SIM Card

The slowness is evident elsewhere.  It is a generally held belief that the emulator does not adequately support video playback, and my experience in building custom video players in Android supports this.  Playback often does not come close to the video frame rate, therefore video playback testing is best handled on a physical device via USB debugging.  Given that it is difficult to automate testing around video playback, this is less of a concern, however it is important to note when setting up a QA team for playback testing.  Real devices should be available for QA as the emulator will likely not suffice.

Up Next

This is just a taste of some of the relevant architectural details of the Android platform that affect build automation.  In the next installment, I’ll dig deeper into build configuration, automating tests and managing the emulator from Ant.