Revision as of 23:29, 1 July 2011 by Tim Bird (Talk | contribs)

Jump to: navigation, search

Eclipse is a integrated development environment (IDE) which consists of a "plug-in framework" written in Java. See the Eclipse wikipedia entry.

Many embedded Linux vendors ship tools based on Eclipse, including TimeSys, MontaVista, Wind River Systems and LynuxWorks. Android uses Eclipse as it's main application development environment, and the Yocto Project also include Eclipse support.

Eclipse started as an IDE for writing Java programs, but has been extended to support numerous other languages, and development activities.

Eclipse basics


All real functionality in Eclipse is provided via plugins (themselves written Java). That is, Eclipse itself is really just a plugin framework.

Eclipse is primarily geared to support Java development. On Fedora 12, the default eclipse install has support for writing java programs, but not C.

  • JDT = Java Development tools - for Java development
  • CDT = C/C++ Development tools - for C and C++ development
  • linuxtools = additional Linux-specific tools (like valgrind, lttng, oprofile, etc.)
    • this is a superset of CDT
  • lttng - for performing tracing and analysis
    • I haven't gotten this to work yet
  • PDE = Plugin development environment
  • PyDev = python development IDE
  • Target Management/Remote System Explorer (TM/RSE)
    • Is used to discover and manage targets
    • see
    • Is used by Wind River for their embedded Linux IDE product

Eclipse and Android

Eclipse is the main application development environment for Android.

To develop programs for Android, a developer installs a Java development kit (JDK), Eclipse itself, and the Android Platform Tools, which is an SDK with class libraries and target management tools (like fastboot and adb). Finally, the developer installs the Android Development Tools (ADT), which has plugins and add-ons for Eclipse.

  • Android Development Tools
    • Android Development Tools is installed as a plugin to Eclipse (using eclipse software manager)
  • Android SDK and AVD manager
    • window to control Android SDK component installs
      • can install or uninstall SDK parts (including different API class libs, examples, and tools)
    • windows to control AVD (QEMU sessions)
      • AVD = Android Virtual Device
      • AVD manager can:
        • define sessions
        • start sessions
      • A different window/dialog is used for selecting a target for deployment and debug
  • Underneath everything are command line tools
    • sometimes you have to use command line adb to "repair" something (uninstall an app on the target)
  • DDMS = Set of windows to show process information from Android
    • DDMS can also be run as a stand-alone application
      • This shows some system-wide information that the Eclipse version does not

Usage examples and tutorials (relevant to Embedded Linux)

BeagleBoard Eclipse describes how to install and use Eclipse with BeagleBoard, focused on JTAG debugging.


  • With CDT, the resource scanner can get into cycles with symbolic links of folders. You must set up a resource filter ignoring these links to prevent the memory leaks that result.

Miscellaneous Notes

  • Eclipse is a derivative of VisualAge by IBM (which was originally a smalltalk IDE)
  • Eclipse uses SWT graphics and windowing (not AWT or SWING)
    • AWT is too native, SWING is too non-native
    • SWT is supposed to be "just right" tradeoff between performance and look and feel.
  • can get Vim-like keybindings with vwrapper -

Android debug/target control architecture

  * can view information from target (either qemu or device)
  * logcat
  * can read process thread info
  * can read process heap info
* Debug view
  * assume that underneath there is some handoff from adb to jdb (java debugger)
    * I assume this is done with port forwarding, but I'm not sure
      * adb support forwarding ports from host to target, including jdwp (java debug wire protocol) ports
      * I assume that once established, jdwp is direct from jdp to process on target, with no intervention by adb after initial handshake
      * Android applications (at least those from deployed from eclipse) all have jdwp threads, ready for debugger to attach to

* how is this related to target management/Remote System Explorer?
  * seems similar in architecture, but completely separate in implementation

Android eclipse plugins

* Source code for plugins is in: <aosp_root>/sdk/eclipse/plugins
  * The following plugins are available:

How the ADT plugins use adb

In sdk/eclipse/plugins/

the following import is found:

* import

and statements:

* AndroidDebugBridge bridge = AndroidDebugBridge.getBridge();
* bridge.restart()
* bridge.setSelectedClient()

In sdk/ddms/libs/ddmlib/src/com/android/ddmlib/ checkAdbVersion creates a command consisting of mAdbOsLocation and "version", and uses Runtime.getRuntime().exec(command) Then the code parses stdOut from the resulting process for the version information.

However, in: sdk/ddms/lib/ddmlib/src/com/android/ddmlib/ there are lots of classes that talk directly to an adb server (using the adb command protocol), to accomplish things like port forwarding, remote shell executing, etc.)

There are the following methods

* AdbHelper::executeRemoteCommand()
* AdbHelper::runEventLogService()
* AdbHelper::runLogService()
* AdbHelper::createForward()
* AdbHelper::removeForward()
* AdbHelper::reboot()
* AdbHelper::write()
* AdbHelper::read()
* AdbHelper::formAdbRequest()
* AdbHelper::readAdbResponse()
* AdbHelper::setDevice()
* AdbHelper::createPassTrhoughConnection()

In sdk/ddms/lib/ddmlib/src/com/android/ddmlib/Device.Java, there's a method executeShellCommand, which is used several places in the ddmlib.

Eclipse and Yocto

Yocto has an eclipse

* Yocto uses CDT remote launch, org.eclipse.cdt.launch.remote and TCF file/shells to transfer binaries and launch applications
  * CDT = (C Development Toolkit)
  * See:
  * supports communication with emulator or real device, via Yocto Eclipse TCF
  * emulated devices use NFS rootfs so host and target access same filesystem
  * debugging is via cross-gdb (gdbserver and gdb client on host)
* required plugins: (see section 4.1.2)
  * CDT 7.0
  * RSE 3.2 (Remote System Explorer)
  * Autotools
  * Yocto Plug-in

The Yocto plug-in provides the following tools:

* OProfile: Selecting this tool causes the oprofile-server to be launched on the remote machine.  The oprofile-viewer must be installed on the local host machine and the oprofile-server must be installed on the remote target, respectively, in order to use. You can locate both the viewer and server from You need to compile and install the oprofile-viewer from the source code on your local host machine. The oprofile-server is installed by default in the image.
* Lttng-ust: Selecting this tool runs "usttrace" on the remote target, transfers the output data back to the local host machine and uses "lttv-gui" to graphically display the output. The "lttv-gui" must be installed on the local host machine to use this tool. For information on how to use "lttng" to trace an application, see
* PowerTOP: Selecting this tool runs "PowerTOP" on the remote target machine and displays the results in a new view called "powertop".
* LatencyTOP and Perf: "LatencyTOP" identifies system latency, while "perf" monitors the system's performance counter registers. Selecting either of these tools causes an RSE terminal view to appear from which you can run the tools. Both tools refresh the entire screen to display results while they run.

Remote System Explorer

I downloaded RSE as part of the Yocto ADT, and found it easy to view files on a target that was running sshd. Also, it was easy to configure and launch shells and "terminals". Shells allow you run individual commands, and see their output. A terminal provides an interactive shell.