Android Software Development Tools – What Do I Need?

Get all 5 posts on
Android development as
a downloadable PDF.

Two of a five part series on mobile development using Android.

After viewing the mobile OS landscape and choosing Android  as the next target for one of our products (see Developing An Android Mobile Application), the next step is determining the best software  development environment.

Our company has been developing for Windows Mobile since 2001 and have worked through many  iterations of device tools from Microsoft.  The current Visual Studio 2008 tool set has been polished and refined to the point where it is a highly effective integrated development environment for mobile device application development.

Microsoft has included support for many aspects of mobile  development including:

  • Visual GUI mobile interface design, with a broad range of control elements.  Allows alignments and sizing to  be done with the mouse.
  • Support for automatic layout of control elements when mobile screen size or orientation changes.
  • Managed code (C#, Visual Basic .NET)
  • Native code (C/C++)
  • A broad range of device emulators covering multiple releases of Windows Mobile and Windows CE in  a variety of form factors.
  • Interactive source code debugging on real and emulated devices.
  • Access to mobile devices via USB connection with GUI’s to view the device file system, registry, processes, heap and  message activity, SQL database, and  view the device screen and simulate the device keyboard on your workstation.
  • Support for Microsoft SQL Server Compact running directly on the mobile device, with ability to graphically define data sets, data sources, in line SQL code, etc.
  • Full support for creating polished installers to build CAB files to be directly installed on the device wirelessly ‘over the air’, and also for workstation installers that push the CAB file over the USB cable to the device using ActiveSync or Mobile Device Center.
  • Integrated source code control via Microsoft Team System or VisualSVN.

After building a number of complex commercial Windows Mobile device applications with Visual Studio 2008, about the only shortcoming we can identify is the inability to single step device source code from managed code to or from native code.  In all other respects, Visual Studio 2008 sets a very high bar for comparing other integrated development environments.

Our first impulse was to see if we could develop for Android using our familiar Windows OS environment.

Impossible?

No.

It turns out you can do this easily for managed Java code.  For C/C++ native code some DLL library development can be done with the Android NDK running on Windows, but developing unrestricted C/C++ native code requires access to Linux or a Mac.  This restriction is associated with the tools needed for full native code development.

If you enjoy working with command  line tools, a set exists that will operate on Windows for  Android Java development.  Our bias is toward using GUI tools wherever possible.  At least two GUI tools for Android Java development exists, Eclipse, and Sun’s NetBeans.  Some consider NetBeans to  be a better tool, but the Android team is officially only supporting Eclipse, and the future status of NetBeans is somewhat unclear because of the sale of Sun Microsystems to Oracle.

So Eclipse wins as our Android Java development environment of choice.

We installed the Eclipse IDE and the Android Development Tool plug-in on Windows XP.  The resulting development environment is pretty civilized, allowing us to write some simple Java programs, and then debug them on the Android emulator, all using the Eclipse IDE.  See the section below titled “Android development on Windows XP” for instructions to set up the Android Java development environment on Windows XP. It should work equally well on Windows Vista and Windows 7. We continue to use Windows XP to accommodate certain legacy applications we support.

C/C++ Native Code Development for Android

One of our products needs native code support on Android, and more importantly, mixed Java and native code in the complete application.  A large body of native C/C++ code already exists for our application, and we did not relish the idea of converting all of that to Java.  Other reasons for retaining the native code include higher performance, access to Android OS features for which a current Java class does not exist, and the ability to better obscure the logic of critical portions our application.

We first attempted to do Android native code support using tools available on Windows.  Eclipse has a CDT plug-in that  does a good job supporting C/C++ code development in a GUI IDE, including  interactive source code debugging on the workstation containing the Eclipse/CDT tool.

Like Visual Studio, Eclipse is a sophisticated shell,  performing  many of its functions by invoking command line tools.   The set of command line tools that does compiling, assembling, linking, loading and debugging of code for a particular hardware and OS environment is referred to as  a “tool chain”.  There are many tool chains available that are compatible with Eclipse. This allows Eclipse to be used for development on a wide variety of platforms.

The tool chain of interest for Android native development is a “cross” tool chain, one that runs in the x86 environment to operate on code located in the ARM CPU environment.  There are a number of these x86 to ARM cross tool chains available for Windows.  We elected to use “Sourcery G++ Lite ARM” from CodeSourcery.

The tool chain we downloaded from CodeSourcery is their community free edition of their more comprehensive commercial tool chain.  It worked well with the sample programs provided by CodeSourcery.

After doing some testing however, it became clear that the run time library and associated headers used by Android were only a subset of the GNU standard expected by the available cross tool chains.  This meant obtaining the library and headers from the Android open source project.  This open source project is designed to be used with Mac OS X or Linux, but not Windows.

We used Ubuntu to obtain the Android source tree, which included the run time libraries and associated headers.  We wanted to run the cross tool chain from Windows, but almost immediately ran into two significant roadblocks:

  • One was that a few dozen of the files whose names differed only in case.  Windows file names, by default, ignore letter case in names, whereas for Linux/Unix file names, case makes a difference.  Copying the files to Windows generates files with duplicate names.
  • The second roadblock is that the header files are organized in a different manner than expected by a GNU tool chain.  Both of these roadblocks could be overcome, but the amount of time and effort to do so was deemed prohibitive.

Since we are committed to building an application with a mix of managed and native code, it  became clear that it was necessary to move off of Windows.  We chose to move to Ubuntu 9.04 (Jaunty Jackalope).

Since we made this evaluation, the Android team has released the Native Development Kit or NDK to help develop native shared libraries for use by Java applications.  It was released on June 26, 2009.

The NDK is somewhat restrictive in its first release and if you want access to features not supported in the NDK, you must use the Android Open Source Project, running on Linux or Mac (not Windows!). There exists a Google group named “android-ndk” where progress reports on the NDK appear. Anyone using the NDK will want to monitor these progress reports.

After doing a fair amount of prowling around in the Android source and many Google searches, it became clear that the most efficient way for us to build native Android applications or libraries is to use the tools already in place in the Android open source project.  The open source project includes a very sophisticated build system including the necessary cross tool chain.  It’s all there ready for your use in building your own native applications or libraries.

What Are We Thinking?

For a developer who regularly works in open source, the last paragraph might seem extremely obvious. What are we thinking?

Our goal in this series of articles is to describe this project from the perspective of the Windows developer, who would likely gravitate to the Windows tools that are most familiar. So, we have documented our false starts and changes in approach to save others time and effort.

It is common wisdom that open source development and Windows development are different in a number of ways. But, we have seen developers on both sides attempt to develop for the other platform using the wrong approach or tools, resulting in delays, poor results and much frustration.

So, when we discovered these issues, we switched development environments and began using Ubuntu running the Android open source project.

For C/C++ native source code applications or libraries, you simply place your source code in a compatible folder tree in the open source project,  create a simplified “Android.mk” make file in the folder containing your source code, and then execute the build command.  After the build completes,  retrieve the executable or library from the designated output folders.  The only restriction is to name your application or library in a way that does not conflict with other modules already in the Android build.  For the build system to operate correctly, your source code must also be placed in a folder in an appropriate folder tree.

This mechanism can be used for pure C/C++ native Android applications, or for mixed Java and native applications interfaced through JNI.  The reason this works so well is that the Android system itself includes pure native applications,  along with mixed Java/native  applications interfaced through JNI.  So instead of attempting to reinvent the wheel with third party tools, we simply use what already is part of the Android open source project.

An important point to remember is that Android Java is not Sun Java ME.  Android Java is based on the Dalvik virtual machine, along with a subset of the classes available to Java ME.  In a similar fashion, the Android C runtime library, named Bionic, is a subset of the runtime library included with a typical GNU tool chain.  The sub-setting provides better performance on a resource limited device such as a mobile phone.

After you generate your native code, how do you debug it?

The latest Android 1.5 build contains a debugger gateway called “gdbserver” which attaches to or starts  up an Android  process on the mobile device.  It accepts commands and returns data to the classic  “gdb” command line debugging tool running on your Ubuntu workstation.

It would be  extremely helpful if we could work with Android  C/C++ native code in Eclipse with the CDT plugin.  But a quick glance at the requirements  indicates that  it would  involve more time and effort than we have available.  Also, there  are indications on the android-NDK group  that the Android team will eventually tackle this project.  For now, we are left with using the command  line debugger GDB for working with native  code debugging.  We will provide detailed instructions for debugging in another article.

Android Development on Windows XP

As we mentioned above, developing Java managed code Android applications on Windows is fully supported and works well.  Developing C/C++ native code Android applications without the NDK is not feasible on Windows because of limitations in the tool chains, the case sensitivity of file names, and the header folder structures.  With a lot of time and effort, one might be able solve all these issues, but the more sane course is to use Linux or Mac as your native code development platform.  A native code development kit (NDK) that operates on Windows via  Cygwin has been released by the Android development team.  The NDK is a great step forward, but may be too restrictive for some applications.

Setting up the Java managed code Android environment on Windows is straight forward, involving the following four steps:

To verify your installation of Eclipse, Android SDK, ADT, and Java, you can build a sample “Hello World” application using the instructions located here: http://developer.android.com/guide/tutorials/hello-world.html.  Set a breakpoint in the Java source code and start the program in Eclipse debug mode.  You can see the emulator startup, and stop execution at the breakpoint you set.  You can single step the Java code or let it run freely to display the “Hello World” message on the Android emulator screen.

Coming Next: Android Development on Ubuntu

* * * * * * * *

Get all 5 posts on android development as a downloadable PDF.

With 20+ years as a top software and firmware developer, Charles Wilde has acquired a combination of proven business smarts, mobile development skills and device engineering expertise that is hard to match. Charles is available to consult with you and your team about native code development in Android, Windows Mobile or Windows CE. Just email him at AtonMail@aton.com.




Related posts

coded by nessus

Comments RSS    Trackback URL

5 Comments

  1. Rokudenashi Blues » Blog Archive » BIRT Project @ July 8, 2009 12:44 am

    [...] Android Software Development Tools – What Do I Need? [...]

  2. gaurav @ October 23, 2009 2:45 am

    hi i have a question related to which eclipse ide we need for xp

    1) Eclipse IDE for Java EE Developers (188 MB)
    or
    2)Eclipse IDE for Java Developers (92 MB)
    or
    3)Eclipse IDE for C/C++ Developers (79 MB)

    tell me the number 1/2/3
    i m waiting and new to this
    u wrote other very well

  3. Charles Wilde @ October 23, 2009 2:44 pm

    The one you want is #2, Eclipse IDE for Java Developers. The other versions contain items that are extraneous or missing needed items.

  4. Gunnar Forsgren @ December 6, 2009 2:28 pm

    Hello, your series of articles are consistent in abstraction level and well written, I enjoy reading this, thanks.

  5. Dom’s Blog » Blog Archive » Links and things @ March 18, 2010 12:23 am

    [...] What is required for Android development [...]

Sorry, the comment form is closed at this time.