Erste Schritte

Ein Beitrag von Arno Becker

Am liebsten möchte man natürlich gleich loslegen mit der ersten Android-App. Zuerst heißt es jedoch eine Entwicklungsumgebung erstellen und sich mit der Struktur eines Android-Projekts vertraut machen.Vor dem ersten Android-Programm steht die Konfiguration einer geeigneten Entwicklungsumgebung. Google gibt recht deutlich den präferierten Weg vor: Eclipse mit dem Android Development Tool-Plugin (ADT-Plugin). Daran muss sich niemand halten, jedoch ist Eclipse eine freie und ausgereifte Entwicklungsumgebung und das ADT-Plugin sorgt für eine vollständige Integration des Android-SDK.

Daher beschreibt dieser Blog zunächst die Installation einer auf Eclipse basierenden Entwicklungsumgebung, bevor der Aufbau eines Android-Programms näher betrachtet wird. Abschließend wird noch ein Blick auf den Umgang mit dem Android-Emulator geworfen. Wer auf das ADT-Plugin verzichten möchte, weil er z.B. eine andere IDE als Eclipse verwendet, findet unter [1] die nötigen Informationen.

Vorbereitung

Egal ob Windows, Linux oder Mac OS, Voraussetzung ist die Installation des Java Development Kits (JDK) [2] in der Version 1.5 oder 1.6. Eine Java Runtime (JRE) reicht nicht aus. Doch Vorsicht, wer die Version 1.6.0-21 installiert hat, kann Probleme mit Eclipse bekommen [3]. Lieber auf eine andere Version ausweichen. Version 1.4 des JDK oder der Gnu Compiler für Java (gcj) laufen nicht zusammen mit dem ADT-Plugin.

Das Android-SDK

Android bringt viele eigene Klassen und Werkzeuge mit, die im Android-SDK zusammengefasst sind. Auch wenn man in Java programmiert, so schreibt man dennoch für Android-Geräte mit spezieller Hardware und einer eigenen Oberfläche. Fertiger Programmcode wird mit dem Java-Compiler übersetzt und anschließend cross-kompiliert in einen Android-eigenen Bytecode (Dex-Bytecode). Auch der Emulator zum Testen der eigenen Anwendung auf dem PC ist Bestandteil des Android-SDKs. Nach dem Download [4] entpackt man die Zip-Datei in ein Verzeichnis. Windows-Benutzer werden vielleicht die Datei „Setup.exe“ im Hauptverzeichnis des Android-SDK bemerken. Linux- und Mac OS-Benutzer erreichen das gleiche Programm über den Aufruf von /tools/android.sh. Die Dateien starten den Android SDK and AVD Manager, den wir später über das ADT-Plugin aus Eclipse heraus aufrufen werden. Sie sollten folglich nicht aufgerufen werden, wenn wir mit Eclipse und dem ADT-Plugin arbeiten.
Nun richtet man sich einen Pfad auf das tools-Verzeichnis des Android-SDK ein. Linux- und Mac OS-Benutzer erweitern und exportieren dazu am besten den Pfad im Startskript der verwendeten Shell (z.B. .bashrc). Windows-Benutzer passen den Pfad in den Umgebungsvariablen (Systemsteuerung -> System und Sicherheit -> System -> Erweiterte Systemeinstellungen -> Umgebungsvariablen) an. Später wird man trotz Eclipse bisweilen mit der Kommandozeile arbeiten, um zum Beispiel eine Änderung der Ortsposition zu simulieren oder einen Blick in die Datenbank der Anwendung zu werfen.

Eclipse installieren

Zur Entwicklung von Android-Anwendungen sollte Eclipse 3.4 oder 3.5 verwendet werden. Mit der Version 3.6 gibt es noch Probleme mit der Integration des ADT-Plugin. Hier sollte man den aktuellen Stand der Dinge in Bezug auf das ADT Plugin überprüfen [5], wenn man Eclipse 3.6 verwenden möchte. Lädt man sich Eclipse herunter [6], so muss man darauf achten, eine Version für Java mit dem JDT-Plugin auszuwählen. Eclipse Classic, Eclipse for Java Developer oder Eclipse RCP sind beispielsweise eine gute Wahl.

Das ADT-Plugin

Das Android Development Tools (ADT) Plugin [7] stellt die Verbindung zwischen Eclipse und dem Android SDK her. Es unterstützt und beschleunigt die Entwicklung von Android-Programmen ganz erheblich. Es bietet einem unter anderem:

