You’ll need to navigate through some hidden folders to do so, in which case it’s usually easier to do through a Terminal window. Note: these instructions will work with Linux and OS X. If you’re on Windows, you’ll have to call Bill Gates, although it’s possible this will also work.

In the terminal, navigate to eclipse/configuration/.settings, where eclipse is your Eclipse installation folder. In this folder there is a file called: org.eclipse.ui.ide.prefs. Edit this file, and you should quickly see the line that says “RECENT_WORKSPACES=” followed by various paths to workspaces you’ve used. Simply delete the workspaces you don’t want. They are separated by “/n”. So make sure to leave a “/n” between each workspace. Additionally, you must leave the information on a single line. Do not break it out to multiple lines.

QUICK ANSWER: eclipse/configuration/.settings/org.eclipse.ui.ide.prefs

Well after scouring the internets with no results, I remembered that when I installed the SDKs with Eclipse, there seemed to be a lack of overlap between the two. When installing the Eclipse Plugin, it creates a folder in the workspace called com.google.android.sdk, except this SDK doesn’t line up with the SDK from the Android Developers site. When I had initially put things together I simply copied over some of the files created by Eclipse to avoid breaking the plugin. But when running adb devices, it was running from the Eclipse provided SDK. Upon trying again with the adb command from the Android Developer’s SDK, the phone shows up on the list of devices. So now I’m copying arranging files to use the good SDK.

Not sure if this will have an effect on the Eclipse plugin. I’m assuming not. My guess is that the Eclipse plugin was simply packaged with an older version of the SDK. We’ll see though. So happy to see the Android SDK is in Java though. Way better than the iPhone SDK.

UPDATE:
Looks like you don’t want to overwrite any files. Simply leave the com.google.android.sdk directory as is and point to the downloaded SDK in the Android preferences pane in Eclipse (SDK Location). I had to delete and recreate my helloworld project in Eclipse to repair the errors due to the missing core library (android.jar).

A few months ago I began working with Ant tasks in Eclipse. Specifically, I was using fdtkit along with Ant in Eclipse to generate JavaDocs for my Actionscirpt 2.0 libraries using as2api. For the most part fdtkit is a fabulous tool, or rather toolbox for generating JavaDocs and numerous other tasks with the use of Ant. However, the issue that I very soon found myself confronted with was documenting classes from linked libraries in Eclipse. Normally I will set up a project with a src containing code specific to that project, and then make use of linked libraries to make use of code from other projects/api’s. When running an Ant task to create my JavaDocs I was unable to intelligently identify the paths to my linked libraries to add to the documentation.

The way Eclipse and FDT handle linked libraries is through the IDE and the .project file found in the root of the project folder. Opening the .project file, you might see something like this (assuming you are using linked libraries):

<link>
<name>core</name>
<type>core</type>
<locationURI>FP8</locationURI>
</link>

Looking at the link object, you will see two important pieces of information the name property and the locationURI property. Now the name property represents the name associated with the linked library (obviously) and then there’s the locationURI. The locationURI is a reference to the linked resource. The problem here is where the hell is the identity of that locationURI? In the Eclipse IDE you can select a linked library in the Explorer view and then examine it with the properties view. Here you will see the value for the resolved location, which is the full, absolute path to the linked library on your local system. But how the hell to I get that property with Ant? How to I access it all? Well, I’ve been asking that question for quite some time, scouring the Internet and finding nothing. Today, I found my answer.

Determined to know how linked resources were being saved on my system I began digging deep in the my Eclipse folder to find property in some buried file. Note, I’m running Eclipse 3.3 on OS X. I would imagine the path is similar on Windows, but probably not exactly the same (I’m guessing it’s pretty damn close to the same in Linux). Anyway…

The file location is: ${your_eclipse_workspace_folder}/.metadata/.plugins/loc.eclipse.core.runtime/.settings/loc.eclipse.core.resources.prefs
This file looks something like:

pathvariable.FP7 = /Users/local/Workspace/fdtkit/lib/FP7
pathvariable.FP8 = /Users/local/Workspace/fdtkit/lib/FP8
pathvariable.FP9 = /Users/local/Workspace/fdtkit/lib/FP9

So now, through Ant task it is possible to have your build.xml (relative to your project) parse the .project file of the project for linked libraries and with the locationURI parameters to grab the absolute path to the class library from the loc.eclipse.core.resources.prefs file.

Please feel free to contact me if you have any questions regarding this post. I’m sure this isn’t the most straight forward explanation of what I’ve found here, but I’m a little to jacked up on coffee to form clear coherent thoughts right now.

Note: Linked resources are Workspace specific. Different workspaces have a different set of linked resources.