Setting up an Android Development Environment in Windows with Eclipse

Posted on

WARNING: In the above video, the cursor is recorded in a slightly offset position, so sometimes it may look like I am selecting a 32 bit install instead of a 64 bit install. In any case, always select the download that matches your computer.

Here we will show you how to setup Eclipse for Android development in Windows. We use Eclipse partially for legacy reasons, but also due to the fact that Android Studio builds can be slow, and the fact that Eclipse supports development in Java, C++, and many other languages. I prefer to only have to learn one IDE for all of the programming I work on, and for that reason, I use Eclipse. For example, do you want to go through learning how to use Visual Studio just to learn C++ development, Android studio only for Android projects, and something else for Java development? I don’t. So here we will walk you through the steps necessary to setup Eclipse for Android development in Windows.


The Ingredients

Here is just a general list of the ingredients… every piece of software that you need to get your development environment set up. But please, try to install everything in the order I lay out. Otherwise, you may need to do a little bit of troubleshooting:

  1. Java JDK
  2. Git
  3. Cygwin (specifically, gcc, g++, and sh)
  4. 7-zip
  5. Eclipse for Android Developers
  6. Android NDK (optional, depending on whether your app has C++ components)


Only the finest ingredients…

I will get into the details of how to actually do the setup in the next section. Here I just want to introduce you to what you will be cooking with and why…

  1. To build a Java app, you need the Java development kit (JDK)… and since Android is basically built on Java (I am taking a little artistic liberty for saying this), you need the JDK to build Android apps. Note that many people already have Java on their computers to run website plugins. However, to run these plugins, you only need the Java Runtime (JRE) environment. To compile a Java app, you need the full JDK, which includes the JRE in it. So if you know you have Java installed, but don’t know if you have the JDK, the answer is almost definitely that you do not. The easiest way to check is to go to the folder “C:\Program Files\Java” and see if there is a subfolder starting with jdk. If there isn’t (if you only have folders starting with jre), then you will need to go get the JDK from the link above.
  2. Git is not technically a requirement for building Android projects in Windows, but it is extremely helpful. You will often find sample apps that you want to download from Github or a privately-hosted Gitlab server, and the easiest way to get that code is to clone it onto your computer. Specifically, on the landing page for most projects, you will typically find the git prominently displayed, or uncovered by clicking a “Clone or download” button. It is a web address that looks like To download the code to your computer using git, you simply open a command prompt in the folder where you want the code, and then type git clone Obviously there is a lot more under the Git hood than that, but that will get you started…
  3. Cygwin is something that probably every Windows developer has on their computer, but if you don’t, then there are 3 things we need from it: gcc, g++, and sh. We need those functions on the path for the Android development environment in Eclipse to be able to build C++ components of our apps. Again, this is something you might not need if you don’t plan on having any native app components, but it is probably something you should have “just in case”. We are getting you setup so that you can handle 99% of use cases…
  4. 7-zip is just a file unzipper. So why do you need it? Well the answer is linked to the next step… the Eclipse download. The builtin file unzipper in Windows 7 does not properly unzip the the Eclipse files. I don’t know why this happens, but I can attest to the fact that the built-in Windows 7 unzipper corrupts the Eclipse files (and I am not alone or crazy… Google it!). I don’t know if the built-in unzipper causes problems in other versions of Windows, but better safe than sorry… 7-zip is great anyway. So it doesn’t hurt to get it.
  5. If we are talking about Eclipse development, then obviously you are going to need Eclipse. But make sure you install the JDK before installing Eclipse. Eclipse uses the JDK extensively (not just for building Android apps), so you can potentially hit a lot of weird problems if you try installing Eclipse before the JDK. Just do yourself a favor and install the JDK first. On top of that, you will note in the video above that I do not recommend using the installer. The reason for that is that the installer will try to use the built-in unzipper… and like I said, that seems to corrupt the Eclipse files on some operating systems (Windows 7..cough..cough).
  6. As mentioned in passing before… Android is based on Java. Most apps will be developed only with Java code. However, you can build C++ components into your app, and to do that, you need the NDK (Native Development Kit). You shouldn’t start app development with the NDK, but you might end up there. So you might want to just go ahead and get that now.



  1. The Oracle website is a bit strange, but I trust that you can find the download for the latest JDK for your platform. By the way, you do not need the “Demos and Samples Download”. The barebones implementation will do. In my case, I looked for “Windows x64”, and then downloaded jdk-8u121-windows-x64.exe. Before downloading, you have to remember to click the “Accept License Agreement” button, which is a bit hidden. Then just click through the installer. Nothing special.
  2. Git is pretty straight-forward. Just get the installer for your system, and keep clicking until it finishes. No special settings needed.
  3. Cygwin is a bit cumbersome for beginners. Run the installer. At one point you have to select a download site. Choose something near you since presumably the connection will be faster. For instance, I live in Germany, so I found a download site that ended with .de. Also, I have always had more luck with the http connections than the ftp connections. Just saying… We will need gcc, g++, and sh, so in the search field, search for gcc. At the bare minimum, you will need gcc-g++ and gcc-core from the Devel list, so select those. You will also need sh, but that will be installed as a dependency, so you don’t have to do anything. Just click through the rest of the installation.
  4. 7-zip is straight-forward. Just click, click, click. Nothing special.
  5. Eclipse is a little bit weird. We downloaded a zip file without the installer. To extract the contents, right-click the downloaded file and open it with the 7-zip file manager (7zFM.exe). Then extract it in a place where you would like your installation. Moving the installation can cause you all sorts of heartbreak, so put it somewhere where it is easy to get to, and where you don’t plan on moving. I think “C:\” and “C:\yourUserName\” are good locations. Just please don’t pick a path with spaces in it, like “C:\Program Files\”. Doing so will cause you heartbreak at least once in your life. Also, don’t run Eclipse yet. We will get to that in the next section.
  6. If you downloaded the NDK, then I would unpack it inside your Eclipse folder, since you won’t be using one without the other.