Aktualisierung des Android-SDK
Projekt-Wizard
GUI-Generator
(Remote)-Debugging
Profiling
Erstellen signierter Programme

Das ADT-Plugin wird über Eclipse installiert. Dazu geht man im Hauptmenü auf Help -> Install New Software… (siehe Abbildung 1). Über die Schaltfläche „Add“ gibt man die Download-Quelle des Android-SDK an:

Das_Android_SDK01-Add_Site

Abbildung 1 | Download-Quelle des Android-SDK angeben.

Falls es zu Schwierigkeiten kommt weil die URL nicht gefunden werden kann, sollte man https in http ändern.
Nun wählt man die SDK-Quelle aus und wartet, bis die Verbindung hergestellt wurde. Eclipse schlägt nun vor, „Developer Tools“ zu installieren (siehe Abbildung 2). Dort setzt man das Häkchen und folgt den Anweisungen.

Das_Android_SDK02-Install_SDK
Abbildung 2 | Installation des Android-SDK.

Es müssen die Lizenzbestimmungen akzeptiert werden. Dann folgt eine Warnung (siehe Abbildung 3), da das Android-SDK nicht mit einem offiziell beglaubigten Zertifikat signiert wurde. Hier kann man bedenkenlos fortfahren, indem man dem Zertifikat durch Setzen eines Häkchens vertraut.

Das_Android_SDK03-Security_Warning
Abbildung 3 | Warnung vor der Installation des unbeglaubigten Zertifikats.

Nach einem Neustart von Eclipse ist das Android Plugin verfügbar. Das erkennt man daran, dass in der Toolbar ein neues Icon hinzugekommen ist (Opens the Android SDK and AVD Manager).

Abbildung 4 | Neu hinzugekommenes Icon in der Toolbar

Android-Plattformen installieren

Nun teilt man dem Plugin mit, wo das Android-SDK liegt: Window -> Preferences -> Android. Dort gibt man die SDK Location an und drückt auf die Schaltfläche Apply. Es werden die schon installierten Android-Zielplattformen (Targets) gesucht. Es gibt zu jeder Android-Version eine SDK-Zielplattform. Dieses enthält genau die Klassen, die zu der jeweiligen Android-Version gehören.

Die verschiedenen Android-Versionen wurden durchnummeriert. Diese Nummerierung wird als API-Level bezeichnet. Der API-Level wird angegeben, um zu definieren, ab welcher Android-Version das Programm lauffähig ist. Dabei entspricht

Level 1 der Android-Version 1.0
Level 2 der Android-Version 1.1
Level 3 der Android-Version 1.5
Level 4 der Android-Version 1.6
Level 5 der Android-Version 2.0
Level 6 der Android-Version 2.0.1
Level 7 der Android-Version 2.1
Level 8 der Android-Version 2.2

Man kann durch die Auswahl eines Targets für eine bestimmte Android-Version entwickeln. Abwärtskompabilität ist gegeben, aber unter einem niedrigeren SDK-Target fehlen die Klassen und Methoden der höheren Android-Versionen. Als Entwickler sollte man sich immer für die niedrigste, aber alle Features unterstützende Android-Version und damit für das korrespondierende Target entscheiden, damit die Anwendung später auf möglichst vielen Geräten läuft. Derzeit laufen noch etwa 40 Prozent der in Umlauf befindlichen Android-Geräte mit einer Version kleiner Android 2.0!
Zu diesem Zeitpunkt enthält das Android SDK noch keine Targets. Dies sieht man daran, dass der Ordner /platforms im Installationsverzeichnis des Android-SDK noch leer ist.
Um Targets herunterzuladen, startet man den Android SDK and AVD Manager über das neue Icon im Toolbar oder über den Menüpunkt Window im Hauptmenü. In der linken Spalte (siehe Abbildung 4) wählt man „Available Packages“ an.

Abbildung 4 | Verfügbare Android-SDKs.

