Downloading the Android SDK

SDK stands for Software Development Kit. The Android SDK contains tools for developing Apps for Android telephones.

There are pretty complete instructions for downloading the SDK in almost every Android reference, because you really can't begin software development without having most of the tools.

You'll notice that there are choices about what to download. I'll tell you what I've downloaded, but if you like another choice, feel free to take it.

I'd like you to prepare a journal describing your download experience (see end of this page) so at the very least you should take notes as you do the various steps.

The page to start from is http://developer.android.com/sdk/index.html.

This page has most of its important content hidden behind expandable headings. For example, if you click on the SYSTEM REQUIREMENTS heading, you'll see a list of operating systems and development tools supported for the Android SDK. If you don't have one of the listed operating systems, you might still succeed in getting the development tools to work, but you are committing yourself to extra work!

Downloading Java

Android applications are (mostly) written in Java, so you need a Java set of Java development tools. (A JDK) In particular, as of August, you need Oracle's JDK 6, which is not the latest version, and which you might not have on your system if you have been developing Java programs already. [The reason you need an older version is that Android phones use an independently developed Java Virtual Machine, called Dalvik VM. Dalvik uses a slightly different set of bytecodes, and packs them slightly differently. But instead of writing another compiler to produce Dalvik binary code, Android uses a binary-to-binary file converter, which reads .class files and writes .dex files for the Dalvik VM to use. Although there isn't any reason a similar converter couldn't be written for Java 7 or 8, or the existing converter upgraded to cover any binary differences between the versions, it hasn't been done and tested yet. For the same reason, you can't use gcj, the Gnu Java compiler.]

If you already have another version of Java on your system, and want to keep it, your life just got more complicated. There's no problem with keeping two versions of Java in separate directories, unless you actually want to use them both.

In Windows, there's a Java directory, using in Program Files, and all the downloaded versions sit inside that directory. To use a particular version, you need to make sure that the path is set correctly and that the environmental variables JAVA_HOME and CLASSPATH are set to match.

On linux, that scheme would work most of the time if it weren't a convention to put a soft link in /usr/bin/javac (and /usr/bin/java and /usr/bin/jar, etc.) to the current version. So you need to redo the soft link when you want to switch between versions. To make this easier, there's a tool called update-alternatives, which fixes the soft links if you follow a set of conventions about where you put the software, and since there are so many different java tools, there's a tool called update-java-alternatives which calls update-alternatives on about twenty different java tools if you have its configuration file set up correctly.

To be lazy, I'm going to assume that you're willing to have only one version of Java on your system; if you already have another, you'll leave the JRE around for programs you've previously compiled, but never use the JDK for that version again.

To download software from Oracle, you need an Oracle user account. Go to https://login.oracle.com/mysso/signon.jsp, and either sign in, or click on the Create Account button. The account is free, although presumably Oracle is hoping to send you advertising once you give them your email address.

To download JDK 6, you need to go to http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html You might as well download the latest version of Java 6, even though you are scores of versions behind the latest version of Java 8. That's Java SE Development Kit 6u45. After you click on the link, you'll have to choose the Accept License Agreement radio button, and the appropriate OS and hardware version.

If you are running a 64-bit Windows system (pretty likely if you bought your machine in the last three years) you want the Windows x64 download, jdk-6u45-windows-x64.exe. It is a self-installing executable, but you'll need an administrative password to install. I think it sets up the path, etc. so that all you have to do is run it.

Linux X64 has two files to pick from. If you were running redhat linux or one of its derivatives, you'd want the file with rmp in the name; I'm running ubuntu, and chose the other. The .bin extension indicates that the file is intended to be run as a shell script, so once you've downloaded it, you'd

Downloading ADT

I have a linux system, and I chose to download the Linux 64-bit bundle, which includes a fresh copy of the eclipse debugger, with all the Android plugins already installed.

If you have Windows on your machine, you will obviously want to download a Windows version of the software. If you happen to have a 32-bit processor, that is also relevant to your choice.

If you already have eclipse installed on your machine, you can save a little network traffic by downloading only the SDK. This would also be your choice if you are planning to skip using eclipse. The main advantage in doing so is that you understand exactly why a particular tool didn't get run -- you didn't run it. Eclipse tries not to do any duplicate work, and sometimes it doesn't do what you expect it to. On the other hand, eclipse is well connected to the documentation, and will save you a lot of search time.

A side-bar invites you to consider downloading Android Studio instead. It isn't a silly idea, but I decided not to do it.

The Example code from the text

The authors have made machine-readable versions of much of their code available online.

The example code is on github, a public code repository. The URL is https://github.com/programmingandroid

You don't need to download any of their code for the course. Almost all of it is in the textbook. But it's instructive to read it anyway, it's interesting to compile and play with it, and you sometimes use it as skeleton to start your own systems.