The first run

First of all, when you unpack Eclipse from the zip file, it is not installed via a traditional installer. Therefore it will not appear on your start menu or desktop. In lieu of that, I like to create a shortcut to the executable on my desktop.

The first time Eclipse is run, it will ask you to specify a workspace. This is the container for projects that Eclipse loads into memory. You will typically never change the workspace, so create an easy to find location where to save it. I think saving it in a newly created workspace folder in the eclipse folder is a good idea. In this workspace, every new project will get its own folder.

After specifying the workspace, Eclipse may ask you for the location of the SDK. It asks you for the location just in case you already downloaded it. But we did not, so click “close”. Eclipse will download it for us in just second…

An aside on terminology: JDK=Java Devleopment Kit, SDK=Software Development Kit, and NDK=Native Development Kit. The JDK is used to develop any Java program (Android or not). The SDK is a Java based library of routines specific to Android (for instance, to get access to the sensors and cameras). The NDK is a library used to compile C++ code into an Android project. A final piece of terminology you may come across is the JNI (Java Native Interface), which is used to compile C++ code into a generic Java project. The NDK is built on top of the JNI.

Once you tell Eclipse that you haven’t downloaded the SDK, it will offer to do it for you. Again, you should tell Eclipse to download these files to the Eclipse folder so that everything is packaged together. You do not need Android 2.2. You only need “The latest available version of Android APIs…” We will get more APIs in a second.

At some point during the installation, Eclipse may ask if you want to install an Android virtual device. This is an emulator. Personally, I like to do test my programs on an actual device (a physical phone that you can hold in your hands). However, you can also simulate a phone on your computer, and test your programs on that. The reason I do not like using the emulator is speed. It can literally take 10 times longer to deploy an app for testing on an emulator than on a physical phone. So in summary… if you are planning on testing on a phone, you do not need to set up a virtual device. Even if you want to use an emulator, you can set that up later, so I would click “no” here.

Next, it may ask you to install the SDK built tools. You need those, so open the SDK Manager. If you accidentally clicked close, you can find the SDK Manager in Eclipse under Window -> Android SDK Manager. There are a lot of options in the SDK Manager, but you only need a few things:

  1. Android SDK Tools
  2. Android SDK Platform-tools
  3. The latest Android SDK Build-tools
  4. An SDK Platform


