Build Overview‎ > ‎

    Building the Eclipse-Based Tools

    This document describes how to build all the Eclipse support for Android, as well as how to configure all the source code such that you can edit, run and debug the Android plug-ins from within Eclipse.


    Make sure you have followed the basic instructions in our overview page.

    The Eclipse plug-ins are located at sdk/eclipse/plug-ins/<plugin-id>
    Because those folders are Eclipse projects they must be self contained and not reference items outside of their folders. Since they do reference several jar files created from content in sdk/, it is necessary to run a script (once) to setup a few symlinks. These symlinks target jar files in out/host/platform/framework/

    $ ./sdk/eclipse/scripts/

    Note that on windows, this command will make copies of the jar files instead.


    Next, configure Eclipse. We support Eclipse 3.6 and up. Make sure you get a version with RCP support, such as the "Eclipse for RCP and RAP Developers" distribution. Eclipse Classic + the XML Editor will also work.

    To configure Eclipse, right click in the Workspace and choose "Import...", then select "Existing Projects into Workspace".  You want to import precisely these projects:
    • sdk/eclipse/plugins/
    • sdk/eclipse/plugins/
    • sdk/eclipse/plugins/
    • sdk/eclipse/plugins/
    • sdk/eclipse/plugins/
    • tools/swt/ddms/app
    • tools/swt/swtmenubar
    • tools/swt/ddms/ddmuilib
    • tools/base/ddmlib
    • tools/base/common
    • tools/base/sdklib
    • tools/swt/sdkmanager/app
    • tools/swt/sdkmanager/sdkuilib
    • tools/base/device_validator/app
    • tools/base/sdk-common
    • tools/swt/sdkstats
    • tools/base/layoutlib-api
    • tools/base/testutils

    Hint: if you want everything, you can simply select a higher level folder (for instance sdk/eclipse/plugins) to open all those project in a one fell swoop.
    You could select sdk/ as the top level folder but you'll get a LOT of projects, including some in sdk/testapps/ which you don't want.

    Then, go to the Preferences panel, search for Classpath Variables, and define the following:
    • ANDROID_SRC pointing to the top of your source tree (e.g. the "android" dir in the initial checkout instructions).
    • ANDROID_OUT_FRAMEWORK pointing to <Android tree>/out/host/<platform>/framework
    Voila -- now all the errors in the Problems view should disappear! (There are still quite a few warnings.)

    Note: We now require projects to compile with Java 1.6.

    Run and Debug

    The next step is to add a run configuration so you can run and debug the ADT. Hit the Run button. When it asks you what to run it as, choose "Eclipse Application".

    Important: Open the Configurations panel and edit the new configuration. In particular, go to the "Plug-ins" panel, and uncheck the third or so item,  "". If you enable it you can run into some very subtle bugs where jars from the test module's classpath are accidentally conflicting with different versions of jars in the tools plugin. I wasted nearly a day on that issue...

    If you're on Mac and you get "java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM", you need to add "-d32" as an argument to the VM.

    You should now be able to run the ADT - it will invoke a second instance of Eclipse, where all the Android tooling is baked in. The first thing you need to do is point the tool to a version of the SDK. Open the Preferences panel, and in the Android panel go to the text field where you can point to an SDK root. If you have downloaded versions of Android in the past, you can point to the root containing all of the different platforms here. 

    For Linux and Mac users: You can either download an official release of the SDK to use with ADT or you can build your own local SDK -- when you ran "make sdk" earlier you built a trunk version of the Android SDK (from here on referred to as "AOSP", which stands for Android Open Source Project).  Therefore, you can point to your build output here -- and as you continue pulling down new changes and rebuilding the SDK, your Eclipse target will also use the latest and greatest. 
    To point to it, use <your tree>/out/host/<architecture>/sdk/android-sdk_eng.<username>_<platform>/.
    That exact path depends on your architecture and user name. So open the file chooser and drill down, first to out, then host, then your os and architecture, then sdk, and then some directory which contains "android-sdk_eng", your username and your platform.  Hit OK.

    For Windows users:  The easiest thing to do is to use an official installation of the SDK (if you need to customize the Android platform yourself the only alternative is to do a linux or mac build of the SDK and then copy it over on your Windows machine; if you do that you might as well develop on ADT on the mac or linux box where you modify the platform.)

    After a brief pause you should now see a platform listed in the listbox in the Android panel, and it will identify itself as version "AOSP". If you instead point to officially released versions of Android, you'll see versions like "5", "6" and "7". The reason we don't use a number for the trunk version is to prevent you from accidentally building an app compiled against this trunk version, and then releasing it on the market.

    Now that you have your Android versions configured, you can create a new Android project. Do New > Android Project, and in the New project dialog, you need to go and choose the AOSP platform in the platform listbox.  Fill out the dialog. The only trick is that it asks you for a "Min SDK Version", and here you should again type "AOSP".  You can now go and try for example the Layout Editor, by opening res > layout > main.xml.

    We're working actively on the layout editor, but as you can see we could use help in lots of areas, from feature development, to icon work, to bug fixing, to bug reporting!

    To stay up to date, just go to the command line, type "repo sync", wait for a while, and then redo the make steps (source build/, lunch sdk-eng, make sdk, create_symlinks), and reopen Eclipse and rebuild all. If you get a build error, you can wipe out the entire out folder to build from scratch, but I rarely have to do that.

    You can add additional Android platforms, such that you can choose which platform to use for WYSIWYG rendering (just like you can already switch theme, orientation, etc):

    This is a new feature added just in the last couple of days. It lets you target older platforms but visually work with newer platforms, and quickly switch between them to see how your layout looks on different platforms.  Of course, to use this you need to point your root Android tree to an install containing multiple platforms. If you do add additional platforms, make sure you copy older platforms (android-6, android-7, etc) into the platforms/ folder of the newly built SDK, rather than the other way around. This is necessary because the directory structure changed recently.


    Now that you can build and run, let's take a look at the source code. The main Eclipse project to look at is the "adt" project, which is the Eclipse plugin.

    First, you can configure your editor to use our custom dictionary to help the spell checker recognize words that are in our comments but are not in the default Eclipse English dictionary.  Search for Spelling in the options dialog, and add sdk/eclipse/dictionary.txt as the "User Defined Dictionary" path.

    Second, if you will be doing any editing of the source code, make sure you configure your editor to use our formatting preferences and our import order. Open the Java Code Style dialog, and for the formatter, import development/ide/eclipse/android-formatting.xml . For Organize Import, import development/ide/eclipse/android.importorder . The code style for the Android source code base is document in


    That's it! You should now be able to get the source code, build, edit, run and debug the Android IDE tools!