Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development

The Android Developer Experience

The Software

The OS version shipping on the developer G1 that I received was an unlocked Nov 3 1.0 build running the Linux 2.6.25 kernel. While this first generation version is a remarkable achievement for the Android team, there are unsurprisingly a few rough edges. I've read Android reviews stating how stable it is and how it's nearly crash-proof. That didn't turn out to be the case for me. I had the OS unexpectedly and forcibly reboot on me several times, most often when using Android's Music application and listening to MP3 file playback.

There is also the fact that the Android designers took the iPhone approach of masking the underlying file system such that files, even those being stored on the microSD card, cannot be easily accessed and manipulated from a standard file management/browser approach using the standard application set. Instead, a visit to the Android Market is necessary to more easily access the file system when un-tethered from the host development environment. The two I found most helpful are a third-party simple file browser called OI File Manager, and Google's own Terminal shell program. On consumer G1 models, the Terminal program isn't very helpful since root access is locked, but on the developer G1 model, root access is helpful, even a necessity at times. Since the version of OI File Manager I used can only affect a single file at a time, I more frequently call upon the Terminal program to perform most of my file manipulation.

Figure 3: The Google Terminal Android application running on the G1 with root level access.

Figure 4: Screen capture of the Terminal application running on the G1, grabbed using Android's ddms developer debugging tool.

More importantly, the Terminal helped me alleviate one of the most painful design oversights of the Android Market and various Google applications like the Maps and Browser. This ravenous storage eater is the current version's inability to have these standard applications store their downloaded data caches on the microSD card and not the main onboard memory of the device. Googling for Android Market and cache together will yield a litany of angry complaint links from end users and developers alike of how their G1's are rapidly exhausted of memory as a result of these two applications lacking such an obvious feature.

As of this writing, the Android team is working on an update to the Android OS, codenamed "Cupcake", that is expected to fix this glaring oversight as well as add new features such as stereo Bluetooth (known as A2DP) support and a few other nice enhancements. In the meantime, hard-pressed developers equipped with the Terminal program have come up with a very easy Unix-like solution to the cache problem. After downloading and installing the Terminal application from the Android Market, launch it, su to root and create a new directory called /sdcard/marketcache (this can be named anything, and even reside in a deeper subdirectory). Navigate to the /data/data/com.android.vending directory, delete the cache folder located there (rm -R cache) and create a symlink to a new cache folder location on the microSD card (in this example, execute ln -s /sdcard/marketcache cache as root). This caching issue is a problem not just with the Android Market app, but several others as well, including the Browser, Maps and even some third-party Android programs that prefer to keep cached data on the device instead of providing an option to store locally cached data on removable storage. Because this is such a prevalent problem, community contributors at modmygphone.com have created a wiki entry outlining the steps needed to alleviate the cached storage constraints with various Android applications. Visit modmygphone.com/wiki/index.php/Caches_To_SD_Card for details. Note that because these cache relocations require root level access, they can only be performed easily on the developer G1 models. End consumers will either have to hold out for Cupcake, cold reset their devices to clear out the cache (and everything else they had installed) or embolden themselves with attempting to unlock the commercial G1 handset on their own and possibly bricking the phone in the process.

If you prefer not to mess with the file system and want to minimize the cache size, you do have another option. Developer Jay Freeman has created an Android Market front end at cyrket.com that anyone can visit with a web browser. This helpful site also allows non-Android owners to see what the Android Market has to offer. As long as Jay keeps cyrket.com alive, I will continue to visit it first before perusing the latest market updates via the Android Market application.

The Development Environment

Setting up the optimal configuration for Android development is a fairly easy process that takes less than 15 minutes, not including download time for the software. The Sun JDK 1.5 or higher is an obvious initial requirement to run both the Eclipse IDE and the Android Developer Toolkit (ADT) plug-in set. I chose to use the latest 1.6 release. Once the JDK version requirement is met, download and install the Eclipse IDE. The nice thing about Android development is that it can be performed on Windows, Mac, or Linux, the same platforms that Eclipse runs on. Any Eclipse version 3.2 or higher will do. I chose the latest 3.4.1 Ganymede release. While the Eclipse IDE isn't absolutely essential, the Android team has written the ADT exclusively for the Eclipse environment that makes launching and managing the Android emulator much easier. There are reports of some brave attempts to wire up these pieces within Sun's own NetBeans IDE, but unless there is some serious aversion to Eclipse, this effort appears to be more trouble than it's worth.

Next, download and install the Android SDK. This can be installed anywhere as long as the Eclipse plug-ins can consistent locate the installation path. Finally, launch Eclipse and grab the ADT via the usual Eclipse plug-in install route. Select "Software Updates" from the Eclipse "Help" menu, click on the "Available Software" tab, then the "Add Site" button and enter the location of the ADT. Restart Eclipse and enter the installation path of the Android SDK in the Window --> Preferences --> Android dialog box.

Windows and Mac users should be ready to go, but Linux 64-bit users will need to ensure they have the 32-bit emulation libraries (ia32-libs) installed; otherwise the proprietary, closed source emulator compiled in 32-bit code for the Linux environment will fail to run on that 64-bit host.

Check to make sure everything is correctly configured by launching Eclipse, importing the APIDemos project from the Android SDK demo folder and running it. Doing so should launch the emulator and, once confirmed running (initial instances take between 30 seconds and a minute depending on host computing resources), select Run. This will compile the the project's source code and various resources into a single Android package called an "apk" file, download and instantiate APIDemo in the emulator. Fortunately, subsequent Android runs will occur much faster as long as the emulator is allowed to keep running in the background.

Figure 5: The Android emulator running the ApiDemos sample application.

The emulator itself is for the most part an accurate reflection of a real Android device like the G1. Unfortunately, the emulator used during the writing of this article could not emulate the sensors or radios such as the accelerometer or GPS. However, the aforementioned folks at OpenIntents have created a helpful alternative to help simulate such inputs at the cost of modifying an Android project's code to get it to talk to OpenIntent's Sensor Simulator. However, I suspect that if the development community clamors loudly enough, the Android SDK team will respond with such capabilities built into future SDK releases.

Once acclimated to the emulated environment, it's time to test sending applications to the actual G1. Windows users first need to download and install the Android USB Windows driver. Linux users have more work to do. A rule has to be added to the host computer (example, for Ubuntu Hardy users, a new file needs to be created at /etc/udev/rules.d/50-android.rules containing the following: SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666". Once saved, chmod a+rx the file and the host computer should be able to identify and communicate with the Android device when plugged in via the USB port. Mac users fortunately do not have to mess with any drivers or settings, as the Android SDK tools and Eclipse environment will automatically recognize the device. As Google's SDK installation documentation boasts, "it just works." And they're right -- it does.

The Android plug-ins will automatically assist Eclipse in targeting the attached device and download and run the desired apk accordingly. Simple.

Figure 6: The G1 running the ApiDemos sample application, downloaded and instantiated from the ADK Eclipse plug-ins.

With both the emulator and device successfully receiving and running the API demo, you're ready to start writing your own Android applications.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.