Es empfiehlt sich, hier gleich alle SDK-Versionen zu installieren. Dabei wird insgesamt ein knappes Gigabyte an Daten heruntergeladen.
Ganz alte Android-Versionen (1.0 und 1.1) und die Versionen 2.0 und 2.0.1 werden nicht mehr zum Download angeboten. Letztere wurden bald durch die stabilere Version 2.1 (API Level 7) ersetzt und sollten nicht mehr verwendet werden.
Pro SDK-Version lassen sich Beispielprogramme und die Google APIs für Google Maps installieren. Beides ist sinnvoll. Die Beispielprogramme bieten zu vielen Themen Referenzcode, den sich mal anschauen sollte. Die Google APIs braucht man beispielsweise, wenn man Kartenmaterial von Google Maps in einer Anwendung verwenden möchte. Sie enthalten das Android-SDK und eine zusätzliche Bibliothek mit der Google Maps-API. Diese Bibliothek wird in die jeweilige Anwendung eingebunden.
Unter Windows kann man auch gleich das USB Driver Package installieren lassen (Abbildung 4 unten). Damit kann man ein Android-Gerät über USB an den Entwicklungsrechner anschließen und Android-Programme darauf testen und debuggen. Unter Linux und Mac OS ist kein spezieller Treiber nötig.
Startet man die Installation der ausgewählten Android-SDKs, muss man im Folgedialog nochmals ausdrücklich die Lizenzbestimmungen der Google Maps APIs akzeptieren. Am schnellsten geht dies, wenn man die Option „Accept All“ wählt. Mit einem Klick auf die Schaltfläche „Install“ startet die Installation, die recht lange dauern kann.

AVD – Android Virtual Device

Android-Programme kann man während der Implementierungsphase im Emulator testen. Dies ersetzt nicht die abschließenden Tests auf echten Endgeräten, ist aber recht bequem.
Um den Emulator verwenden zu können, müssen Android Virtual Devices (AVDs) angelegt werden. Dabei handelt es sich um konfigurierbare System-Images, die alle wesentlichen Bestandteile von Android enthalten. Der Emulator sorgt nur für die Emulation eines Android-Geräts am Bildschirm. Die Eigenschaften des Geräts legt man über das AVD fest.
Über den schon bekannten Android SDK and AVD Manager, kurz AVD Manager, legt man ein AVD an und kann ihm verschiedene Systemeigenschaften zuweisen. Dazu gehören zum Beispiel:

Auflösung des Bildschirms
Größe der SD-Speicherkarte
Größe des Gerätespeichers
Verwendete Hardware
Auflösung der Kamera
GPS

Der Emulator wird mit einem bestimmten AVD gestartet und simuliert die im AVD eingestellten Geräteeigenschaften.
Zum Anlegen eines AVD wählt man im AVD Manager in der linken Spalte den Menüpunkt Virtual Devices. Durch einen Klick auf die Schaltfläche „New“ öffnet sich der Dialog zur Konfiguration eines AVD (siehe Abbildung 5).

Das_Android_SDK05-Android_SDK_and_AVD_Manager
Abbildung 5 | Konfiguration eines AVD.

Hier baut man sich sein virtuelles Gerät zusammen. Man gibt den Namen, die Android-Version (Target), die Größe der SD-Karte, die Bildschirmauflösung und die zu simulierenden Hardware-Komponenten an. Über die Schaltfläche „New“ kann man weitere Hardwareelemente und Geräteeigenschaften hinzufügen.
Will man eine Anwendung für Location Based Services schreiben, so muss beispielsweise „GPS Support“ hinzugefügt werden. Per Voreinstellung hat ein normales Android-Gerät einen 16 Megabyte großen Programmspeicher (Heap), den sich alle Android-Anwendungen teilen. Für höhere Bildschirmauflösungen wird automatisch ein größerer Heap gewählt (Parameter: Max VM application heap).
Mit Hilfe der Parameter kann man sich auch ein minimales Android-Gerät zu Testzwecken zusammenstellen, auf welchem man die spätere Anwendung testet. Bei einer Heap-Größe von einem Megabyte reicht es, wenige andere Programme zu starten, um Speicherprobleme zu simulieren. Nimmt man den Parameter „Battery Support“ hinzu, kann man einen leer werdenden Akku simulieren und testen, ob die Anwendung mühsam eingegebene Daten rechtzeitig sichert.

Ein Projekt anlegen

Nachdem die Entwicklungsumgebung steht, sollte man sich damit vertraut machen, wie ein Android-Projekt aufgebaut ist.
Das ADT-Plugin kann ein neues Android-Projekt anlegen, erzeugt dabei die komplette Projektstruktur und generiert ein „Hello, World!“-Programm.
Zum Anlegen eines Projekts wählt man im Hauptmenü von Eclipse File -> New -> Android Project. Abbildung 6 zeigt den Dialog zur Eingabe der Projekteigenschaften. Wichtig ist hier, dass man sich Gedanken darüber macht, für welche Android-Version (bzw. Plattform) man sein Programm schreiben wird.