The Android SDK Manager

For each Android API, you are given the option to down some mix of the following options: SDK Platform, Samples for SDK, Google APIs, System Images, Sources for Android SDK, Documentation. Here is what those options do:

  1. SDK Platform: This is the bare minimum needed to compile code meant for a specific API. For instance, if I want to compile an app meant for Android 5.1.1 and newer devices, I could compile it with the 5.1.1 SDK Platform. All devices newer than the chosen SDK should be able to run the app because the APIs are backward compatible. That means that if I use some function that Google introduced in Android version 5.1.1, a phone running Android 5.1.1 or newer should be able to run that function. Some functions become deprecated over time, so that this is not technically guaranteed to be true, but I have never once seen an issue with it. Some functions have been deprecated for years, but still remain in the API. The last thing I should mention is that, due to this backward compatibility, you might consider only getting the newest SDK Platform. However, when you write code with that platform, it is easy to forget that some functions will not be available on older devices.
  2. Samples for SDK: When a new function or functionality is introduced to Android, a minimum working example app is typically released along with it to demonstrate its proper usage. Looking at and running these sample apps is often a good way to see how you should be using the code. In fact, many people use these apps as baselines for new apps, basically just tweaking the apps to fit their needs instead of writing a new app from the ground up.
  3. Google APIs: Google has a lot of well know APIs (like the Maps API) that are not built into the basic SDK Platform. The reason might partially be size (so that only core functionality is in the SDK Platform), but it probably also has to do with licensing. I believe the phone manufacturers have to pay Google to incorporate the Google APIs on their phones (which essentially all phone manufacturers do). So the Google APIs (which include the SDK Platform in them), are kind of like downloading a different API level version… If a phone doesn’t implement the Google APIs, then you wouldn’t want to built your app with them because you might include a function that is not implemented by the device manufacturer. So if somebody tried to run your app on such a phone they would probably see a runtime crash.
  4. System Images: These are the objects that the emulator uses to simulate a specific device. For instance, if I want to emulate an Android 5.1.1 device with Google APIs and an ARM 64 processor, I would look for that System Image. Be careful though. These files can be really huge, so you do not want to download many of these. Actually, I do not have any downloaded, because I do not use the emulator. But I leave it up to you…
  5. Sources for Android SDK: The SDK Platform is a compiled version of the source code. These are the sources used to generate it. I like to download these so that when I am debugging, I can see exactly what the Android code is doing internally. So these are not necessary, but they give you insight into the underlying implementation.
  6. Documentation: Self explanatory… no?

Finally, there are some “Extras” at the bottom. Depending on what types of apps you are writing, you may or may not need these. So it is hard for me to give you advice on whether to download them. I like having them there just in case.


Finishing the NDK setup

Open Eclipse, and navigate to Window->Preferences->Android->NDK. There, you need to specify the location of the unpacked NDK files. In some of the newer NDK versions there seems to be a small bug, where Eclipse says “Not a valid NDK directory”, and will not let you “Apply” the changes. To solve this problem, you need to create a blank file called “ndk-build” without a file extension in the ndk folder. In that folder, you should already have a file “ndk-build.cmd”, so now we need to create an additional empty file with the same name, but no extension. As I show in the video above, one easy way to do this is to open the command prompt in the ndk folder, and enter the command “echo > ndk-build“. Then open the file with Wordpad or something similar and delete all of the contents. Then you can go back to Eclipse and try to reenter the NDK location. You should find that it is now recognized.

Next, to actually compile NDK code, we installed Cygwin, but didn’t tell Eclipse where it lives. Therefore we are going to add Cygwin to the system path so that Eclipse (and anybody else) can always find it. To do that, we need to modify the “Advanced System Settings”. To get there, you can either click the start button and search for “Advanced System Settings”, or you can right-click on “My Computer” and select “Advanced System Settings” from the left hand side. In the pane that pops up, click on “Environmental Variables” towards the bottom.

