Android App Builds with Eclipse
With the world being overrun by smartphone apps, once again I was a bit curious just how difficult it would be to build one of these apps on my personal computer. The Android OS has been around for 5-7 years, so I have to believe the development SDK is fairly mature. I have very little experience with Java, and even less with the Dalvik VM, but I do have 20+ years of experience with C/C++ and object-oriented design methodology, so I decided to give it a go.
I had already installed the Android SDK and played around with it a little bit. It seemed to install things on my computer, but it wasn’t clear exactly what, and there didn’t appear to be anything really interesting I could do with these tools (other than create an Android Virtual Device using the AVD Manager, which again didn’t allow me to do anything else interesting).
The Android Plugin for Eclipse
I had heard people were developing for Android using Eclipse, so my first task was to find an Eclipse plugin for the Android SDK. After a fast Googling I found this reference page. This is called the Android Developer Tools plugin for Eclipse, and the following information is needed for installation into Eclipse.
The Add Repository name is “ADT Plugin”
The Download Location is https://dl-ssl.google.com/android/eclipse/
I then proceeded to fire up Eclipse and perform the following steps.
Click the Help menu | Install New Software
Click the Add button
Enter my repository name and download location
Select “Developer Tools” as the instructions say to do
Click Next twice
Accept the license agreement
I waited a few seconds for the plugin to be downloaded and installed, and then allowed Eclipse to reboot.
On reboot if you get a message saying that the plugin requires a more recent version of the Android SDK, then you have no choice but to comply if you wish to use the plugin, so just follow instructions until both SDK and plugin are brought current.
From my prior experience with Eclipse, the next step is often to add a new perspective to the interface (especially when using a new language), but in this case there was no new perspective associated with the Android plugin.
Create the Android App Project
The next step I took then was to create a new Android project. I right-clicked on the Package Explorer, chose the new Android Application Project wizard, then clicked Next.
The next page of this dialog has 3 values which fundamentally affect your project (top 3 textboxes), and context help displays at the bottom of the dialog depending on which textbox your cursor is in. In fact if you just enter the Application Name, the other text fields will auto-populate. I left the bottom four fields at their default values, then clicked Next four times (accepting all default values), then clicked Finish.
The plugin seemed to know what to add to my project, since there were a couple primary folders containing project data.
First Run Attempt
At this point it wasn’t perfectly clear to a noob like me what to do next. Without further information I just started clicking things, and I started with those interesting-looking Run and Debug buttons in the toolbar. Then, nothing happened. That’s usually a bad sign when you click Run and nothing happens. I did get a strange warning dialog however.
I subsequently learned from this page that I had to do a couple things to get my program running. For starters I decided I was going to be running my app in the Android emulator (since I didn’t have a physical mobile device anywhere near my computer at the time). The emulator instructions say that first I must create an Android Virtual Device, and this I was already familiar with from playing with the AVD Manager. You can launch the AVD Manager from Eclipse using a button in the toolbar.
Using the AVD Manager is pretty straightforward. From the Device Definitions tab I selected the entry matching my own mobile device, and clicked the Create AVD button. This auto-populated the AVD creation dialog, I selected a skin from the drop-down list (I chose the HVGA skin so the resulting emulator would be a reasonable size on my computer screen), clicked Ok, and I was done. My device then showed up in the Android Virtual Devices listbox.
The developer instructional page also told me I had to create a Run and/or Debug configuration, and associate my virtual device with it. This is also straightforward. Since I wanted to use the debugger, I created my Debug Configuration by first clicking Run menu | Debug Configurations. On the main dialog page I selected Android Application, then clicked the New Launch Configuration button.
You must first name the new configuration, then select the name of your project. On the Target tab, you also must select the Android Virtual Device you want associated with this Debug Configuration.
Second Run Attempt
That’s all that is needed. After clicking Apply you can begin to Debug by clicking that button, or you can simply Close the dialog. This time when I clicked Debug, there was some activity, but what appeared was a whole new set of errors. I was seeing a number of Lint errors and warnings. For all the noobies out there, Lint is like a pre-processor which scans through your code looking for errors.
I wasn’t sure what I did to cause this, but I was looking at 7 errors and 187 warnings, and things didn’t appear too promising. The items on the Lint Warnings tab give you information on the individual problem, but these items are not clickable, and there is no context menu for them either. However the Problems tab does allow you a context menu with some options, and I looked at these briefly, but the place I found which corrected these errors was the Options button on the Lint Warnings tab.
The Lint Options dialog allows you to specify how Lint handles any given scan condition. Certain things that appeared as errors in my output, may not have actually been a fatal error to Android, and this turned out to be the case. Somehow I had triggered an overly strict Lint interpretation (perhaps that’s the default when the plugin is first set up). Each item on the Lint Warnings tab tells you which specific Module, Lint Category and Id is causing the error. You can use those values to look up the scan condition in the Options dialog and change the reporting from fatal error to warning. In the Options dialog, be sure to choose the module which is causing the error before changing the reporting.
You can get Lint to rescan using the refresh button.
Third Run Attempt
This time when I clicked the Debug button, my host intrusion prevention system began going berserk, as the emulator created local servers which Eclipse tried to connect to. The emulator here goes through the process of a complete launch (Android OS boot-up), so it seemed to take a long time to get to where my app began running. You see the steps it goes through in the Eclipse output console, and finally you will see your app running in the emulator.
I was encouraged that this whole process only took maybe 15-20 minutes (it took much longer to compose this article with images). With any new development technology, the first part of the battle is always just getting the work environment set up, becoming familiar with the interface, tools, and overcoming initial obstacles.
In case you’re very, very new to Eclipse, it is an open source IDE (Integrated Development Environment), written in Java, and it is customizable to such an extent that you can use it with a great many languages and build platforms. Eclipse is downloadable from here. Typically the standard version is all you need, since any specialized language or build perspectives can be added/removed at any time through the package manager. There is no installation program for Eclipse, so just unzip it into the final destination folder where you will launch it from. Since it relies on Java, it is usually a good idea to install the latest version of Java (both 32 and 64 bit) from here before installing Eclipse.