Das_Android_SDK06-Create_new_Android_Virtual_Device
Abbildung 6 | Anlegen eines Android-Projekts.

Grundsätzlich sollte man für das fertige Programm eine möglichst kleine Versionsnummer wählen. Der Grund ist, dass sich Anwendungen mit einer höheren Versionsnummer nicht auf Android-Geräten mit einer kleineren Versionsnummer installieren lassen. Man verliert folglich Anwender.
Versionen vor Android 1.5 (= API Level 3) muss man heute nicht mehr unterstützen, da es dank automatischer Aktualisierungen kaum noch Geräte mit diesen Versionen gibt.
Verwendet man später Klassen oder Methoden, die erst in einer höheren Version hinzugekommen sind, so muss man die Versionsnummer des Programms hochsetzen, was jederzeit problemlos möglich ist, wie wir später sehen werden. In der API-Dokumentation zu Android findet man die Versionsnummer zu jeder Klasse, Methode und Konstante am rechten Seitenrand neben deren Namen (z.B. „Since: API Level 5“).
In Abbildung 6 wurde als „Target Name“ Android 1.5 gewählt, was dem API Level 3 entspricht, wie man der rechten Spalte entnehmen kann. Diesen trägt man ganz unten unter „Min SDK Version“ ein. API Level und „Min SDK Version“ sollten immer übereinstimmen, damit die Klassen der richtigen Android-Version zum kompilieren verwendet werden.
„Application Name“ ist der Name der Anwendung, wie er später im Programmordner des Geräts erscheint. Mittels „Create Activity“ hat man die Möglichkeit, automatisch einen Startbildschirm für die Anwendung generieren zu lassen. Klassen, die Bildschirmseiten verwalten, nennt man Activity. Als Name für die Startseite wurde hier „MainActivity“ eingetragen.
Ein Klick auf die Schaltfläche „Finish“ beendet den Dialog. Optional könnte man im nächsten Schritt ein Testprojekt zum Testen der Anwendung anlegen.

Start der Anwendung im Emulator

Das ADT-Plugin legt nun ein lauffähiges Android-Projekt an. Der erste Start sollte immer über den AVD Manager (Menüpunkt „Virtual Devices“) erfolgen und nicht über das Kontextmenü des Android-Projekts (Run As -> Android Application). Hat man später zu Testzwecken mehrere Android Virtual Devices angelegt (für Version 1.5, 1.6 etc.), so wird automatisch das mit der passenden Zielplattform ausgewählt. Dies wäre hier die Version 1.5 und es wird der alte Emulator gestartet. Zum Entwickeln empfiehlt es sich jedoch, den Emulator einer aktuellen Android-Version zu verwenden. Daher startet man die Anwendung besser über den AVD Manager. Dort wählt man das eben angelegte AVD „Android_2.2“ und drückt auf die Schaltfläche „Start…“. Die „Launch Options“ lässt man zunächst unverändert. Als Ergebnis startet der Emulator des Android-SDK Version 2.2 und nicht der Emulator der Version 1.5. Später kann man das Target über die Eclipse Run Configuration im Reiter Target ändern.
Der Emulator braucht recht lange, um zu starten. Wurde er einmal gestartet, sollte man ihn nicht beenden. Es reicht, nur die Anwendung neu zu starten. Bisweilen bleibt der Emulator „hängen“, wenn man ihn startet. Dann muss man ihn Beenden und neu starten.
Nach erfolgreichem Start der Anwendung zeigt der Emulator eine schwarze Oberfläche mit dem Text Hello World, MainActivity! an. Die Statuszeile gibt den Namen der Anwendung wieder (Hallo Android).

Das Android Manifest

Für das Schreiben eigener Android-Anwendungen ist es wichtig, den Aufbau eines Android-Projekts verstanden zu haben. Bild 7 zeigt die Projektstruktur.

Das_Android_SDK07-New_Android_Project

Abbildung 7 | Anlegen eines Android-Projektes