Testing your installation

In order to test your installation you should write the minimal android hello world program.

Start eclipse. In Windows, I think there'll be an eclipse icon on the desktop, and of course you can get at it by pressing the Windows key and going through the Start menu. On linux, I type "eclipse" in a terminal window. Eclipse pops up a window asking you which workspace to use. No reason to change it...
Eclipse offers a number of different screen arrangements; here are some you may see:

You can change among these and others by using the Windows / Change Perspective and Windows / Change View choices in Eclipse. an
In eclipse, create a new project: File / New / Android Application. Go through the project creation wizard, filling in the name of the application.
In the package name box, create a unique package name. The usual convention for package names is to begin with a URL and reverse the elements so that the most general element comes first. Then add more specific names to avoid duplication. For example, I might use:

Because computersystemsartists.net is a domain name I control, android separates my android projects from others, and HelloWorld is the particular project. Because java gives special relationships to classes sharing the same package, you want your package name to be different from every other one, even other projects you may write later.
I usually make API 8 Android 2.2(Froyo) the minimum required SDK, because I have a 2.2 handset, and it's easy to test on it. You could make some earlier or later version the minimum. This minimum will appear in your Android_Manifest file, and handsets earlier than the indicated minimum won't run the project. Since the API evolves with time, if you are only testing on later versions, you may be using classes or methods which hadn't been invented yet when the older phone was shipped.
On the other hand, I compile with Android 4.4.2, on the theory that they may have fixed bugs over the years.
Moving on the other screens in the new project wizard, you can choose an icon, ask eclipse to create a blank activity, and choose a name for the starting class in your application. The default is MainActivity, but Hello seems like a sensible name ...
When you have finished the new project wizard, eclipse puts up the .java file for your starting class. It has the required code for an android app already in place, and in fact, we won't add anything to it today; instead we'll
edit the activity_hello.xml file, which is also already open, by clicking on the appropriate upper tab. There is a builtin what-you-see-is-what-you-get editor, which shows us that eclipse already created a file which will show "Hello World!" on the screen.
We'll change this to مرحبا
By clicking on the RelativeLayout in the Outline pane at the right of the screen, we can see the TextView which holds the text,
click on the TextView to highlight it, and a properties box opens below the outline.
We want to change the Text property. It is currently @string/hello_world That means it is actually defined in the res/values/string.xml
if we change it to bumble, or ﻡﺮﺤﺑا, we'll see those values reflected in the Graphical Layout panel of the editor. But the reason that Android allows for indirection (that is, using yet another file to hold the actual value) is so that all the user interface values are defined together. So, a better thing to do would be to change it in the res/values/string.xml file.
clicking on res / values /string.xml in the package explorer pane at the left-hand side of the window brings up strings.xml to edit, and we can change the value to whatever we want.
Build the package by right-clicking on the project name in the package explorer pane at the left, and choosing Build Project from the long list of possibilities.
Now you want to run the software you have just created. If you have an Android phone, you can plug it into the computer with an appropriate cable. First, on the phone, start up the Settings app. Choose Applications / Development / Enable USB debugging. Then plug the USB cable into the phone and the computer. If you don't have an Android phone, you'll run the software on the simulator.
Highlight the project name in the package explorer project and choose Run from the top bar and then Run from the dropdown choices. If you've plugged in a phone, eclipse will ask if you want to run the project on the phone; if not, it will prompt you to create a system image for the simulator. You can create many images, to test your app for different screen sizes and Android versions, but a recent one seems like a good thing to have. Once you've created an simulator image, eclipse will keep it to use again later.
If you are testing the app on a phone, you can watch the progress of the software installation at the bottom of the eclipse screen. When it is installed, you can unlock the phone and see the app running.
If you are using the simulator, the process is exactly the same, except the simulator takes longer to run. Depending on which image you are running and the speed of your PC, you may have to wait several minutes while the simulator starts up. Even after eclipse claims the software is installed, the simulator is still working, and not yet ready to be unlocked. Just be patient.
(This step is solely for my benefit. You already know it worked.) Get an image of the screen. If you are using a simulator, you can take a screenshot. If you are using a real phone, the easiest way to get a screenshot is to use another phone to take a picture of the screen. I haven't tried it yet, but there's a description of taking a screenshot of an Android phone using the adb software included in the Android SDK at http://blog.shvetsov.com/2013/02/grab-android-screenshot-to-computer-via.html

What to turn in

I'd like to see a journal describing your download and testing effort. It can be a Word document, a web page, or an archive of text and image files. It should contain:

A text description of your steps, successes, and problems. You don't need to retype everything I already said; you can just reference it if you want.
A few illustrations, perhaps screenshots.
listings of code, xml files, etc. which you modified for the Hello World app.

You'll notice that wordy as I was, I missed many steps. Surely you will document them ...