Android ist ein Linux-Betriebssystem, bei dem aber typische für den Desktop-Einsatz bekannte Erweiterungen fehlen, beispielsweise das X Window System. Android bietet die von Linux her gewohnte Prozessverwaltung. Sie können sich beispielsweise mit einem Prozess-Manager wie Astro alle Prozesse anzeigen lassen (die wie unter Linux gewohnt als PIDs bezeichnet werden) und jeden Prozess einzeln beenden. Findige Linux-Tüftler haben zudem ihre eigenen Varianten von Android entwickelt und zum Download bereitgestellt, beispielsweise CyanogenMod.
Android verwendet den Linux-Kernel 2.6x. Als Smartphone-Betriebssystem ist Android optimiert für das Zusammenspiel mit GPS und Bewegungssensoren sowie mit Telefonie-Funktionen und für die Bedienung durch einen (Multi-)Touchscreen. Dafür stehen dann die entsprechenden Bibliotheken und Schnittstellen zur Verfügung.
Genauso wie Sie auf einem Desktop-Linux-System nicht sofort mit der Kommandozeile-Ebene von Linux konfrontiert werden, weil oberhalb von Linux eine grafische Bedienoberfläche wie beispielsweise Gnome oder KDE liegt, so präsentiert sich auch Android nicht im düsteren "Kommandozeilen-Schwarz", sondern besitzt eine ansprechende grafische Bedien-Oberfläche, die als Touchscreen funktioniert (in der Regel handelt es sich dabei um einen kapazitiven Touchscreen bei Einsteigergeräten aus der Tablet-PC-Ecke kommen aus Kostengründen aber auch noch resistive Touchscreens zum Einsatz).
Dieser Artikel basiert auf einem Beitrag der Schwesterpublikation PC-Welt .
Ein Android, verschiedene Oberflächen
Allerdings konnte sich die Standard-Oberfläche von Android, wie sie Google mitliefert, bisher nicht so recht durchsetzen. Die meisten Smartphone-Produzenten hübschen Ihre Androiden mit einer individuellen Lösung auf, die sich intuitiver bedienen lässt (oder bedienen lassen soll). Sicherlich verfolgen die Smartphone-Hersteller damit auch das Eigeninteresse, die Kunden etwas mehr an sich und an ihre Smartphones zu binden, wenn sie die User an eine bestimmte Oberfläche gewöhnen.
Das führt aber zwangsläufig dazu, dass Android nicht auf allen Smartphones identisch aussieht, was auf Android-Einsteiger verwirrend wirkt. So verwendet HTC die Oberfläche Sense, Motorola setzt auf Motoblur, Samsung auf Touchwiz und Garmin/Asus auf Breeze.
Ein Android-Smartphone wird allerdings nicht nur über den Touchscreen beziehungsweise über die Slider-Tastatur (wie beim Motorola Milestone aka Droid) bedient, sondern besitzt meist auch noch einige Standardtasten unterhalb des Bildschirms für "Home", "Menü" und "Zurück".
Die Geschichte von Android
Google stellte das Android-Betriebssystem im Jahr 2007 vor. Und betrat damit Neuland, denn weder hatte Google bis dahin ein Betriebssystem entwickelt (Chrome OS folgte erst viel später und ist bis heute nicht marktreif) noch sich auf dem Smartphone-Sektor hervorgetan, den seit Anfang 2007 Apple mit dem revolutionären iPhone aufmischte.
Eine Zeitlang hatten Gerüchte um ein Google Phone die Branche bewegt (das als Google Nexus One dann schließlich doch noch kam; mittlerweile hat Google das Nexus One aber beerdigt), doch mit dem Smartphone-OS Android, das allen interessierten Handy-Herstellern zur Verfügung gestellt wird, überraschte Google den Markt. Android ist allerdings keine Erfindung von Google, sondern wurde ursprünglich von der kleinen US-Firma Android entwickelt, die Google 2005 aufkaufte. Seitdem entwickelt Google Android energisch weiter.
Das eigentliche Smartphone-Betriebssystem wird ergänzt durch ein Software Development Kit (SDK) und durch einen Android Market (zu dem es noch diverse deutlich kleinere Download-Markets unter anderem von den verschiedenen Hardware-Herstellern gibt. Beispiele sind Samsung und Archos. Außerdem kann man auch APK-Dateien (apk steht für Android Package; mehr dazu später) direkt auf den Rechner herunterladen, vom PC auf das Smartphone überspielen und dort installieren). Erst durch den Market wird Android zu einem ernstzunehmenden Konkurrenten für Apples iPhone mit seinem gigantischen App Store. Denn die Leistungsfähigkeit eines modernen Smartphones steht und fällt nun einmal mit seiner Erweiterbarkeit durch Apps. Auf diesem Gebiet hinken die Platzhirsche Windows Mobile, Symbian, Nokia und Blackberry, aber auch die Newcomer WebOS und Bada den beiden App-Giganten Apple und Google weit hinterher.
Android steht unter der Open Source Lizenz, der Quellcode ist also frei zugänglich und kostenlos erhältlich. Google und alle Unternehmen, die an Android mitarbeiten - in erster Linie sind das die Hersteller von Smartphones, die Netzbetreiber sowie die Chip-Hersteller - sind in der Open Handset Alliance zusammengeschlossen. Android kann also auf mächtige Unterstützung zählen, während Apples iPhone samt iOS allenfalls Unterstützung durch Mobilfunk-Provider erhält. Andererseits ist Android nicht die einzige Plattform, die von vielen Smartphone-Herstellern unterstützt wird. Denn viele Smartphone-Hersteller, die bei Android mit an Bord sind, sind auch mit etlichen Windows Mobile-Geräten auf dem Markt vertreten. Bestes Beispiel hierfür ist HTC, das sogar seine Sense-Oberfläche auf beiden Plattformen anbietet.
Android wird Realität
Bis das erst Android-Smartphone auf den Markt kam, dauerte es aber noch einige Zeit: Am 23. September 2008 stellte Google das T-Mobile G1 vor, in Deutschland war das vom taiwanischen Unternehmen HTC entwickelte Gerät ab dem 2. Februar 2009 erhältlich. Mittlerweile gibt es eine Vielzahl von Smartphones mit Android-Betriebssystem: Einsteigergeräte wie das T-Mobile Pulse, Highend-Geräte wie HTC Desire und Samsung Galaxy S, spezialisierte Zwitter wie das Garmin Nüvifone A50 und mittlerweile auch einige Nicht-Smartphones, vor allem Tablets.
Jede Android-Version hat neben ihrer Versionsnummer einen englischsprachigen Spitznamen, der eine Süßspeise darstellt. Am 30. April 2009 erschien Android 1.5 (Codename Cupcake). Es brachte erstmals eine virtuelle Tastatur für Android-Smartphones mit. Android-Smartphones lassen sich ab Android 1.5 übrigens auch ohne Google-Konto nutzen. Damit entfiel eine wichtige Einschränkung. Allerdings gilt nach wie vor die Faustregel: wer ein Android-Smartphone wirklich umfassend nutzen will, braucht einen Google-Account. Allein die Möglichkeit, damit Pushmail, einen rund um den Globus verfügbaren Kalender und überall verfügbare Kontakte nutzen zu können, die bei jeder Änderung an irgendeinem PC oder Smartphone mit Google-Konto automatisch synchronisiert werden, ist ein Killer-Argument für die Symbiose aus Android-Smartphone und Google-Account.
Am 15. September 2009 stellte Google dann Android 1.6 (Codename Donut) vor. Zusammen mit einem komplett neuen Android Market. Android 1.6 befindet sich bis heute auf vielen neuen(!) Android-Geräten, beispielsweise auch auf den Dell Streak. Für Kunden mag das ärgerlich erscheinen, dass sie ein neues Gerät mit einer ziemlich alten Android-Version erwerben. Doch der Grund für diese merkwürdige Kombination scheint der langwierige Zertifizierungsvorgang durch Google zu sein. Um ihre neuen Geräte schneller auf den Markt zu bekommen, installieren die Hersteller dann lieber das bereits zertifizierte Android 1.6 also bis zum Abschluss der Zertifizierung von Android 2.1 zu warten.
Am 26. Oktober 2009 erschien Android 2.0 (Codename Eclair) mit neuer Bedienoberfläche und Kontaktverwaltung, einem verbesserten Browser und Unterstützung für Microsoft Exchange. Letzteres macht Android-Smartphones deutlich Business-tauglicher. Zudem sind nun verschiedene Bildschirmgrößen und -Auflösungen möglich. Wichtig war das Bugfix-Release Android 2.0.1 mit verbesserter Performance und neuem Lock-Screen.
Android 2.1 (Codename Éclair) ermöglichte erstmals Live-Wallpaper. Android 2.2 (Froyo) wiederum brachte Flash-Support, integrierte Hotspot-Funktion, JIT-Compiler und die Möglichkeit, Apps auf der SD-Karte zu speichern.
Das derzeit in der Entwicklung befindliche Android 3.0 (Codename Gingerbread) verspricht Unterstützung des WebM-Formats, eine neue Oberfläche und ermöglicht größere Displays.
Die Android-Architektur
Android basiert auf einem Vier-Schichtenmodell: 1. Dem Linux Kernel mit den Hardwaretreibern, 2. der Android Runtime mit der Dalvik Virtual Machine und den Java Core Libraries sowie den Standard-Bibliotheken, 3. dem Application Framework und 4. den eigentlichen Anwendungen.
Wie von Linux gewohnt übernimmt der Kernel die Speicher- und, Prozessverwaltung. Der Kernel verwaltet die Treiber, beispielsweise für den Bildschirm, die Kamera oder die Lautsprecher und das Wlan-Modul sowie für die Tastatur und kümmert sich um die Netzwerkanbindung und um das Power-Management.
Über dem Kernel befinden sich als nächste Schicht die Bibliotheken (dabei handelt es sich sowohl um klassische Java-Bibliotheken als auch um neue Android-typische Bibliotheken sowie einige andere Bibliotheken) und die Android-Lautzeitumgebung (Runtime). Diese in C/C++ erstellten Bibliotheken stellen Entwicklern fertige Methoden und Eigenschaften zur Entwicklung bereit. Zum Beispiel für den Browser (Webkit), Datenbanken (SQLite), Multimedia, Verschlüsselung, Grafik und Touchscreen. Die Android-Runtime wiederum stellt die Core-Bibliotheken mit der gesamten Java-API (Programmierschnittstelle) und - ganz wichtig - die virtuelle Maschine von Android, die sich grundlegend von der gewohnten Java Virtual Machine (JVM) unterscheidet, zur Verfügung.
Stichwort: WebKit ist eine Open Source Browser Engine, die aus dem KHTML-Code des Linux-Projekts KDE entstanden ist. WebKit wird für den Browser Safari von Apple iOS, den Browser von Android und für Blackberry OS 6 sowie von Nokia verwendet.
Über den Bibliotheken und der Android-Runtime liegt das Application Framework (Anwendungsrahmen). Es beinhalten unter anderem den Activity Manager (der die Anwendungen verwaltet und deren Lebenszyklus steuert), den Window Manager, Content Providers (für den Austausch und den Zugriff auf Daten von anderen Anwendungen, zum Beispiel Kontakte) und das View System (Eingabefelder, Textboxen, Buttons etc.), aber auch den Package Manager sowie die Verwaltung von Ressourcen wie Grafiken (Resource Manager). Sowie die gesamten Dienste für Telefonie (Telephony Manager) und Ortung (Location Manager). Hier ist auch der Notification Manager zu erwähnen, der es Apps ermöglicht, Informationen in der Statusleiste anzuzeigen. Dass Application Framework ist in Java programmiert.
Die oberste Schicht ist dann das, was der Android-Anwender sieht. Also die einzelnen Apps, die Kontakte, das Telefon, Mailprogramm, Kalender, Webbrowser und so weiter. Alle diese Anwendungen sind bisher weitgehend in Java programmiert, Java ist die Entwicklersprache für Android-Apps schlechthin. Allerdings besteht auch die Möglichkeit, mit C und C++ Apps zu entwickeln. Google stellt hierfür das Android NDK bereit.
Android Runtime und Dalvik Virtual Machine
Jede Android-Anwendung läuft mit einem eigenen Prozess (den Sie über ein geeignetes Tool wie beispielsweise den Prozessmanager im Astro-Datei-Manager anzeigen und auch beenden können) und mit einer eigenen Instanz in der virtuellen Maschine von Android. Einfacher formuliert: Jede App läuft in einer eigenen virtuellen Maschine. Es laufen also immer gleichzeitig mehrere Instanzen der Dalvik VM auf einem Android-Smartphone. Jeder Prozess läuft zudem unter dem Benutzer, der für die jeweilige Anwendung angelegt wird. Wird die Anwendung beendet, dann wird auch der Prozess beendet.
Die virtuelle Maschine von Android ist eine speziell für die Erfordernisse des Smartphone-Betriebssystems entwickelte Java Virtual Machine (JVM), genannt die Dalvik Virtual Machine. Die Dalvik VM (Dalvik ist eine Stadt in Island, wo Vorfahren von Dan Bornstein, dem Entwickler der Dalvik VM, lebten) führt Dateien im Dalvik Executable-Format (.dex) aus. Diese sind so beschaffen, dass sie möglichst wenig Arbeitsspeicher belegen. Denn Speicher ist in Smartphones nun einmal knapp. Dazu vermeidet sie so weit als möglich Wiederholungen.
Zudem kommt die Dalvik VM gut mit schwachen Prozessoren zurecht, was ebenfalls wichtig ist für den Einsatz auf Smartphones. Und sie ist optimiert für ein Betriebssystem, das auf keine SWAP-Partition (Auslagerungs-Partition. Unter Windows entspricht ihr die Auslagerungs-Datei) zugreifen kann. Zudem wurde bei der Dalvik VM der Strombedarf berücksichtigt, schließlich kommt sie auf Akku-betriebenen Geräten zum Einsatz.
Außerdem will Google durch den Einsatz der Dalvik VM Patent-Probleme mit Oracle vermeiden und Lizenzkosten sparen. Oracle hat bekanntlich Sun aufgekauft. Sun hat die Programmiersprache Java erfunden und bis heute entwickelt. Allerdings hat der Erfolg von Android Oracle aufgeweckt: Der Datenbank-Riese, dem Java gehört, hat Google wegen Patentverstoßes verklagt: Laut Oracle soll Google bei der Entwicklung seines mobilen Betriebssystems Android wiederholt Patente rund um Java verletzt haben. Zitat der Sprecherin Karen Tillman: "Google hat wissentlich, direkt und wiederholt Oracles Java-bezogenes Eigentumsrecht verletzt".
Nun stellt sich die Frage: was macht eigentlich die Dalvik VM genau? Und wie unterscheidet sie sich von einer normalen Java Virtual Machine auf dem PC?
Unterschiede zwischen JVM und Dalvik VM
Programmiersprachen unterscheidet man normalerweise zwischen interpretierten und kompilierten Sprachen. C++ ist ein typisches Beispiel für eine Compiler-Sprache: Sie erstellen Ihren Quellcode und der Compiler wandelt diesen in für den PC ausführbaren Maschinen-Code um. Letzterer wird dann ausgeführt, wenn Sie beispielsweise unter Windows eine .exe-Datei starten. Das geht dann sehr schnell. Bei PHP, einer typischen Interpreter-Sprache, wird dagegen nichts vorab kompiliert, sondernd der Quellcode wird zur Laufzeit (also während der Ausführung) vom Interpreter abgearbeitet. Deshalb dauert die Ausführung eines derartigen Programmes etwas länger.
Java (und auch die Microsoft .Net-Framework-Programmiersprache C#) gehen anders vor. Java kompiliert zunächst den Quellcode und erstellt daraus einen Bytecode (bei C+ heißt dieser Zwischencode Common Intermediate Language). Dieser Bytecode wird dann zur Laufzeit (also bei der Ausführung des Programms) in der Java-Laufzeitumgebung ausgeführt und von der Java Virtual Machine (die Bestandteil der Java-Runtime ist) interpretiert. Die viel gelobte Plattform-Unabhängigkeit von Java wird dadurch möglich, dass für alle gängigen Betriebssysteme eine Java-Runtime mit JVM existiert.
Die konkrete Vorgehensweise bei der Entstehung eines Java-Programmes sieht also folgendermaßen aus: Der Programmierer erstellt mit einem Editor Quelltext (diese Datei hat die Endung .java) und kompiliert den Quelltext zu Bytecode (diese Datei trägt die Endung .class, weil es sich dabei immer um Klassen handelt - ein Java-Programm besteht, da Java eine streng objektorientierte Programmiersprache ist, immer aus Klassen, mindestens aus einer einzigen). Diese .class-Dateien werden dann gestartet und interpretiert (daneben gibt es aus Performance-Gründen auch die Möglichkeit, Bytecode sofort zu kompilieren: Die so genannte HotSpot-Technik). Soweit zur Vorgehensweise beim "typischen" Java auf einem Desktop-PC, einem Notebook oder einem Server (wobei bei der Serverprogrammierung wieder spezielle Begriffe wie Servlets oder Java Server Pages hinzukommen).
Bei Android sieht die Entwicklung von Programmiercode folgendermaßen aus: Der Developer erstellt Quellcode (.java), der dann mit einem normalen Java-Compiler (javac) in Byte-Code kompiliert wird (.class). Diese Klassen werden dann durch das dx-Tool aus dem Android SDK vom .class-Format in das .dex-Format ("Dalvik Executable") umgewandelt, es handelt sich beim Bytecode, den die Dalvik VM im Anschluss ausführt, also nicht mehr um Java-Bytecode, sondern um Dalvik-Bytecode. Dieser Vorgang heißt Cross-Compiling. Die Dalvik VM führt dann zur Laufzeit den Dalvik-Bytecode aus.
Um Speicherplatz zu sparen, werden dabei mehrere .class-Dateien zu einer einzigen .dex-Datei zusammengefasst. Diese .dex-Dateien werden dann in .apk-Dateien (Android Package) gepackt und ein Manifest hinzugefügt. Diese apk-Dateien werden schließlich auf dem Android-Smartphone installiert und die App dann ausgeführt.
Ein weiterer Unterschied zwischen einer JVM, wie sie auf dem Desktop-PC zum Einsatz kommt, und der Dalvik VM: Die klassische Java VM basiert auf einem Kellerautomaten und nutzt damit nicht die Tatsache aus, dass Prozessoren in der Regel Register haben. Die Dalvik VM ist dagegen eine Registermaschine und damit optimiert für die Architektur heutiger Prozessoren wie die ARM-CPUs, die eben Registermaschinen sind. Solche Registermaschinen besitzen eigene besonders schnell zugreifbare Speicherzellen (die Register), es handelt sich also um Mikroprozessoren mit Zwischenspeicher direkt im Prozessor.
Der Bytecode der Dalvik VM ist nicht kompatibel zu Bytecode von JVM. Seit Android 2.2 besitzt die Dalvik VM zudem einen JIT-Compiler ("Just In Time"). Ein Just-in-time-Compiler übersetzt zur Laufzeit und erst bei Bedarf den Bytecode direkt in Maschinen-Code. Das bietet gegenüber dem Interpreter einen Geschwindigkeitsvorteil.
So funktioniert eine Android-App
Wer verstehen will, wie eine Android-App funktioniert, muss einige Schlüsselbegriffe kennen, die die Bestandteile einer Android-App definieren: Activities, Intents, Services und Content Provider.
Nehmen wir Activity: Eine Activity ist das, womit der Anwender auf seinem Smartphone interagiert beziehungsweise was der Smartphone-Besitzer sieht. Jede Bildschirmseite hat eine eigene Activity, die deren Funktionalität festlegt. Allen Activities entsprechen Views, die das Layout definieren und als Bildschirmmasken bezeichnet werden können. Views können bequem in XML definiert werden und müssen nicht in Java selbst programmiert werden (wie es sonst bei der klassischen Java-Programmierung mit Swing oder AWT der Fall ist und was grundsätzlich auch bei einer Android-App möglich ist). Das oben erwähnte Application Framework stellt die Views für die Anwendungen bereit.
Jede App mit einer grafischen Oberfläche hat mindestens eine Activity. Jede Activity kann verschiedene Zustände haben:
active/running: Die Activity wird ausgeführt und die View auf dem Gerät dargestellt.
Paused: Die Activity ist pausiert und wird von einer anderen aktiven Activities teilweise überdeckt. Status- und Benutzerinformationen werden zwischengespeichert.
Stopped: Die Ansicht einer Activity wird durch eine andere Activity komplett überdeckt. Die Statusinformationen werden gespeichert.
Services sind wiederum die Hintergrunddienste, beispielsweise ein im Hintergrund ablaufender Download oder der Media Player, der gerade ein Lied abspielt. Zwischen den Services, die es lokal oder via Remote gibt, und dem Benutzer findet keine Interaktion statt.
Der Content Provider enthält Daten, die andere Anwendungen abrufen und nutzen können, beispielsweise Kontaktdaten. Für Lese- und Schreibzugriffe können Linux-typisch Zugriffsbeschränkungen festgelegt werden.
Mit den Broadcast Receivern kann eine App auf Systemereignisse lauschen und dann darauf reagieren. Und dann gibt es noch Intent: Damit werden Nachrichten zwischen den Anwendungen bezeichnet.
Activities, Prozesse, Ressourcen und Bibliotheken
Alle Activities einer Anwendung befinden sich in derselben Dalvik VM, jede Anwendung läuft in einer eigenen VM mit einem eigenen Prozess und besitzt einen eigenen Adressraum. Das kostet zwar mehr Systemressourcen, ist aber sicherer: Die Anwendungen teilen sich keinen gemeinsamen Speicher, ein sterbender Prozess kann keine andere App beeinträchtigen.
Die Prozesse sind abgestuft priorisiert. Der aktive Prozess hat die höchste Priorität, danach kommen sichtbare Prozesse oder laufende Server mit hoher Priorität und schließlich Hintergrundprozesse und leere Prozesse mit niedrigster Priorität.
Die Ressourcen, wie beispielsweise Bilder oder Texte (im Stringformat) und zum Beispiel auch Farbinformationen werden mit XML verwaltet. Alle Ressourcen liegen zentral unter res/ im Projektverzeichnis. Beim Kompilieren werden daraus Binärdaten. Programmier-Logik in Java und Layout in XML sind also vollständig getrennt.
Zu den wichtigsten Bibliotheken gehört beispielsweise SQLite, die Datenbank von Android. Weil Ressourcen-Sparen wichtig ist bei Smartphones, verzichtet Google bei Android auf eine Riesen-Datenbank mit eigenem Datenbankserver wie beispielsweise MySQL und setzt stattdessen das schlanke SQLite ein, das ohne Datenbankserver auskommt: Jede Datenbank entspricht einer Datei. Übrigens: Mozilla Firefox nutzt ebenfalls SQLite.
Das View-System verwaltet das Userinterface und die Events. Der Notification Manager informiert den Anwender auf verschiedene Weise. Typisch sind Informationen in der Statuszeile des Bildschirms. Er kann aber auch die Hintergrundbeleuchtung oder den Sound beeinflussen oder einen Vibrationsalarm erzeugen. Der Location Manager ist ein ganz typischer Bestandteil des Application Frameworks von Android. Er kümmert sich zum Beispiel um die Standortbestimmung mit Hilfe des GPS-Signals.
App-Entwicklung mit Java
Wer Apps für den Android-Market von Google entwickeln will, muss sich dafür registrieren. Für die Identitäts-Überprüfung fällt eine einmalige Gebühr von 25 US-Dollar an. Von den Einnahmen kostenpflichtiger Apps kassiert Google 30 Prozent. Das Geschäftsmodell von Google ist also annähernd identisch mit dem von Apple und dessen App Store.
Java ist die Programmiersprache für Android Apps, Eclipse die bevorzugte Entwicklungsumgebung. Allerdings greift man bei der Entwicklung auf viele in C/C++ geschriebene Bibliotheken zu, die besonders für Bereiche zur Verfügung stehen, bei denen die Ausführungsgeschwindigkeit wichtig ist. Beispielsweise Webkit für den Browser, die SQLite-Datenbank und die 3D-Grafikbibliothek. Wichtig für Programmierer: Mit jeder neuen Android-Version steigt der API-Level und die Anzahl der verfügbaren Bibliotheken. Zudem müssen Programmierer seit Android auch unterschiedliche Bildschirmgrößen und -Auflösungen berücksichtigen. Ebenfalls nicht unproblematisch: Android-Developer müssen Ihre Apps für unterschiedliche Hardware-Plattformen entwickeln.
Damit man eigene Android-Apps programmieren kann, benötigt man neben dem SDK für Java (das bei einer Installation von Eclipse ja mit dabei ist) noch das SDK für Android von Google. Google stellt Entwicklern aber nicht nur das SDK zur Verfügung, sondern auch Tutorials sowie Codebeispiele und gibt Tipps und Tricks. Eine Dokumentation finden Sie unter developer.android.com.
Eclipse ist wie bereits erwähnt die Entwicklungsumgebung schlechthin für Android-Entwickler. Wie so oft bei Eclipse sorgt eine kostenlos erhältliche Erweiterung dafür, dass aus dem Standard-Eclipse die ideale IDE für Android-Programmierer wird: Das so genannte ADT Plugin. Eclipse ADT bringt übrigens auch einen Editor zur Gestaltung der App-Oberfläche mit. Die Daten für das App-User-Interface werden damit wie bereits erwähnt in XML festgelegt.
Grundsätzlich kann man aber wie gehabt auch ohne spezielle IDE einfach nur mit einem Text-Editor samt Android Debugger, Java-Compiler und Cross-Assembler entwickeln, es ist halt nur mühsamer. Mit dem Android Emulator und anderen Simulations-Tools können Sie Ihre App unter realistischen Bedingungen testen, also beispielsweise den SMS-Empfang nachstellen und die Positionsbestimmung via GPS-Daten simulieren.
Wenn die App mit ihren dex-Dateien (mit dem Bytecode für die Dalvik VM) fertig ist, wird sie zusammen mit einem Manifest (AndroidManifest.xml) sowie allen nötigen Ressourcen (Bilder, Layout-Definitionen, sonstige Medien) im XML-Format in einem APK-Archiv gepackt und signiert. Im Manifest legt der Programmierer zum Beispiel fest, welche Versionsnummer die App hat, ab welcher Android-Version die App lauffähig ist und aus welchen Komponenten sich eine App zusammensetzt (genauer gesagt macht das Eclipse automatisch bei der Anlage eines Projekts) sowie - wichtig - welche Berechtigungen die App benötigt. Signieren bedeutet, dass die App eine digitale Unterschrift in Form eines Zertifikats bekommt. Das geht allerdings auch mit nicht beglaubigten Zertifikaten, man weiß also auf der Basis der Signatur nicht sicher, ob der Programmierer auch wirklich der ist, als der er sich ausgibt. Der eigentliche Sinn der Signierung besteht vielmehr darin zu zeigen, dass alle Anwendungen mit dem gleichen Zertifikat vom gleichen Hersteller stammen. Die Signierung hat bei Android also weniger Aussagekraft als bei Apple, wo die Identität des Entwicklers überprüft wird.
Übrigens: Wie bei jeder Smartphone-Plattform können Sie auch plattformübergreifend mit Javascript, HTML und CSS programmieren.
Wichtig: Bevor man mit der Programmierung anfängt, muss man sich überlegen, zu welchen Android-Versionen die eigene App kompatibel sein soll. Wenn Sie die allerneuesten APIs und Bibliotheken nutzen wollen, schließen Sie zwangsläufig Besitzer älterer Android-Geräte aus. In Eclipse mit Android-Plugin legen Sie diese Kompatibilität bei jedem Projekt von Anfang an mit "Build Target" fest.
Sicherheit unter Android
Jede Anwendung bekommt bei der Installation eine unveränderliche UserID, ist also ein eigener User mit einem eigenen Prozess, einer eigenen Dalvik VM, einem eigenen Bereich im Hauptspeicher des Smartphones (HEAP) und einen eigenen Bereich im Dateisystem. Nur der Prozess mit der entsprechenden UserID bekommt Zugriff auf die Datei mit der App. Eine App kann also nicht auf die Daten und Dateien anderer Apps zugreifen. Dateien lassen sich via Flags für schreiben und lesen freigeben. Wenn eine Anwendung bestimmte Rechte auf Dienste wie Netzwerkkommunikation oder Telefon benötigt, müssen diese im Manifest AndroidManifest.xml definiert werden. Auf diese Rechte wird der Anwender bei der Installation hingewiesen.
Es ist deshalb wichtig, dass sich der Smartphone-Besitzer bei der Installation einer neuen App genau durchliest, welche Rechte eine App beansprucht. Bei einer App, die beispielsweise nur Texte zum Unterwegs-Lesen bereit stelle (quasi ein eBook), besteht keine Notwendigkeit für den Zugriff auf persönliche Daten, Kontakte oder Telefon. Ein Beispiel dafür sind diverse englischsprachige Bibeleditionen (die überwiegend von den Zeugen Jehowas zu stammen scheinen), die Zugriff auf Systemprotokolle und andere wichtige Informationen benötigen. Ein User brachte das in einem Kommentar zu einer solchen Bibel-App treffend auf den Punkt: "gepriesen sei der Name des Herrn. Aber wozu SEIN Wort Zugriff auf meine Systemprotokolle braucht, ist mir schleierhaft".
Eine verschlüsselte Datenübertragung über SSL ist möglich. Daten lassen sich zudem auf Anwendungsebene verschlüsseln.
Jede Android-App läuft wie bereits erwähnt in einer eigenen VM-Instanz und in einer eigenen Sandbox, also in einer geschlossenen Umgebung. Aus dieser Sandbox heraus kann sie nicht das Android-System oder andere Apps kompromittieren. Die Anwendung hat keinen Zugriff auf systemwichtige Daten, ausgenommen solche, die Sie bei der Installation ausdrücklich dafür freigegeben haben. Stürzt die App ab, dann betrifft das nicht das übrige System, das Android-Smartphone sollte weiter funktionieren. Jede Android-App lässt sich zudem über ihre Prozess-ID (PID) separat beenden.
Übrigens: Das Sandbox-System können Sie bei gerooteten Android-Smartphones aushebeln. Dann ist alles möglich, nicht nur Sie haben dann Vollzugriff (wie der Administrator unter Linux, der dort Root heißt), sondern eben auch eine Malware. (mb)