Das zentrale Dokument ist das Android Manifest im Wurzelverzeichnis des Projekts. Es handelt sich um eine XML-Datei. Sie stellt eine Art Deployment Descriptor dar. Hier werden alle eigenständigen Komponenten eines Android-Programms deklariert.
Als Komponenten werden Activities zur Verwaltung von Bildschirmseiten, Services für Hintergrundprozesse, Content Provider zur Definition von Schnittstellen und Broadcast Receiver zum Empfang von Systemnachrichten bezeichnet.
Listing 1 zeigt das automatisch generierte Android Manifest. Innerhalb des Application-Tags befindet sich die Deklaration der Komponenten. Die Anwendung besteht nur aus einer Bildschirmseite, deren Activity hier deklariert ist. Das Intent-Filter-Tag sorgt dafür, dass beim Start der Anwendung genau diese Bildschirmseite angezeigt wird

<?xml version="1.0" encoding="utf-8"?>
 manifest xmlns:android="http://schemas.android.com/apk/res/android"
  package="de.visionera.introduction" android:versioncode="1" android:versionname="1.0">

  <application
   android:icon="@drawable/icon"
   android:label="@string/app_name">
   <activity android:name=".MainActivity"
    android:label="@string/app_name">
    <intent-filter>

     <action android:name="android.intent.action.MAIN"/>
     <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
   </activity>
  </application>

  <uses-sdk android:minSdkVersion="3"/>
 </manifest>

Außerhalb des Application-Tags wird die minimale SDK-Version definiert, wie sie beim Anlegen des Projekts angegeben wurde. Verwendet man später bei der Implementierung der Anwendung Klassen oder Methoden aus einem höheren Android SDK, muss man hier den Wert auf den benötigten API-Level erhöhen.

Ressourcen

Ein beträchtlicher Teil der Arbeit beim Schreiben eines Android-Programms fließt in das Erstellen von XML-Dateien. Diese werden als Ressourcen bezeichnet. Ort der Ablage in der Projektstruktur sind Ordner unterhalb des Ordners /res. Dort befinden sich schon einige Unterordner mit Dateien (siehe Bild 8). Bilder und Grafiken werden im Ordner /res/drawable abgelegt. Dort befindet sich schon die Datei icon.png. Das Icon des Programms wird im Android Manifest in einem Parameter des Application-Tags eingebunden.

Das_Android_SDK08-Projektstruktur

Abbildung 8 | Projektstruktur

Das Aussehen einer Bildschirmseite bestimmt man über ihr Layout, wovon es auch mehrere für eine Seite geben kann. Ein Layout zusammen mit einer Activity ergibt die Bildschirmseite. Dabei bestimmt das Layout, welche Oberflächenelemente (etwa Textfeld, Checkbox, Schaltfläche) angezeigt werden sollen. Die Activity realisiert das Laufzeitverhalten der Bildschirmseite (Reagieren auf Oberflächenereignisse, Auslesen von Formularfeldern et cetera).
Listing 2 definiert als einziges Oberflächenelement eine TextView. Als Views bezeichnet man in Android Oberflächenelemente, in diesem Fall ein Textfeld. Die Art des Layouts wird über das äußere Tag LinearLayout festgelegt. Seine Attri bute legen fest, dass alle Oberflächenelemente des Layouts vertikal, also untereinander angeordnet werden sollen und dass die Breite und Höhe des Layouts den ganzen Bildschirm einnehmen soll. Es gibt noch eine Reihe weiterer Arten von Layouts, die andere Anordnungsvorschriften für Oberflächenelemente besitzen.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"

    android:layout_height="fill_parent"
    >
<TextView
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="@string/hello"

    />
</LinearLayout>?xml version="1.0" encoding="utf-8"?
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"

    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    >
<TextView
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"

    android:text="@string/hello"
    />
</LinearLayout>

Statische Texte sollten immer in einer weiteren Ressourcendatei definiert werden. Daher wird im Layout das android:text-Attribut der TextView über eine Textressource befüllt. @string/hello ist ein Verweis auf eine Ressource. Dabei bedeutet das @-Zeichen, dass es sich um einen Verweis handelt. Das Schlüsselwort string definiert den Typ der Ressource. String-Ressourcen, also Texte, werden in der Datei /res/values/strings.xml abgelegt. Dort ist ein Parameter hello zu finden, der den Wert enthält, der auf der Bildschirmseite angezeigt wird (Hello World, MainActivity!).

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="hello">Hello World, MainActivity!</string>
    <string name="app_name">Hallo Android</string>

</resources>

