Android, die von der Open Handset Alliance vorgestellte Plattform für mobile Endgeräte, tritt während einer entscheidenden Phase für die gesamte Industrie auf die Bühne.
Das gerade gestartete System Android tritt gegen Apples I-Phone, diverse mobile Linux-Alternativen und die zum Teil sehr betagten proprietären Plattformen der Hersteller an. Hinter Android steht zwar ein Konsortium von über 30 sich ergänzenden Technologieträgern, jedoch weidet im Zentrum der Platzhirsch schlechthin: Google.
Im stillen Kämmerchen
Die Plattform [1] ist das Ergebnis jahrelanger Entwicklungsarbeit, die bis zur offiziellen Bildung des Konsortiums allein der Google-Ableger Android vorangetrieben hat. Die Android Inc. selbst, ehemals angesiedelt in Palo Alto und damit nur ein paar Autominuten entfernt vom ständig wachsenden Googleplex im Nachbarort Mountain View, hat Google 2005 übernommen und konnte somit ungestört im Verborgenen arbeiten.
Der Kauf machte klar, dass der Internetgigant auch die mobile Welt auf dem Radar hat und zu gegebener Zeit einen Trumpf spielen kann. Android-Gründer ist Andy Rubin, der schon in den 90ern mit seiner Firma Web-TV am TV-Empfang für mobile Geräte tüftelte und später über eine weitere Firmengründung (Danger) ein Smartphone namens Sidekick entwickelte. Google hat sich einige Veteranen von Web-TV und Danger und damit eine Menge Erfahrung ins Boot geholt.
Wäre ein G-Phone von Google schon als ein ernst zu nehmender Angriff auf das gesamte Establishment der Handywelt zu verstehen gewesen wie das I-Phone, so bietet die offene Android-Plattform mit der breiten Basis auf mittlere und längere Frist noch wesentlich mehr Sprengkraft.
Viele Handyhersteller suchen nämlich nach einer Alternative für proprietäre Plattformen, die mit der schönen neuen Multimediawelt, den hohen Datenmengen und insbesondere den Forderungen nach besseren Benutzeroberflächen nicht mehr nachkommen. Das sind die besten Voraussetzungen, um das Interesse an Android bei so ziemlichen jedem Mitspieler im Markt zu entflammen.
Mit Open Moko [2], der Access Linux Platform (ALP, [3]), Trolltech Qtopia [4] oder dem von Nokia propagierten Maemo [5] stehen allerdings auch viele Konkurrenten bereit, die sich gerne das größte Stück vom neuen Kuchen einverleiben möchten.
Offenes System
Im Zentrum von Android steht eine offene Systemplattform, die auf Linux und der Java-Syntax aufbaut und zudem den Port des Webkit-Browsers mitbringt. Webkit ist bereits als Standard-Browser der Nokia-S60-Geräteserie und des I-Phone im Einsatz und auch der Core-Bestandteil des Safari-Browsers von Apple.
Webkit ist inzwischen zum “hot cake” schlechthin avanciert, lassen sich damit doch endlich Ajax-fähige Browser-Applikationen auf dem Handy erstellen. Es bedarf keiner intensiven Analyse, um zu erkennen, dass Android-Hardware mit einem Großteil der zu erwartenden I-Phone-Applikationen umgehen kann. Die Konkurrenz fürs I-Phone kommt also vor allem aus der Android-Richtung. Dem bisher eher hochnäsig auftretenden Browseranbieter Openwave oder auch Access weht nun mit Webkit der Wind kalt ins Gesicht. Milliarden Kühlschänke, Espressomaschinen und Aufzüge warten darauf, mit modernen Mitteln programmiert und bedient zu werden.
Die beste Plattform nutzt aber nichts, wenn die Programmierer, die für Applikationen sorgen, das Angebot nicht wahrnehmen. Hier hat Google einen Schnellstart hingelegt. Ein Programmierwettbewerb mit einer Gesamtbörse von 10 Millionen US-Dollar heizte vom ersten Tag an das Interesse der Entwickler an. Das kommt der Android-Community und sicherlich auch Google zu Gute – der Wettbewerb ersetzt gleichfalls teure und langwierige Technology-Push-Szenarien.
Dalvik – Java á la Android
In erster Linie soll der Anwendungsprogrammierer die Android-Applikationen in Java erstellen. Java? Google versucht mit einem geschickten Schachzug, die zum Teil ärgerlichen Lizenzrestriktionen von Sun zu umgehen. Zwar ist die Sun VM inzwischen Open Source (OpenJDK), jedoch gelten bei Nicht-GPL-Projekten nach wie vor Restriktionen. So sind die TCK-Testsuite (Technology Compatibility Kit) beziehungsweise das JCK (Java Compatibility Kit), die die Compliance mit der Java-Spezifikation feststellen und zum Tragen des offiziellen Attributs und Marketingnamens “Java” zu durchlaufen sind, für kommerzielle Projekte nach wie vor kostenpflichtig. Diese Einschränkung ist eine Hürde, die die Open-Source-Gemeinde ungern zu nehmen gedenkt.
In der Android-Welt kompiliert der von Google entwickelte Compiler die Quellen in den Bytecode für die so genannte Dalvik VM, ohne sich um die offizielle Java-TCK zu kümmern. Google trifft mit diesem Lösungsansatz die Kritik vieler Open-Source-Anhänger, die nach der Öffnung seitens Sun zwar besser mit Java arbeiten können, aber beim Übergang zu kommerziellen Applikationen wieder zu einer kostenpflichtigen Lizenz verdonnert sind. Abzuwarten bleibt, ob sich aus diesem Ansatz neue Scharmützel zwischen Sun und Google ergeben.
Es kann nicht schaden, die Meinung von Terrance Barr [6] zu verfolgen, der bei Sun für diese Fragen geradesteht. Auf der letztjährigen OSGi-Konferenz in Madrid musste er Kritik der Mobil-Linux-Gemeinde einstecken. Zudem gibt Android mit seinem Dalvik/Java-Mix ein klares Zeichen in Richtung Java SE statt des nunmehr betagten Java ME für mobile Endgeräte.
Sun hat es in den letzten Jahren allem Anschein nach verschlafen, Java ME so schnell mitwachsen zu lassen, wie die mobile Hardwarewelt voranbraust. So wurde Java ME von der Realität überrundet, auch weil der zähe Java Community Process (JCP) zur Genehmigung von Neuentwicklungen die Definition und folgende Implementierung neuer APIs verzögert. In jedem Fall erhöht sich die Aufsplitterung der Java-Gemeinde, die bereits mit der unüberschaubaren Realität der Java-ME-Implementierung ringt, weiter.
Abgesehen von kosmetischen Unterschieden ist die Dalvik VM nicht einfach ein “Clean room”-Port der bekannten Sun Java VM. Der Bytecode (»dex«- statt der gewohnten »class«-Dateien) beider VMs unterscheidet sich zum Teil erheblich. Das liegt auch daran, dass Dalvik registerbasiert arbeitet, während die Sun VM Parameter auf dem Stack verwaltet.
Der Bytecode normaler Java-Programme lässt sich mit Hilfe des »dx«-Tools in den Dalvik-Bytcode kompilieren. Dank der von Apache Harmony übernommenen Java-SE-Bibliotheken ist die Chance groß, dass die Java-SE-Applikationen auch unter Android laufen. Harmony wiederum greift auf den TCK von Sun zu, sodass die Bibliotheken Sun-konform sind – ein genialer Schachzug von Google.
Parallel-Gesellschaft
Da jede Android-Applikation als eigener Prozess abläuft, ist Dalvik auch für den parallelen Einsatz vieler VMs auf Systemen mit wenigen Ressourcen optimiert. Natürlich bleibt es beim Support durch eine VM nicht aus, dass sich auch Scripting-Umgebungen nutzen lassen. Mit Hecl [7] steht der erste Port zur Verfügung. Weitere dürften folgen. Der Entwickler David Welton führte den Hecl-Port durch und baute einige Erweiterungen ein. So erlaubt Hecl Applikationsskripte, die direkt auf Android-Widgets zugreifen. Zudem ist die Einbindung von Dalvik-Klassen möglich.
Einen guten Überblick in die zur Verfügung stehenden Java-Bibliotheken [8] findet sich auf den Dokumentationsseiten zu Android. Es fallen unter anderem APIs für die eingebaue SQLite-Datenbank, weiterführende Netzwerk-Schnittstellen (Proxy-Support), der OpenGL-Support, ein schlanker SAX-Handler, ein Modul zur Spracherkennung oder der XMPP-Support auf. Neben vielen Java-SE-Libs (»java.*«) finden sich des Weiteren die bekannte Bluetooth-API Bluez sowie JSON.
Natürlich gibt es ein Telefonie-API, das derzeit allerdings nur das Handling von GSM-Gesprächen und SMS unterstützt. Es fehlen noch Funktionen für moderne Lösungen auf HSPA- oder LTE-Basis, genau wie ein MMS-Support. Alle Widgets zum Aufbau eines UI sind in »android.widget« zusammengefasst. Eine Perle findet sich mit dem Webkit-Port in Android: Webkit-API. Dieses API erlaubt einen engen Draht zwischen Webapplikation und Plattform – falls erwünscht.
Android-Projektebau
Der zentrale Bestandteil einer Android-Applikation ist eine Activity. Eine Applikation kann aus mehreren Activities bestehen, jedoch definiert der Entwickler immer eine bestimmte Activity als dedizierte Einsprungadresse für die gesamte Applikation. Diese selbst muss keine Oberfläche mittels der Views bereitstellen. Insbesondere System-Services können damit im Hintergrund agieren.
Funktionen von höherer Komplexität – wie etwa der Browser – lassen sich als so genannte “Message Objects” isolieren und von Applikationen aufrufen. Eine Applikation verknüpft hierzu ein Message Object per »Intend« mit dem externen Code. Im Falle des Falles sorgt das System dafür, dass beim Aufrufen einer URL automatisch der externe Browser aufgeht. Weitere Intends stehen derzeit für den Aufbau eines Telefonanrufs sowie für die eingebaute Map-Applikation zur Verfügung. Applikationsentwickler können dieses Portfolio für ihre Zwecke noch erweitern.
Optionale APIs
Neben den erwähnten Basis-APIs können dedizierte Geräte auf einen Satz optionaler APIs [9] zurückgreifen (Abbildung 2). Sie betreffen Location Based Services und Maps (LBS-API), Medien-Handling (Media-APIs) sowie 3D-Grafik (OpenGL-API). Weitere Low Level-APIs sind nach Google-Angaben geplant. Das der ganze Bereich noch nicht völlig ausgegoren ist, zeigt die Gruppe “Google-API” [10] die ebenfalls Google-Map-Support sowie mit XMPP-Messaging einen Dienst anbietet, der allerdings eher unter der Rubrik “Jabber” zu erwarten wäre als bei Google-API.
Eclipse als IDE der Wahl
Bereits die erste Version des vorläufigen Android-SDK wartete mit einem recht tief gehenden Support der Eclipse-IDE auf. Nach dem Installieren des Android-Plugins und des SDK ist die erste Android-Applikation schnell geschrieben und im Emulator (Abbildung 1) ausgetestet. Hierbei ist es wie gewohnt möglich, das eigene Programm im Debug-Modus unter die Lupe zu nehmen. Es fehlt noch ein UI-Builder, der es erlaubt, direkt unter Eclipse auch die Oberfläche grafisch zu erstellen. Derzeit gilt es, diesen Schritt mühsam per XML-Deklaration oder direkt im Programmcode zu vollziehen oder die Hilfe externer Tools zu beanspruchen.
Zwar gilt Eclipse durch den direkten Support von Google derzeit als erste Wahl hinsichtlich der IDE, doch dürfen Entwickler auch andere Tools benutzen. Ein Beispiel hierfür sind erste Versuche mit Netbeans [11]. Auch steht zu erwarten, dass die Java-Entwicklungsumgebung Intelli-J brauchbaren Android-Support bekommt.
Abbildung 1: Eine der Device-Skins für den Android-Emulator zum Testen der Anwendungen.
Abbildung 2: Optionale APIs dienen der Entwicklung von Zubehörprogrammen mit 3D-Grafik und Maps.
Oberflächengestaltung
Zum Gestalten der Oberfläche teilt der Programmierer jeden Funktionsblock, etwa Anzeige von Informationen, Konfiguration und Begrüßung, in so genannte Views [12] auf. Das ist nicht neu und gilt als Brot-und-Butter-Konzept nativer mobiler Applikationen. Jede View – in anderen Umgebungen auch Screen genannt – übernimmt also eine spezielle Aufgabe.
Ein “Application flow” verknüpft die einzelnen Views zur gesamten Applikation. Android nutzt zur Definition des User Interface (UI) eine XML-Struktur, um die zur Verfügung stehenden UI-Widgets zu positionieren und zu konfigurieren. Die UI-Deklaration per XML ist schon von XUL und anderen Lösungen bekannt. Widgets lassen sich auch im Programmcode in den Widget-Tree der View einbauen oder manipulieren. Jede View bekommt über ihren Listener mit, ob etwa der Fokusstatus sich geändert hat, und viele Widgets haben als View-Subclass wiederum ihren eigenen spezialisierten Listener. Zum besseren Adressieren sollten jedes Element einer View und die View selbst eine eigene ID bekommen. Mit Hilfe der Methode »findViewById« lassen sich Elemente dann gezielt suchen.
Das Layout-Konzept von Android arbeitet zweiphasig, um die Anforderungen der einzelnen Elemente mit den tatsächlichen Gegebenheiten zu verknüpfen. Dies bedeutet praktisch, dass einzelne Elemente gewissermaßen von oben andere Parameter für Breite und Höhe erhalten als gewünscht oder Restriktionen einbeziehen müssen. Damit versucht das Layout-System, das bei mobilen Endgeräten meist recht kleine Display möglichst optimal zu nutzen. Einzelne Views fasst der Android-Entwickler zur besseren Organisation in Viewgroups zusammen. In der Baumstruktur sorgt dann immer das Root-Objekt dafür, dass untergeordnete Elemente gerendert werden und Events aufnehmen.
Es stehen diverse Layout-Typen zur Verfügung, um möglichst flexibel bei der Anordnung der Widgets zu sein. Während ein “Frame Layout” hauptsächlich als generischer Platzhalter dient, etwa für ein Multimedia-Objekt, baut ein “Linear Layout” die einzelnen Knoten in ihrer Reihenfolge hintereinander in einer horizontalen Anordnung auf. Um zu verhindern, dass kleine Widgets genau so groß erscheinen wie ausladende, kann der Programmierer per Gewichtung Einfluss nehmen.
Beim “Table Layout” erfolgt die Positionierung über ein Grid. Beim “Relative Layout” lassen sich einzelne Widgets in Relation zum Nachbarn positionieren und schließlich erlaubt das “Absolute Layout” die komplette, aber unerwünschte Kontrolle der Positionierung. Wie erwähnt ist jede View als eigenständige Einheit definiert. Demnach bekommt also auch jede View ihre ureigene XML-Datei, die sich im Projektfolder unter »/res/layout« findet. Ein Beispiel zeigt Listing 1, das eine View mit Linear Layout und einer Textbox nebst Button definiert. Der zugehörige Java-Code ist in Listing 2 zu finden.
|
Listing 1: Beispiel für |
|---|
01 <?xml version="1.0" encoding="utf-8"?> 02 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:padding="4dip" 03 android:gravity="center_horizontal" 04 android:layout_width="fill_parent" android:layout_height="fill_parent"> 05 06 <TextView 07 android:layout_width="fill_parent" android:layout_height="wrap_content" 08 android:layout_weight="0" 09 android:paddingBottom="4dip" 10 android:text="@string/contacts_filter"/> 11 12 <Button id="@+id/go" 13 android:layout_width="wrap_content" android:layout_height="wrap_content" 14 android:text="@string/go"> 15 <requestFocus /> 16 </Button> 17 18 </LinearLayout> |
|
Listing 2: Java-Code für |
|---|
01 package com.google.android.samples.app;
02
03 import android.app.Activity;
04 import android.content.ComponentName;
05 import android.content.Context;
06 import android.os.DeadObjectException;
07 import android.os.Bundle;
08 import android.view.View;
09 import android.view.View.OnClickListener;
10 import android.widget.Button;
11
12 import com.google.android.samples.R;
13
14 public class ContactsFilter extends Activity {
15 @Override
16 protected void onCreate(Bundle icicle) {
17 super.onCreate(icicle);
18
19 setContentView(R.layout.contacts_filter);
20
21 // Watch for button clicks.
22 Button button = (Button)findViewById(R.id.go);
23 button.setOnClickListener(mGoListener);
24 }
25
26 private OnClickListener mGoListener = new OnClickListener() {
27 public void onClick(View v) {
28 startInstrumentation(newComponentName(ContactsFilter.this,
ContactsFilterInstrumentation.class), null,null);
29 }
30 };
31 }
|
Die folgende Codesequenz definiert ein Button-Objekt, wobei die ID des Button-Widget aus der XML-Datei angegeben ist, und setzt die Referenz zum Listener, den das System bei einer Statusänderungen aufruft:
Button button = (Button)U findViewById(R.id.go); button.setOnClickListener(mGoListener);
Wer sich etwas Arbeit sparen möchte, erstellt mit Hilfe des frei zugänglichen Droid Draw [13] die Oberfläche im Browser oder mit der lokalen Variante, die für Linux, Mac OS X und Windows zur Verfügung steht. In kurzer Zeit entwickelte sich dieses Tool zu einer ernst zu nehmenden Hilfe.
Es hat nicht lange gedauert, bis erste Entwickler sich der Android-Sourcen [14] annahmen und sie auf diverse Hardware portierten. Derzeit basiert der Kernel auf Linux 2.6.23, als Zielhardware soll es eine ARM-Umgebung sein. Die notwendige Toolchain (ARM EABI, IA32 GNU/Linux) findet sich bei Codesourcery [15]. Prinzipielle Informationen zur ARM-Toolchain gibt es bei Macrobug [16].
Auf der Basis von Scratchbox und Qemu lassen sich so erste Schritte in einer virtuellen ARM-Umgebung gehen, ohne die passende Hardware aus der Schublade ziehen zu müssen. Es hat auch nicht lange gedauert, bis die Busybox [17] fertig war.
Hardware-Bausatz
Letztlich will aber jeder Entwickler das Ergebnis seiner Mühen auf realer Hardware zum Funkeln bringen. Erste offizielle Android-Produkte sollen zwar bereits in diesem Jahr erhältlich sein, jedoch können Entwickler sich auch mit einem, anfangs sicherlich noch holprigen, Port auf Handhelds und PDAs versuchen.
Ein Beispiel für einen Port auf den Sharp Zaurus SL-C760 wird in diesem Blog [18] dokumentiert. Wie Android auf ein Xscale-Evaluationsboard gelangt, zeigt [19]. Ähnlich nützliche Informationen finden sich unter [20] auch für einen ansatzweise gelungenen Brückenschlag hin zu einem ARM-System. (uba)