Now for the Pro-tip: One of the most useful things that we can do with environmental variables is add something to the path. For instance, suppose I have some executable “aa.exe” in my “Downloads” folder. If I want to run the program, I would typically navigate to that folder and double-click the file. Similarly, if I wanted to run it from the command line, I would have to navigate to “C:\Users\bob\Downloads” and run it. I could not run the program if my command prompt was at “C:\Users\bob” or any other location. This is annoying if there is a file that I want to run a lot, like Cygwin. So to get around this, we will add it to the system path, meaning loosely that we can run Cygwin from any folder. To add a new program to the path, I always employ a three-step process:

  1. Create a user variable with the variable name PATH_CYGWIN (replacing CYGWIN with whatever program you are adding to the PATH) and variable value pointing to the directory that we want to add to the path. In this case, we want to add the “bin” folder in the Cygwin installation to the path. On my system, this is “C:\cygwin64\bin“. If you open a new command prompt (cannot be a previously opened one) and type echo %PATH_CYGWIN%, the output should now be the directory we just added. That means that we successfully created the new variable. However, we didn’t add Cygwin to the path yet (which you can see by trying to run the “gcc -v” command in your open prompt). Instead, we just added a new variable pointing to the directory.
  2. Next, we are going to see if you already have a user variable named “PATH” (case is not important, and it could be undercase, or written as “Path“). If there is one, copy the value to a new text file. You may want to save this file as a backup. The reason we are doing this is that the PATH variable is instrumental in getting your system to work properly… and now we are going to modify it. So to protect ourselves in case we make a mistake, we will make a copy so that we can just copy/paste the value from the text file in case we need to revert our changes.
  3. To actually add Cygwin to the system path, we will now add %PATH_CYGWIN% to the value of the user variable “PATH“. If there is no user variable (DO NOT modify the system variable PATH), then create a new user variable with the name PATH and value %PATH_CYGWIN%. If there is already a path variable, and it ends with a semicolon, then add “%PATH_CYGWIN%”. If it did not end with a semicolon, add “;%PATH_CYGWIN%” to the value. Now if you open a new command prompt and type “gcc -v“, you should see the version of gcc that is you installed. If something went wrong, you can revert to the original PATH value by copying what we put in the text file.

Note: Instead of creating a separate variable PATH_CYGWIN, and adding that variable to the Path, you could instead add Cygwin’s bin directory directly to the path’s value. However, as you start adding more and more paths (when you install more and more programs), this gets to be a real mess. It is much cleaner if your Path variable simply says something like %PATH_CYGWIN%;%PATH_PERL%;%PATH_PYTHON% etc. At the very least, it makes it much easier to see what is on your path, and potentially remove it.


The finishing touches

Now, if you find an Eclipse-based Android project on Github, we are ready to build the thing. What you want to do is to clone the code into your Eclipse workspace. So open a command prompt in your workspace folder (it should be something like C:\bob\eclipse\workspace), and run your git clone command. To get Eclipse to recognize the project, you need to “import” it into Eclipse. To do that, go to File->Import->Android->Existing Android code into workspace. Then browse to the root directory, and select the projects you want to import. Generally, I have found no use for working sets, so I never “add project to working sets”. However, there is one thing you need to be careful of…

If you have the project’s code already sitting in your workspace folder, but it is not imported into Eclipse, then you should NOT “Copy projects into workspace”. The use of the “Copy projects into workspace” function is this… If you do not have the code in your workspace folder, then you could tell Eclipse to “Copy projects into workspace”, in which case, Eclipse would simply copy all of the code into your workspace folder. Then whenever you modify the code, build it, etc, your original code would remain untouched. If your code is not in the workspace folder, and you don’t let Eclipse copy it, then Eclipse will work with it “in place”, that is, you will never see that projects contents in your workspace folder.

A note about the workspace: Do not copy this folder and try to move it. If you try to do this and reopen Eclipse, you will have to start reimporting your projects. If you want to see what would happen, try copying (copy/paste NOT cut/paste) your workspace somewhere else. Then you could try to change your workspace by going to File->Switch workspace. Did everything reappear like thought it would? Probably not.