In der Datei strings.xml wird auch der Name der Anwendung definiert. Im Android Manifest (siehe Listing 1) befinden sich ebenfalls Verweise auf Ressourcen, neben dem Verweis auf den Anwendungsnamen auch der auf das Icon der Anwendung.
Android erlaubt es, für verschiedene Umgebungen umgebungsabhängige Ressourcen zu definieren. Will man beispielsweise die Anwendung für unterschiedliche Sprachvarianten auf den Markt bringen, so definiert man je Sprache eigene Ressourcenordner. Dort hinein kommen dann die Ressourcen, die zu dieser Sprache gehören.
Derzeit liegt nur die Datei strings.xml mit deutschen Sprachtexten in dem Ordner /res/values. Dies ist der Ordner, auf den zugegriffen wird, wenn Android keinen sprachabhängigen Ordner findet. Maßgebend ist die in den Systemeinstellungen eingestellte Sprache. Die Default-Sprache ist somit Deutsch. Besser, man erzeugt einen neuen Ordner /res/values-de und kopiert die Datei strings.xml in diesen Ordner.
Soll die Standard-Sprache Englisch sein, übersetzt man die Texte in der Datei /res/values/strings.xml ins Englische. Der Name des Ordners values wird nach ISO 639-1 um das entsprechende Sprachkürzel mit vorangestelltem Minuszeichen erweitert.
Nicht nur der values-Ordner lässt sich für verschiedene Umgebungskriterien duplizieren. Gleiches gilt auch für weitere Ordner, wie drawable und layout. Layouts im Ordner layout können beispielsweise je Perspektive (Hochformat oder Querformat) erstellt werden. Dazu erzeugt man die Ordner /res/drawable-port und /res/drawable-land und legt die entsprechenden Layouts dort ab. Die wichtigsten Umgebungskriterien sind:

Sprache (zum Beispiel en, fr),
Bildschirmgröße (zum Beispiel 640 x 480),
Perspektive (zum Beispiel. port, land),
Android-Version (v1 ..., v8).

Ressourcen werden automatisch vom ADT-Plug-in vorkompiliert. Gleichzeitig wird die Klasse R.java automatisch generiert. Diese Klasse enthält Konstanten, auf die von überall aus dem Programmcode heraus zugegriffen werden kann. Die Konstanten haben als Werte automatisch erzeugte Ids; über diese Ids referenziert die Android-Anwendung zur Laufzeit eindeutig eine bestimmte Ressource.
Die Klasse R.java befindet sich im Ordner /gen/packagename.der.anwendung/R.java. Ausführliche Informationen zu den Ressourcen und deren Verwendung im Programmcode sind [7] zu entnehmen.
Durch die Verwendung von Ressourcen erhalten Sie bei der Android-Programmierung eine gute Trennung von Programmlogik und Oberfläche. Die Beschreibung von Bildschirmseiten in XML (Layouts) mag am Anfang gewöhungsbedürftig sein, ist aber wesentlich leichter zu pflegen und für Menschen einfacher zu lesen als Programmcode.
Beim Schreiben des XML-Codes gibt es keinen Grund, sich vor Laufzeitfehlern zu fürchten, da das XML beim Speichern durch den Android-Ressourcencompiler geprüft wird. Fehler fallen daher sofort auf.
Der im ADT-Plug-in eingebaute GUI-Builder ist bis jetzt wenig brauchbar, sodass man das XML besser von Hand schreibt oder auf Werkzeuge von Drittanbietern zurückgreift.
Das Testen der Anwendung im Emulator ersetzt nicht das Testen auf echten Endgeräten. Durch die vielen Einstellmöglichkeiten und das Anlegen einer nahezu beliebigen Anzahl von Android Virtual Devices ist es jedoch möglich, vollständige Anwendungen zu entwickeln, ohne den Rechner zu verlassen.

Quellen:

[1] Alternative IDEs; http://developer.android.com/guide/
[2] JDK; http://java.sun.com/javase/
[3] Eclipse-Fehler; https://bugs.eclipse.org/bugs/
[4] Android SDK; http://developer.android.com/
[5] ADT-Plug-in für Eclipse; http://developer.android.com/sdk/eclipse-adt.html
[6] Eclipse; http://www.eclipse.org/downloads/
[7] Arno Becker, Marcus Pant:
„Android 2 – Grundlagen und Programmierung“,
dpunkt-Verlag, ISBN 978-3-89864-677-2
[8] Systemvoraussetzungen; http://developer.android.com/sdk/requirements.html