Vergleich Mobiler Plattformen

Großer Beleg

Vergleich von Plattformen für Mobile Geräte

bearbeitet von

René Dienel

geboren am 27.08.1981 in Zittau

Matrikelnummer: 2928117

Technische Universität Dresden

Fakultät Informatik Institut für Systemarchitektur Professur Rechnernetze

Betreuer: Dr.-Ing. Thomas Springer Lehrstuhlinhaber: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Bearbeitungszeit: 14.05.2008 - 14.02.2009

Inhaltsverzeichnis 1 Einleitung...... 3 1.1 Mobile Geräte...... 3 1.2 Limitierungen...... 4 1.3 Plattformen...... 4 1.4 Aufbau der Arbeit...... 5 2 Plattformen...... 6 2.1 Kriterienkatalog...... 6 2.1.1 Architektur...... 6 2.1.2 Laufzeitumgebung...... 6 2.1.3 Speicherverwaltung...... 6 2.1.4 Grafische Benutzungsoberfläche...... 7 2.1.5 Persistente Datenspeicherung...... 7 2.1.6 Multimediaunterstützung...... 7 2.1.7 Kommunikationsschnittstellen...... 7 2.1.8 Sicherheitsmechanismen...... 7 2.1.9 Native Programmierung ...... 7 2.1.10 Entwicklungsumgebung...... 7 2.1.11 Besonderheiten...... 8 2.2 Symbian...... 9 2.2.1 Java Micro Edition...... 10 2.2.2 Architektur...... 10 2.2.3 Laufzeitumgebung...... 13 2.2.4 Speicherverwaltung...... 14 2.2.5 Grafische Benutzungsoberfläche...... 15 2.2.6 Persistente Datenspeicherung...... 16 2.2.7 Multimediaunterstützung...... 17 2.2.8 Kommunikationsschnittstellen...... 18 2.2.9 Sicherheitsmechanismen...... 20 2.2.10 Native Programmierung...... 21 2.2.11 Entwicklungsumgebung...... 21 2.2.12 Besonderheiten der Plattform...... 22 2.3 Windows Mobile...... 23 2.3.1 .NET Compact Framework ...... 23 2.3.2 Architektur...... 24 2.3.3 Laufzeitumgebung...... 25 2.3.4 Speicherverwaltung...... 26 2.3.5 Grafische Benutzungsoberfläche...... 27 2.3.6 Persistente Datenspeicherung...... 28 2.3.7 Multimediaunterstützung...... 29 2.3.8 Kommunikationsschnittstellen...... 30 2.3.9 Sicherheitsmechanismen...... 30 2.3.10 Native Programmierung...... 31 2.3.11 Entwicklungsumgebung...... 31 2.3.12 Besonderheiten der Plattform...... 32 2.4 Android...... 33 2.4.1 Android-Plattform...... 33 2.4.2 Architektur...... 34 2

2.4.3 Laufzeitumgebung...... 37 2.4.4 Speicherverwaltung...... 39 2.4.5 Grafische Benutzungsoberfläche...... 40 2.4.6 Persistente Datenspeicherung...... 42 2.4.7 Multimediaunterstützung...... 43 2.4.8 Kommunikationsschnittstellen...... 43 2.4.9 Sicherheitsmechanismen...... 44 2.4.10 Native Programmierung...... 44 2.4.11 Entwicklungsumgebung...... 44 2.4.12 Besonderheiten der Plattform...... 45 2.5 Vergleich der Plattformen...... 46 3 Referenzanwendung...... 48 3.1 Konzept...... 48 3.2 Umsetzung...... 48 3.3 Webservice...... 49 3.4 Java ME Klient...... 50 3.5 .NET CF Klient...... 53 3.6 Android Klient...... 55 3.7 Auswertung...... 57 4 Ausblick...... 59 Literaturverzeichnis...... 60 Abbildungsverzeichnis...... 64 Abkürzungsverzeichnis...... 65 Einleitung 3

1 Einleitung Mobiltelefone und Digitale Assistenten haben mittlerweile Einzug in unseren Alltag gefunden. Seit Mitte April gibt es in Deutschland über 100 Millionen Mobilfunkan- schlüsse [BIT07]. Statistisch besitzt jeder fünfte Deutsche zwei Mobiltelefone. Diese werden inzwischen nicht mehr nur für ihren vorgesehenen Zweck verwendet. Tech- nologische Entwicklungen haben die Leistungsfähigkeit der Geräte und ihre Eigen- schaften enorm verbessert. Sie werden heutzutage als Digitalkamera oder Musik- player verwendet. Das Ziel des Mobile Computing, Informationen zu jeder Zeit und an jedem Ort abrufen zu können, wird durch neue Kommunikationstechnologien erreicht. Neue Dienste für mobile Geräte, z.B. Stadtführung, Navigation oder Fahrplanaus- kunft, fördern die Entwicklung von innovativen Anwendungen. Der Markt wird von verschiedenen geschlossenen oder lizenzpflichtigen Systemen dominiert. Die Pro- grammierung von Anwendungen auf diesen ist sehr aufwendig oder nicht möglich. Die Systeme nutzen ihre eigenen Bibliotheken und unterstützen nur bestimmte Pro- grammiersprachen. Die Vielzahl der Geräte und die große Unterschiede in der Leis- tungsfähigkeit, der Größe des Bildschirms und der verfügbaren Eingabegeräte, er- schweren die gleichzeitige Entwicklung für eine große Anzahl an Geräten. Die An- wendungen müssen für das jeweilige Umgebung angepasst werden. Einen Ausweg bilden die mobilen Plattformen, auf denen Anwendungen unabhängig vom Gerätetyp und Ausstattung ausgeführt werden. Einige Plattformen sind bereits weit verbreitet und erhalten seit kurzem Konkurrenz aus dem Open Source Bereich.

1.1 Mobile Geräte Mobile Geräte können anhand ihrer Funktion klassifiziert werden. Mobiltelefone bieten Kommunikationsmöglichkeiten, wie ein Festnetztelefon, während Digitale Assis- tenten als transportables Datenarchiv dienen. Die Technologien der beiden Klassen entwickelten sich unabhängig voneinander weiter. Inzwischen enthält jedes Mobiltelefon ein Adressbuch und Funktionen mit denen Textnachrichten versendet werden können. Der technologische Fortschritt ermöglich- te die Entwicklung von kleineren und leistungsfähigeren Geräten. Das speziell entwickelte Betriebssystem wurde um neue Anwendungen, wie Rechner, Spiele, Multime- diaplayer oder Webbrowser erweitert. Über die digitale Funkschnittstelle und das integrierte Modem werden Sprache, Videos und Bilder übertragen. Mittlerweile hat sich das Mobiltelefon zum Feature Phone entwickelt. Diese Geräte enthalten spezielle Funktionen, z.B. die integrierte Digitalkamera. Die heutige Generation hat sich von der reinen Sprachübertragung zur Datenkommunikation weiterentwickelt. Der Persönliche Digitale Assistent (PDA) verwandelte sich vom einfachen Termin- planer zu einem kompakten Taschencomputer. Dieser ist nicht größer als die Hand- fläche eines Menschen und dient der Verwaltung von elektronischen Dokumenten, Kontaktdaten und Terminen. Die gespeicherten Daten können überall abgerufen und verändert werden. Die digitalen Assistenten entwickelten sich zu leistungsfähigen Geräten mit neuen Eingabemöglichkeiten, großen Bildschirmen, größerem Speicher und wurden um drahtlose Kommunikationsschnittellen erweitert. Im Gegensatz zu den klassischen Mobiltelefonen verfügen sie über ein eigenes Betriebssystem, auf 4 Mobile Geräte dem zusätzliche Anwendungen installiert werden können. Aus den beiden unabhängigen Entwicklungszweigen bildete sich ein neuer Geräte- typ, das Smartphone. Dieser vereinigt die Funktionen der beiden Geräteklassen und verfügt über einen lokalen Speicher, höhere Rechenleistung und Multimediafunktio- nen. Der Austausch von Daten wird über die lokalen Verbindungsarten oder über die Verbindungsprotokolle des Mobiltelefons realisiert.

1.2 Limitierungen Im Vergleich zu Desktop-Computern sind die Ressourcen von mobilen Geräten ein- geschränkt. Die Beschränkungen sind im wesentlichen der Mobilität und der Größe des Gerätes geschuldet. Der Prozessor eines mobilen Gerätes arbeitet mit einer geringen Taktrate. Daher werden spezielle Aufgaben von zusätzlichen Mikrochips ausgeführt. Aufgrund der be- grenzten Rechenleistung sollten Berechnungen auf dem Gerät mit Bedacht ausge- führt und eventuell auf einen anderen Computer ausgelagert werden. Die Berechnung auf dem Gerät bietet eine schnellere Antwortzeit, benötigt aber zusätzlichen Speicher und Energie, während die Wartezeit, bei Ausführung auf einem Server, unangenehm für den Nutzer ist. Mobile Geräte besitzen nur einen Speicher von wenigen Megabytes für Anwendun- gen und Daten. Der Anwendung steht nur ein kleiner flüchtiger Speicher zur Verfü- gung. Daher sollte der Speicherverbrauch und die Größe der Anwendung minimiert werden. Der Datenspeicher ist durch die Größe des Speichermediums limitiert. Eine weitere Einschränkung für Mobiltelefone und Digitale Assistenten ist die Auflö- sung des Bildschirms. Diese schränkt die Menge der gleichzeitig darstellbaren Infor- mationen ein. Daher wird eine angepasste Menüführung benötigt, die auf die Einga- bemöglichkeiten abgestimmt ist. Diese sind sind meist unhandlich, die Stifteingabe ist ungewohnt und die alphanumerische Tastatur oder das ITU-T-Keypad1 ist zu klein. Eingaben sollten auf ein Minimum reduziert und die Navigation durch einfache Klicks oder Optionsfelder realisiert werden. Die Energie der Geräte ist begrenzt und kostbar. Daher sollten unnötige Aktivitäten, umfangreiche Berechnungen oder Tonausgabe vermieden werden. Datenverbindun- gen werden über drahtlose Netze hergestellt. Diese haben meist nur eine geringe Bandbreite und sind unzuverlässig.

1.3 Plattformen Anwendungen setzen grundlegende Funktionalitäten der Geräte voraus. Dazu gehö- ren Ein- und Ausgabegeräte, ein persistenter Speicher und Möglichkeiten der Kom- munikation. Diese werden durch die entsprechende Hardware angeboten. Die dafür erforderliche hardwarenahe Programmierung ist zeitintensiv und setzt Hardware- kenntnisse voraus. Deshalb wird eine abstrakte Sicht auf das System benötigt. Abbil- dung 1 zeigt die Architektur eines mobilen Gerätes, die aus vier aufeinander aufbau- enden Schichten besteht.

1 besteht aus den Zahlen 0-9 und den Zeichen * und # Plattformen 5

Abbildung 1: Struktur eines mobilen Gerätes [Talu06] Die Hardwareschicht beschreibt die Komponenten des Systems. Zu diesen gehört der Mikroprozessor2, ein digitaler Signalprozessor3, die Ein- und Ausgabegeräte, eine Energiequelle sowie der flüchtige und persistente Speicher. Diese sind meist auf einem Printed circuit board4 integriert. In der darüber liegenden Schicht befindet sich das Betriebssystem. Das Systempro- gramm kontrolliert die Ressourcen des Systems. Es ermöglicht die Ausführung von Anwendungen und bildet die Basis für die Entwicklung von Anwendungsprogram- men. Moderne Betriebssysteme bieten dafür zahlreiche Dienste und Funktionen an. Auf diesen Funktionen baut die Softwareplattform auf. Diese stellt eine zusätzliche Abstraktionsebene zwischen dem Betriebssystem und der Anwendung dar. Die Platt- form definiert zum einen eine Ausführungsumgebung und zum anderen eine Pro- grammierschnittstelle. Die Laufzeitumgebung stellt die erforderlichen Basisfunktio- nen und -dienste für Anwendungen zur Verfügung und übernimmt, unabhängig von den darunter liegenden Schichten, die Verwaltung des Speichers und weiterer Res- sourcen. Die Anwendungen werden von einer Laufzeitumgebung ausgeführt, welche den zumeist vorkompilierten Anwendungscode interpretiert und in Maschinencode übersetzt. Die Programmierschnittstelle besteht aus der Klassenbibliothek, einer Sammlung vorgefertigter Klassen, Schnittstellen und Werttypen zur Wiederverwen- dung in Anwendungen, und bildet die Grundlage der Anwendungsprogrammierung. Die Plattform stellt die Umgebung für die oberste Schicht bereit. In dieser befinden sich die Anwendungen. Sie nutzen die Funktionen der Klassenbibliothek und sind von der restlichen Architektur unabhängig.

1.4 Aufbau der Arbeit Im ersten Teil der Arbeit wird ein Kriterienkatalog für den Vergleich von Plattformen erstellt. Anschließend werden die ausgewählten Plattformen Java Micro Edition, .NET Compact Framework und Android anhand der Kriterien analysiert. Der praktische Teil zeigt am Beispiel eines Bilderarchivs die Implementierung einer mobilen Anwendung auf den untersuchten Plattformen.

2 Mikrochip, auf dem alle Komponenten eines Prozessor vereinigt sind 3 Komponente zur Signalmanipulation 4 Leiterplatten mit gedruckter Schaltung 6 Plattformen

2 Plattformen In der heutigen Anwendungsentwicklung beschreibt der Begriff Plattform eine Soft- wareebene zwischen Betriebssystem und den Anwendungen. Sie stellt die benötigten Funktionen zur Ausführung von Anwendungen zur Verfügung, unabhängig von tiefe- ren Systemschichten. Für den Vergleich wird zunächst ein Kriterienkatalog entwickelt. Die zu untersuchen- den Plattformen werden, nach einer Beschreibung der Basissysteme, anhand der Kri- terien vorgestellt. Abschließend wird der direkte Vergleich der Plattformen durchge- führt.

2.1 Kriterienkatalog Im folgenden werden die Kriterien einer mobilen Plattform definiert. Anhand dieser kann eine Plattform untersucht und mit anderen verglichen werden.

2.1.1 Architektur Das Kriterium Architektur befasst sich mit dem Aufbau der Plattform aus einer abstrakten Sicht und visualisiert das Funktionsprinzip. Dazu wird das System in die einzelnen Komponenten zerlegt. Diese werden charakterisiert und ihre Funktion innerhalb des Softwaresystems beschrieben.

2.1.2 Laufzeitumgebung Die mobile Plattform enthält, oberhalb der Hardware und dem Betriebssystem, eine unabhängige Softwareschicht, die generische Funktionen zur Verfügung stellt. Ein Teil dieser Schicht ist die Laufzeitumgebung. Sie verwaltet die Ressourcen der Platt- form und kontrolliert den Lebenszyklus der Anwendungen. Die virtuelle Maschine interpretiert den Anwendungscode und übersetzt ihn in Maschinenbefehle. erlaubt die Ausführung der Anwendungen unabhängig von der Hardware. Die Anwendung ist dadurch vom restlichen System getrennt.

2.1.3 Speicherverwaltung In diesem Kriterium werden die speziellen Verfahren der Speicherverwaltung betrachtet. Mobile Geräte verfügen meist nur über einen kleinen Speicher. In diesem befinden sich die laufenden Anwendungen und die gespeicherten Daten. Der Spei- cher kann über Erweiterungsschnittstellen hinzugefügt werden und steht als weiterer Datenspeicher zur Verfügung. Das Prinzip der Auslagerung von Programmen kann aufgrund des geringen Speichers nicht angewendet werden. Daher benötigen die Ge- räte ein effizientes Speichermanagement. Diese Aufgabe wird vom Betriebssystem oder der Laufzeitumgebung der Plattform übernommen. In verwalteten Umgebungen übernimmt der Garbage Collector die Speicherbereinigung. Geeignete Verfahren wirken der Fragmentierung des Speicher entgegen. Weiterhin ist es sinnvoll mehr- fach genutzte Ressourcen in einem globalen Speicherbereich abzulegen und den Speicherbedarf zu minimieren. Kriterienkatalog 7

2.1.4 Grafische Benutzungsoberfläche Im Gegensatz zu modernen Computern besitzen mobile Geräte nur einen kleinen Bildschirm auf dem alle Informationen angezeigt werden. Dieser unterscheidet sich, abhängig von der Größe des Geräts, in der Auflösung und in der Anzahl der darstellbaren Farben. Die Grafikschnittstelle muss flexibel sein und sich an die Eigenschaf- ten der Geräte anpassen. Vordergründig sollen die vorgefertigten Bedienelemente der Grafikbibliothek, die Anpassung an die verschiedenen Eingabemöglichkeiten und die Positionierung auf dem Bildschirm betrachtet werden. Weiterführend sollen die ele- mentaren Grafikfunktionen und spezielle Möglichkeiten, wie 3D-Unterstützung, der Plattform aufgezeigt werden.

2.1.5 Persistente Datenspeicherung Anwendungen benötigen zum Sichern von Einstellungen oder anderen Daten einen persistenten Speicher. Das Kriterium fasst die Möglichkeiten der Plattform zusammen, in welcher Form Daten im Gerät abgespeichert und gelesen werden können.

2.1.6 Multimediaunterstützung Das Kriterium widmet sich der Wiedergabe und Aufzeichnung von Mediendateien der mobilen Plattform. Dabei soll der Aufbau des Multimediasystems erklärt und auf die unterstützten Wiedergabe- und Aufnahmemöglichkeiten und Formate eingegangen werden.

2.1.7 Kommunikationsschnittstellen Mobile Geräte besitzen integrierte Funkschnittstellen zur Kommunikation über drahtlose Netze. In diesem Kriterium werden die Netzwerkfunktionen der Plattform vorgestellt. Darüber hinaus wird auf die unterstützten Verbindungstypen und Proto- kolle eingegangen.

2.1.8 Sicherheitsmechanismen Die Sicherheit innerhalb der Plattform ist auf mobilen Geräten von großer Bedeu- tung. Die Plattformen muss die Anwendungen sicher ausführen und die Beeinflus- sung des Systems verhindern. In diesem Kriterium wird auf die Sicherheitsmechanis- men der Plattform eingegangen, vordergründig auf die Prüfung des Byte-Code und der Integrität der Anwendungen. Zudem wird auf die Schutzmechanismen, das Rech- temodell und die Fehlerbehandlung eingegangen.

2.1.9 Native Programmierung Das Kriterium befasst sich mit dem Zugriff auf die Hardware und Funktionen des Betriebssystems. Daher sollen die Möglichkeiten aufgezeigt werden, wie native Pro- gramme oder Bibliotheken genutzt werden können.

2.1.10 Entwicklungsumgebung Für die Entwicklung von Anwendungen wird eine Entwicklungsumgebung für die 8 Kriterienkatalog

Plattformen benötigt. Daher soll auf das Software Development Kit und unterstützte Entwicklungsumgebungen eingegangen werden.

2.1.11 Besonderheiten Diesem Kriterium dient zum Beschreiben von besonderen Merkmalen der Plattform. Zudem kann auf spezielle Funktionen und Konzepte eingegangen werden. Symbian 9

2.2 Symbian Symbian ist ein Softwareunternehmen des finnischen Mobiltelefonherstellers Nokia. Das Unternehmen entwickelt und vertreibt das offene Betriebssystem Symbian OS. Symbian OS ist der direkte Nachfolger des EPOC-Betriebssystem der Firma Psion, welches 1997 im ersten Organizer eingesetzt wurde. Seit 1998 wird das System von einem Konsortium, bestehend aus Psion, Nokia, Sony, Ericsson und Motorola, weiterentwickelt. Das Betriebssystem ist für Mobiltelefone und Organizer konzipiert und zeichnet sich durch Sicherheit, Stabilität und Erweiterbarkeit aus. Die Geräte werden in verschiedene Klassen eingeteilt. Diese wurden früher als Device Family Reference Design (DFRD) bezeichnet. Die Geräteklassen beschreiben unter anderem das Erscheinungsbild5 der grafischen Oberfläche, die vorinstallierten Anwendungen, die Anpassung an die speziellen Eingabegeräte und die Hardwarean- forderungen. Die wichtigsten Klassen der Symbian OS Version 6 waren Pearl, Crys- tal und Quartz. Das Pearl-Design beschreibt ein Mobiltelefon mit numerischem Ein- gabegerät und kleinem Farbbildschirm. Crystal-Design Geräte besitzen eine vollstän- dige alphanumerische Tastatur und einen großen Bildschirm im Querformat. Geräte des Quartz-Designs nutzen eine Stifteingabe auf einem berührungsempfindlichen Bildschirm im Hochformat. Diese Einteilung wurde in die heutigen Versionen über- tragen. Die Geräte werden als Smartphone, Communicator und PDA eingeteilt. Die Hersteller können darüber hinaus ihr eigenes Referenzdesign erstellen und wie beispielsweise Nokia durch sogenannte Series-Plattformen beschreiben. Diese sind spezielle Softwareplattformen für Geräte mit Symbian OS und bieten erweiterte Funktio- nen, z.B. eine individuelle Benutzungsoberfläche, zusätzliche Telefoniefunktionen, Java- und XHTML-Technologien und weitere Kommunikationsschnittstellen. Das Symbian OS Betriebssystem verwaltet den Speicher des Gerätes, welcher in drei Typen unterteilt wird. Der erste Typ ist ein Read Only Memory (ROM), indem sich das Betriebssystem und die vorgefertigte Software befindet. Der Zweite enthält die installierten Anwendungen und die abgespeicherten Daten. Der Dritte ist ein schnel- lerer Speicher und wird für die Ausführung der Anwendungen genutzt. Eine weitere Aufgabe des Betriebssystems ist die Energieverwaltung. Ein gesonderter Thread mit niedriger Priorität versetzt das System in den Ruhezustand, wenn es nicht benötigt wird. Das Betriebssystem unterstützt, neben Python und Flash-Lite, hauptsächlich die Pro- grammiersprachen C++ und Java für die Anwendungsentwicklung. Die native Pro- grammierung in C++ bietet den Programmierern hohe Flexibilität bei der Anwen- dungsentwicklung und Zugriff auf alle öffentlichen Funktionen des Betriebssystems. Die Programme nutzen die gleichen Schnittstellen, wie die integrierten Anwendun- gen. Aufgrund der speziellen Eigenschaften existiert für jede Geräteklasse ein eigenes Software Development Kit (SDK) mit speziellen Werkzeugen und Emulatoren. Einige Herstellen stellen eine eigene Entwicklungsumgebungen bereit. Das Java Micro Edition Subsystem ist Teil des Symbian OS Betriebssystem und stellt die Plattform für Anwendungen in der Programmiersprache Java bereit. Die Java Plattform erlaubt die Ausführung von Anwendungen auf einer Vielzahl unterschiedlicher Geräte. Im Gegensatz dazu ist der native C++ Code für die spezielle CPU-Ar-

5 eng.: Look & Feel 10 Symbian chitektur kompiliert und wird dadurch wesentlich schneller ausgeführt. Die Entwick- ler des Symbian OS betreiben einen großen Aufwand, um auch die Ausführung auf der Java Plattform zu beschleunigen. Dies wird durch eine, an das Betriebssystem angepasste, Implementierung der Java Virtuellen Maschine (JVM) erreicht. Weitere Verbesserungen werden durch die Dynamic Adaptive Compilation (DAC), die Java Byte-Code während der Laufzeit in nativen Code übersetzt, oder durch die Verwen- dung mehrerer Threads für die Ausführung erreicht. Der Zugriff auf Betriebssystem- funktionen wird über zusätzliche Programmierschnittstellen bereitgestellt. Diese sind Bestandteil des SDK für den Gerätetyp und gehören nicht zum Java ME-Standard. [Morr07]

2.2.1 Java Micro Edition Die Java Micro Edition (Java ME) ist die, von Sun Microsystems6 entwickelte, Java Plattform für mobile Endgeräte und eingebettete Systeme. Sie ist die kleinste der drei Java Editionen und speziell für den Einsatz auf Geräten mit beschränkten Ressourcen konzipiert. Die Java ME ist eine Sammlung von Technologien und Spezifikationen und und bietet eine vollständige Ablaufumgebung. Dadurch können Anwendungen auf verschiedenen Betriebssystem ausgeführt werden, für die es eine Laufzeitumge- bung gibt. Sie enthält eine große Menge standardisierter Programmierschnittstellen. Diese sind aus der Java Standard Edition (Java SE) übernommen oder für mobile Geräte neu erstellt. [Orti07]

2.2.2 Architektur Die Java Micro Edition, früher Java Plattform 2 Micro Edition, besteht aus horizon- talen Konfigurationen, vertikalen Profilen und optionalen Paketen.

Abbildung 2: Java ME in der Java Plattform [Sun08]

6 http://de.sun.com/ Symbian 11

• Konfiguration: Basis-Klassen für IO-Streams, Basistypen, Threads, Ausnah- men, Auflistungen, grundlegende Netzwerkklassen • Profile: GUI-Verwaltung, persistente Speicherung, Steuerung des Lebenszy- klus, Multimedia, spezifische Netzwerkklassen • optionale Pakete: File API, erweiterte Multimediaunterstützung, Webservice Die Konfigurationen, die Profile und die optionalen Pakete gehen aus Arbeitsgruppen des Java Community Process (JCP) hervor. Dieser bietet den beteiligten Herstellern die Möglichkeit eine, mit den Wettbewerbern, abgestimmte Schnittstelle für besondere oder neue Leistungsmerkmale zu spezifizieren. Grundsätzlich besteht keine Imple- mentierungspflicht der Spezifikation auf dem Endgerät. Ausgangspunkt ist der Java Specification Request (JSR) eines Mitglieds. Das Resultat ist die Spezifikation und eine Referenzimplementierung. Diese sind auf der Internetseite des Java Community Process7 für alle Java Editionen abrufbar. Die zwei wichtigsten Konfiguration der Java ME sind die Connected Device Config- uration (CDC) und die Connected Limited Device Configuration (CLDC). Die CDC ist durch die [JSR036], die CLDC 1.0 durch die [JSR030] und die CLDC 1.1 durch die [JSR139] spezifiziert. Diese definieren die verfügbaren Sprachmittel, den Funkti- onsumfang der JVM und die minimalen Anforderung an die Endgeräte. Der Prozes- sortyp, die minimale Kapazität des flüchtigen und permanenten Speicher und die Kommunikationsschnittstellen sind durch die Spezifikation festgelegt. Die Konfigu- rationen sind das Grundgerüst der Java Plattform für Geräte mit beschränkten Res- sourcen. Die Endgerätehersteller müssen die Spezifikation in vollem Umfang in ihren Geräten implementieren und die definierten Anforderung erfüllen. Dadurch wird die Portabilität gewährleistet. Die Profile sind von der darunter liegenden Konfiguration abhängig, da sie die Leis- tungsmerkmale und Teile der Klassenbibliothek voraussetzen. Sie enthalten zusätzli- che Klassen für die Verwaltung der Benutzungsschnittstelle, zur Speicherung persistenter Daten und zur Steuerung des Lebenszyklus der Anwendung. Die mobile Java Plattform setzt sich aus der Konfiguration, den Profilen und den optionalen Paketen zusammen. Die Connected Device Configuration ist eine umfangreiche Konfiguration und basiert im wesentlichen auf der Java Standard Edition (CDC 1.0 Java SE 1.3, CDC 1.1 Java SE 1.4.2). Sie setzt sich aus einer vollwertige Java Virtual Machine und einer umfangreichen Teilmenge der Java SE API zusammen. Aus diesem Grund unterstützt sie die Programmiersprache Java vollständig und ist gegenüber der Java Standard Edition nicht eingeschränkt. Sie definiert drei aufeinander aufbauende Profile:

 Foundation Profile – die kleinste Teilmenge ohne grafische Komponenten

 Personal Basis Profile – Teilpakete des Abstract Window Toolkit (AWT)

 Personal Profile – alle Komponenten des AWT Die CDC ist für größere Geräte mit höherer Leistung und Speicherkapazität und Sys- teme ohne Eingabegerät und dauerhafter Netzwerkanbindung ausgelegt. Sie wird in in High-End-PDAs, Set-top Boxen oder eingebetteten Systemen eingesetzt.

7 www.jcp.org 12 Symbian

Die zweite Konfiguration der Java ME ist die Connected Limited Device Configura- tion. Sie besteht aus einer minimalen Klassenbibliothek und einer speziellen JVM mit eingeschränkten Funktionsumfang und geringem Speicherverbrauch. Im Kapitel Laufzeitumgebung wird genauer auf die Kilobyte Virtual Machine (KVM) eingegangen. Die Spezifikation der CLDC schreibt eine minimale Speicheranforderungen von 160kB permanenten und 32kB flüchtigen Speicher und einen 16 oder 32-bit Prozes- sor vor. Die CLDC ist damit für kleine mobile Endgeräte mit begrenzter Rechenleis- tung, geringer Speicherkapazität und drahtloser Kommunikationsschnittstelle mit niedriger Bandbreite geeignet. Sie findet Einsatz in Mobiltelefonen und Smart- phones.

Abbildung 3: CLDC Architektur [Brey06] Die CLDC bildet die Basis für das Mobile Information Device Profile (MIDP). Wei- tere Profile, beispielsweise das Information Module Profile [JSR195], welches in eingebetteten Systemen ohne grafischen Bildschirm verwendet wird, setzten die CLDC als Grundlage voraus. Darüber hinaus existieren noch die weniger bekannten Profile für digitale Assistenten (PDA Optional Packages [JSR075]) oder Set-Top-Boxen (Digital Set Top Box Profile [JSR242]). Das Mobile Information Device Profile ist das bekannteste Profil der CLDC. Es erweitert die Konfigurationen und enthält die Funktionen für die Entwicklung mobiler Anwendungen. Die beiden Versionen des MIDP werden durch [JSR037] (MIDP 1.0) und [JSR118] (MIDP 2.0) spezifiziert und erfordern mindestens die CLDC 1.0. Die Spezifikationen legen, im Gegensatz zu den Konfigurationen, nur die minimalen An- forderungen fest. Zusammen mit der CLDC bilden sie eine umfangreiche Program- mierschnittstelle. Die Schwerpunkte der API liegen in der Benutzeroberfläche, Netz- werkfunktionen und die Speicherung persistenter Daten. Die zweiten Version enthält Verbesserung und neue Funktionen zur Wiedergabe von Medien, sichere Netzwerk- verbindungen und eine API für Spiele. Die Spezifikation des MIDP 2.0 schreibt eine Bildschirmauflösung von mindestens 96x54 Pixel und 1-Bit Farbtiefe, eine drahtlose Netzwerkverbindung mit limitierter Bandbreite, zusätzlich zur Konfiguration 256kB permanenten und 128kB flüchtigen Speicher und die Eingabemöglichkeiten fest. Diese Anforderungen dienen der Portabilität der Anwendungen und gewährleisten die Ausführung auf verschiedenen Endgeräten. Die Anwendungen des MID-Profils werden, in Anlehnung an Java Applets, MIDlets genannt. Sie werden in einer normalen Java Klasse implementiert und erben die Me- Symbian 13 thoden des Lebenszyklus zum Starten, Pausieren und Beenden der Anwendung von der abstrakten MIDlet-Klasse. Die Ereignisverarbeitung wird über Javatypische Eventlistener realisiert. Mehrere MIDlets können in einer MIDlet Suite, der kleinsten installierbaren Einheit, zusammengefasst werden. Die Kombination erlaubt den Zu- griff auf statische Klassenvariablen und gemeinsame Ressourcen in der Suite. Die Anwendung wird in ein Java Archiv (JAR) verpackt, welches den kompilierten Byte- Code, die Ressourcen (Bilder, Text) und das Manifest enthält. Das obligatorische Manifest enthält Meta-Informationen der Suite als Schlüssel-Wert-Paare. Zum Inhalt gehört der Name der Suite, die Version, der Ersteller, die Größe des Archivs, die be- nötigte Konfiguration und das Profil, sowie anwendungsspezifische Attribute. Der optionale Java Application Descriptor (JAD), mit gleicher Syntax, kann zusätzliche Informationen enthalten und wird zur Überprüfung der Konfiguration, des Profil und des benötigten Speicherplatzes während der Installation der Suite verwendet. Bei unterschiedlichen Werten wird im MIDP 1.0 der Application Descriptor genutzt. In Ver- sion 2.0 sind MIDlet Suites mit widersprüchlichen Angaben unzulässig und führen zum Abbruch der Installation. Der JAD kann zusätzlich URLs für die Installation über das Over-The-Air Provisioning8 (OTA Provisioning) enthalten. In diesem Fall wird das Java Archiv nach erfolgreicher Überprüfung von einem Webserver über das Hypertext Transfer Protokoll geladen. Über diesen Mechanismus kann sich der Er- steller der Anwendung über die erfolgreiche Installation oder Deinstallation benach- richtigen lassen. Diese Aufgaben übernimmt die Application Management Software (AMS), die auch den Lebenszyklus der Anwendung steuert und Teil der Laufzeitum- gebung ist. Über den Profilen befinden sich die optionalen Pakete. Diese erweitern die Plattform um spezielle Klassen für den Zugriff auf die Hardware oder bieten zusätzliche Funk- tionen. Die unterstützten Pakete können von Hersteller zu Hersteller und innerhalb einer Produktlinie von Modell zu Modell variieren. Dadurch wird die Portabilität von Anwendungen eingeschränkt. Eine Überprüfungsmöglichkeit ist nicht vorgesehen. Einen Ausweg bildet Java Technology for Wireless Industry9 (JTWI). Diese Spezifi- kation ist ein neuer Versuch eine gemeinsame Basis für mobile Anwendungen zu schaffen, welche die Anforderungen der Konfigurationen und Profilen übersteigen. Die Geräte müssen die Eignung in speziellen Tests nachweisen. [Gigu02], [Gigu02a], [Mahm01], [Mare05]

2.2.3 Laufzeitumgebung Die Kilobyte Virtual Machine (KVM) ist die Laufzeitumgebung der CLDC. Sie un- terstützt zum einen die essentiellen Funktionen der Programmiersprache Java und ist für die Verwendung in Systemen mit geringer Speicherkapazität optimiert. Abhängig von der Zielplattform benötigt die KVM 40-80kB Speicher und ist durch die Imple- mentierung in C auf viele Plattformen portierbar. Die Laufzeitumgebung basiert auf der Virtuelle Maschine der Java SE. Aus dieser wurden einige Funktionen entfernt, die auf mobilen Geräten nicht benötigt werden. Die Fließkommaberechnung ist aufgrund fehlender Hardwareunterstützung nicht integriert. In Version 1.1 der CLDC wurde sie hinzugefügt und wird gegebenenfalls von einer Softwareimplementierung übernommen. Darüber hinaus fehlen die Funktionen des Java Native Interface (JNI),

8 Bereitstellung der Anwendung über die drahtlose Schnittstelle 9 http://java.sun.com/products/jtwi/ 14 Symbian da diese Bibliothek zu umfangreich ist. Die Funktionen der Introspektion10 sind nicht vorhanden, sodass die Serialisierung und Remote Method Invocation (RMI) nicht un- terstützt wird. Die KVM verwendet nur nebenläufige Threads. Thread-Gruppen11 oder Daemon-Threads existieren nicht, da der Programmablauf mit dem letzten User- Thread endet. Die Garbage Collection ist vorhanden, besitzt jedoch nicht die Fähig- keit Objekte zu finalisieren und genutzte Ressourcen automatisch freizugeben. Der Classloader der KVM kann nicht durch eine eigene Implementierung ersetzt werden. Darüber hinaus beinhaltet sie nur eine rudimentäre Fehlerbehandlung. Tritt ein Fehler auf, der nicht in der CLDC definiert ist, wird die KVM angehalten oder ein Objekt der Error-Klasse wird ausgeworfen. Diese Einschränkungen ermöglichen die Erstel- lung der KVM mit einem geringen Speicherplatzverbrauch. Die Implementierung, inklusive der KVM und den Java Bibliotheken, erfordert auf der Zielplattform minimal 128kB. Sie wird meist als Modul in einem Softwaresystem eingesetzt und kann Systemdienste und Anwendungen enthalten. [Sun00]

2.2.4 Speicherverwaltung Die Speicherbereinigung wird, wie die anderen Java Editionen, vom Garbage Col- lector durchgeführt. Dieser Dienst der virtuellen Maschine gibt nicht mehr genutzten Speicher frei. Im Gegensatz zu anderen Programmiersprachen (C, C++) kann in Java der Speicher nicht manuell freigegeben werden. Der gesamte Speicher wird von der KVM verwaltet. In Java gibt es keine Zeiger, da diese die Funktionsweise der Garbage Collection beeinflussen könnten. Die Klassenbibliothek bietet dem Pro- grammierer eine Methode um die Speicherbereinigung auszulösen. Die Laufzeitum- gebung entscheidet selbst, wann die Bereinigung durchgeführt wird. Der verwendete Algorithmus ist nicht vorgeschrieben und von der Implementierung der KVM abhän- gig. Der Garbage Collector entfernt ein Objekt, wenn es von keinem aktiven Thread referenziert wird. Dies ist der Fall, wenn der Thread beendet wird, die Referenz eines Objekts auf null gesetzt wird, oder das Objekt nur isolierte Referenzen enthält. Im Vergleich zu den anderen Java Editionen steht auf Java ME-Geräten nur sehr wenig Speicher zur Verfügung. Daher ist eine solide Speicherverwaltung für ein zuver- lässiges System ausschlaggebend. Tritt ein interner Fehler auf, erzeugt die Fehlerbe- handlung eine Instanz einer Unterklasse der Error-Klasse. In der Konfiguration kön- nen bestimmte Fehler definiert werden, welche die Laufzeitumgebung beenden. Be- nötigt eine Anwendung mehr Speicher als zur Verfügung steht, wird der OutOfMemoryError ausgelöst. Er entsteht auf mobilen Geräten vor allem beim La- den von großen Dateien. Insbesondere tritt der Fehler bei komprimierten Bildern (z.B. JPEG) auf, da diese im Speicher entpackt werden. Ein weiteres Problem stellt die Fragmentierung des Speichers dar. Objekte werden erstellt, genutzt und danach verworfen. Dadurch wird der zusammenhängende freie Speicherbereich immer kleiner. Die Fragmentierung kann durch Wiederverwendung von Objekten reduziert werden. Daher sollte der Großteil der Funktionalität in der MIDlet-Klasse implementiert werden, da diese über die gesamte Laufzeit im Speicher verbleibt. Dies reduziert den Aufwand der Garbage Collection und spart Energie. [Sun00a]

10 Analyse der Klassen zur Laufzeit 11 verwaltet hierarchische Threads oder Threadgruppen in Java SE Symbian 15

2.2.5 Grafische Benutzungsoberfläche Für die grafische Ausgabe und die Verarbeitung von Eingaben ist das Lowest Com- mon Denominator User Interface (LCDUI) verantwortlich. Anwendungen müssen auf verschiedenen Geräten, mit unterschiedlichen Eingabemöglichkeiten und Bild- schirmformaten lauffähig sein. Daher beinhaltet die Bibliothek den kleinsten gemein- samen Nenner der Fähigkeiten, die aus den minimalen Anforderungen des MID-Pro- fils hervorgehen. Die Auflösung des MIDP 1.0 und MIDP 2.0 muss minimal 96x54 Pixel bei 1-Bit Farbtiefe sein. Das LCDUI bietet Informationen über die Eigenschaf- ten des Gerätes an. Bereits beim Entwurf der Schnittstelle wurde berücksichtigt, dass Anwendungen von jedem Nutzer bedient werden können. Die Fähigkeiten der Gra- fikbibliothek kann durch Funktionen des Herstellers erweitert werden. Die Portabili- tät der Anwendung wird gewährleistet, wenn der plattformunabhängige Teil der API verwendet wird. Abbildung 4 zeigt die Aufteilung der grafischen Programmier- schnittstelle in die High-Level-API und Low-Level-API.

Abbildung 4: MIDP LCDUI Klassen [Krol02] Das Hauptelement der Benutzungsoberfläche ist die Klasse Display. Sie ist das Soft- wareabbild des physischen Bildschirms. Deshalb gibt es nur eine Instanz innerhalb eines MIDlets. Diese wird über die statische Methode getDisplay, unter Angabe des MIDlet abgerufen. Die Klasse bietet Methoden zum Abrufen und Setzen der Bild- schirmeigenschaften, des aktuell angezeigten Dialoges, sowie das Aufrufen der Vi- brationsfunktion. Die Klassen der Benutzungsschnittstelle befinden sich im Paket javax.microedition.lcdui. Dialoge werden durch die abstrakte Klasse Displayable repräsentiert. In einem MID- let wird jeweils nur ein Displayable-Objekt dargestellt. Dieses wird auf dem Bild- schirm angezeigt, kann aber durch ein anderes MIDlet überlagert werden. Die Basis- klasse enthält die Methoden zum Setzen des Titels und des Laufbandes (Ticker), zur Veränderung der Größe, zum Abfragen der Sichtbarkeit und zum Hinzufügen oder Entfernen von Kommandos. Die High-Level-API ermöglicht die Portabilität von Anwendungen auf verschiedene 16 Symbian

Endgeräte. Sie wird durch die im Gerät implementierten abstrakten User Interface Widgets bereitgestellt. Das Erscheinungsbild und das Verhalten der Bedienelemente soll an die bekannten Komponenten des Endgerätes angepasst sein, um dem Benut- zer die Bedienung zu erleichtern. Dies bedeutet im Umkehrschluss, das ein MIDlet keine visuellen Veränderungen der Bedienelemente vornehmen kann, da diese im Er- messen der LCDUI Implementierung liegen. Die High-Level-API ist verantwortlich für das Zeichnen und Aktualisieren der Komponenten und unterstützt einfache Inter- aktionen, wie beispielsweise das Blättern über den physischen Bildschirm hinaus. Von den Eingabegeräten empfangene Kommandos werden an die Anwendung über die Schnittstelle CommandListener weitergeben. Die Unterklassen List, TextBox und Alert stellen bereits fertige Dialoge mit festgelegter Struktur und vorgefertigten Funktionen bereit. Zu diesen können keine weiteren Strukturelemente hinzugefügt werden. In die Unterklasse Form können Elemente der Basisklasse Item hinzugefügt werden. Die Darstellung der vorgefertigten Standardelemente Ein- und Ausgabefel- der, Auswahlfelder oder Bilder wird über Eigenschaften festgelegt. Mit geringen Pro- grammieraufwand können damit beliebige Dialoge erstellt werden. Eigene Elemente können durch Ableitung der CustomItem erstellt und hinzugefügt werden. Die Klasse Canvas der Low-Level-API bietet direkten Zugriff auf den Bildschirm und die Eingabegeräte. Sie bietet durch die Graphics-Klasse direkten Zugriff auf den angezeigten Inhalt auf Pixelebene. Der Ereignismechanismus verarbeitet die Eingabe über Tastatur oder Touchscreen und ruft die implementierten Methoden des Com- mandListener auf. Die API erlaubt es zudem auf hardwarespezifische Funktionen zuzugreifen, z.B. zusätzliche Tasten (Game-Key, 5-Wege-Navigation). Das MID-Profil Version 2.0 definiert zusätzlich die Erweiterung Game API. Sie ent- hält Klassen zur Erstellung von Spielen auf mobilen Geräten. Sie bietet DoubleBuf- fering12, Animationen, Kollisionserkennung und weitere Funktionen. Diese und andere Erweiterungen nutzen die Low-Level-API um Zugriff auf den Bildschirm zu erhalten. [Hopk07]

2.2.6 Persistente Datenspeicherung Das Record Management System (RMS) bietet für das MID-Profil, welches einen permanenten Speicher voraussetzt, eine unabhängige Programmierschnittstelle für den lesenden und schreibenden Zugriff auf persistente Daten. Die Klasse RecordStore stellt eine einfache satzorientierte Datenbank dar. Sie wird über die statische Methode openRecordStore geöffnet oder erzeugt. Der Name des RecordStore muss innerhalb einer MIDlet Suite eindeutig sein. Alle MIDlets einer Suite können diese Datenbank nutzen. Der RecordStore besteht aus den Records, einer Menge ungetypter Datensätze variabler Länge. Der Zugriff erfolgt durch einen automatisch vergebenen eindeutigen Identifikator, der die Funktion des Primär- schlüssels übernimmt. Das RMS bietet sequenziellen Zugriff auf die Datensätze. Diese können über die Schnittstellen RecordFilter gefiltert und RecordComparator sortiert werden. Die Version, der Zeitpunkt des letzten Zugriffs, sowie der verwendete und zur Verfügung stehende Speicher kann abgerufen werden.

12 Technik zur beschleunigten Darstellung Symbian 17

Abbildung 5: RMS Struktur [Ghos02] Die Datensätze können aus strukturierten Byte-Sequenzen bestehen. Über die Klas- sen DataInputStream und DataOutputStream können diese in das und aus dem Byte- Array überführt werden. Das RMS garantiert das die Aufrufe unteilbare Operationen sind. Die Reihenfolge kann nicht gewährleistet werden, da mehrere Threads auf die Datenbank zugreifen können. Die Größe der Datenbank ist abhängig vom verfügbaren Speicherplatz im Gerät.

2.2.7 Multimediaunterstützung Für das Abspielen von multimedialen Inhalten existieren für die Java Micro Edition zwei Programmierschnittstellen. Die Media API ist in der Spezifikation des MID- Profil definiert. Sie ist eine direkte Teilmenge der in [JSR135] spezifizierten Mobile Media API (MMAPI). Diese ist ein optionales Paket und geht aus dem umfangreichen Java Media Framework13 hervor. Die Media API enthält keine vollständige Medienunterstützung. Sie ist speziell für Java ME-Geräte mit beschränkten Ressourcen vorgesehen und unterstützt zumindest minimale Multimediafähigkeiten. Sie unterstützt die Erzeugung und die Wiedergabe von Tönen. Die Mobile Media API erlaubt das Abspielen aus verschiedenen Medienquellen und zusätzlich die Aufnahme von Tonsignalen und von Bildern über die Kamera des Ge- rätes. Die Version der MMAPI, die unterstützten Aufzeichnungsquellen und Daten- formate werden über die Methoden getSupportedProtocols und getSupportedCon- tentTypes des Manager abgerufen und sind von der Implementierung des Geräteher- stellers abhängig.

13 http://java.sun.com/javase/technologies/desktop/media/jmf/ 18 Symbian

Abbildung 6: Mobile Media API Architektur [Mahm03] Beide Programmierschnittstellen folgen der gleichen Architektur und enthalten die drei Hauptkomponenten Manager, Player und Control. Der Manager ist die Haupt- komponente und stellt den erforderlichen Player für den Medientyp bereit. Der Typ wird über den Content Type14 in der MIME-Syntax identifiziert. Darüber hinaus ent- hält der Manager eine Methode um einfache Töne zu erzeugen und wiederzugeben, für die kein eigener Player benötigt wird. Der Player kann aus einem Datenstrom oder einer Datenquelle erzeugt werden. Der MediaLocator wird in URI-Syntax spezifiziert. Die Verbindung wird unter Einsatz des Generic Connection Framework, auf das im nächsten Kapitel eingegangen wird, erstellt. Der Player enthält Methoden zur Steuerung des Lebenszyklus, der aus fünf Zuständen besteht. Die Zustände bieten die Kontrolle über die zeitaufwendigen Operationen, wie das Aufbauen der Verbindung und das Übertragen der Daten vom Server. Der Programmierer kann den Zustands- übergang über Methoden beeinflussen um ein unterbrechungsfreies Abspielen sicher- zustellen. Der aktuelle Status kann direkt abgerufen oder über einen vorher registrier- ten EventListener mitgeteilt werden. Neben Informationen über das Medium bietet der Player vom Medium abhängige Controls, mit denen die Verarbeitung der Daten im Player gesteuert wird. Der Zugriff erfolgt über die Methoden des Interfaces Con- trollable. Beispielsweise enthält ein allgemeiner Audioplayer ein VolumeControl zum Steuern der Lautstärke. Ein MIDI-Player bietet zusätzlich die TempoControl, zum Ändern der Wiedergabegeschwindigkeit, und PitchControl, zum Ändern der Tonhö- he, an. Die unterstützten Controls werden über die Methode getControls abgerufen. [Mahm03]

2.2.8 Kommunikationsschnittstellen Die Java ME nutzt das Generic Connection Framework (GCF), da die Klassen der Java SE für den mobilen Einsatz ungeeignet sind. Die Gründe liegen in der Größe des Byte-Codes der Klassen, dem inkonsistente Umgang mit unterschiedlichen Proto- kollen und der geringen Flexibilität beim Austausch von Protokollimplementierun- gen. Die Klassen des GCF befinden sich im Paket javax.microedition.io. Das GCF ist ein erweiterbares, generisches Framework für Endgeräte mit beschränk- ten Ressourcen. Es ist mobil einsetzbar und ermöglicht die Kommunikation über

14 klassifiziert die Daten Symbian 19

Netzwerkprotokolle. Abbildung 7 zeigt einen Überblick über die Hierarchie des GCF. Verbindungen werden über die Klassen Connector, unter Angabe einer URL, erstellt. Die Schnittstelle Connection stellt den Basistyp für alle Verbindungen dar. In jeder Hierarchieebene wird die Funktionalität der Schnittstellen erweitert. Das GCF bietet paket- und datenstrombasierte Verbindungen über die Schnittstellen Datagram- Connection, InputConnection und OutputConnection an. Die StreamConnection ist repräsentiert die Verbindung für eine bidirektionale Kommunikation. Der Zugriff auf inhaltsbasierte Informationen, z.B. Länge, Typ und Kodierung wird über die Schnitt- stelle ContentConnection bereitgestellt. Die StreamConnectionNotifier-Schnittstelle kann eine Anwendung über das Eintreffen eines asynchronen Datenstromes informie- ren. Das GCF bietet eine einheitliche Programmierschnittstelle für verschiedene Pro- tokolle.

Abbildung 7: Generic Connection Framework [Orti03] Ausgangspunkt jeder Kommunikation ist die Schnittstelle Connection. Sie repräsen- tiert die Verbindung, unabhängig vom Übertragungsprotokoll. Sie stellt die Funktio- nalität bereit, die auf alle Verbindungstypen angewendet werden kann. Für die wichtigsten Protokolle wird eine abgeleitete Schnittstelle bereitgestellt, die den Zugriff auf die spezifischen Eigenschaften ermöglicht. Die Verbindung wird über die statische open-Methode der Klasse Connector angelegt. Die Daten werden gesendet, wenn die Größe des Sendepuffers erreicht ist oder die Verbindung geschlossen wird. Der erste Parameter enthält das Protokoll, die Netzwerkadresse und optionale Para- meter als Schlüssel-Wert-Paare definiert. Der Aufbau folgt der Struktur scheme:tar- get[;parameters]. Weitere Parameter legen die Art der Kommunikation und die Be- handlung von Zeitüberschreitungen fest. Die empfangenen Daten werden über einen InputStream bereitgestellt. Im MIDP 2.0 ist das HTTP und das Hypertext Transfer Protocol Secure (HTTPS) der Anwendungsschicht des OSI-Referenzmodells15 unmittelbar enthalten. Weiterhin

15 ISO/IEC 7498-l 20 Symbian werden die Verbindungen Socket, Server-Socket, Secure-Socket-Layer (SSL), UDP- Datagramm, und Seriell unterstützt. Die Implementierung dieser Verbindungstypen ist optional und muss von der Implementierung des Herstellers nicht unterstützt werden. Optionale Pakete ermöglichen den Zugriff auf weitere Verbindungstypen, beispielsweise Bluetooth [JSR082]. [Mahm03a]

2.2.9 Sicherheitsmechanismen Die Java Plattform ist für sicherheitskritische Umgebungen ausgelegt. Der Einsatz des Sicherheitsmodells der Java Standard Edition ist aufgrund der beschränkten Res- sourcen nicht möglich. Daher wurde es für die CLDC vereinfacht und besteht aus drei Ebenen. Die Low-Level Sicherheit der Laufzeitumgebung sichert, dass die aus- geführte Anwendung den Regeln der Programmiersprache Java entspricht und verhindert das falsche oder schadhafte Klassendateien das System beeinflussen. Der Class-File-Verifier prüft den Anwendungscode auf fehlerhafte Anweisungen und Re- ferenzen auf ungültige Speicherbereiche. Fehlerhafte Dateien werden zurückgewie- sen. Die rechenintensive Überprüfung ist, wie in Abbildung 8 dargestellt, zweigeteilt. Die Präverifikation wird während der Erstellung des Archivs in der Entwicklungsum- gebung durchgeführt und übernimmt den Großteil der Überprüfung. Die Laufzeitum- gebung des Endgeräts prüft nur die vorhandene Struktur und die Gültigkeit der kompilierten Klassen.

Abbildung 8: 2-Phasen Byte-Code-Verifikation in CLDC [Schm06] Weitere Sicherheitsmechanismen befinden sich auf Anwendungsebene. Die Anwen- dungen werden in einer abgeschlossenen Umgebung, der Java Sandbox, ausgeführt und können nur vorher definierte Bibliotheken nutzen. Dadurch wird die Beeinträch- tigung des Systems und der Ressourcen durch schadhafte Programme verhindert. Die Implementierung der CLDC unterbindet das Überschreiben von Klassen der System- pakete. Das Trusted Application Model des MID-Profils ergänzt den Schutz auf der dritten Ebene. Die Spezifikation definiert ein erweiterbares System von Berechtigun- Symbian 21 gen. Damit ein MIDlet mit einem Webserver kommunizieren kann, muss es über die Berechtigung eine Netzwerkverbindung aufzubauen verfügen. Diese werden vom Hersteller oder vom Anwendungsentwickler über sogenannte Protection Domains festgelegt. Diese enthält eine Liste mit Operationen. Der Modus legt fest, ob die Operation verweigert, erlaubt oder der Benutzer gefragt wird. Die Java Micro Edi- tion enthält vier vorgefertigte Domänen: • Minimal – keine Berechtigungen • Untrusted – Nachfrage beim Nutzer • Trusted – äquivalent zu Maximum • Maximum – alle Berechtigungen

Die MIDlet Suite kann zusätzlich eine digitale Signatur und ein Zertifikat enthalten. Über diese wird die Authentizität und Integrität des Java Archiv geprüft. [Knud03], [Kull04]

2.2.10 Native Programmierung Die Java Micro Edition unterstützt aus Sicherheitsgründen keinen Zugriff auf native Programme oder Hardwarefunktionen. Die Implementierung des Java Native Inter- face ist zu umfangreich für CLDC Zielsysteme. Der Zugriff auf herstellerspezifische Funktionen ist durch optionale Pakete möglich. Funktionen des Basissystems können vom Hersteller in die virtuelle Maschine implementiert werden. [Maso08]

2.2.11 Entwicklungsumgebung Für die Entwicklung existiert neben den herstellerspezifischen Software Develop- ment Kits das Sun JavaTM Wireless Toolkit for CLDC16. Es ist ein modernes Werkzeug für die Entwicklung von Anwendungen für Mobiltelefone der CLDC und des MIDP. Teil des SDK sind die Java ME Standardbibliotheken, die Implementierung optiona- ler Pakete, die Dokumentation der Programmierschnittstellen, Programme für die Er- stellung der MIDlet Suite in einem Java Archiv, ein umfangreicher Emulator für unterschiedliche Gerätetypen und Beispielanwendungen. Mitgelieferte Werkzeuge stellen zusätzliche Informationen über den aktuellen Status des Emulators, beispielsweise die Kommunikation über das Netzwerk oder der momentane Speicherverbrauch, dar. Die herstellerspezifischen SDK enthalten die Bibliotheken für den Zugriff auf die Funktionen des Endgeräts. Das SDK kann durch zusätzliche Module in bekannte Entwicklungsumgebungen, wie Eclipse17 und NetBeans18, integriert werden. Diese bieten die bekannten Funktio- nen wie Quellcodevervollständigung, intelligente Hinweise für die Fehlerkorrektur und Syntaxhervorhebung.

16 http://java.sun.com/products/sjwtoolkit/ 17 http://www.eclipse.org/ 18 http://www.netbeans.org/ 22 Symbian

Abbildung 9: NetBeans IDE mit Mobility Pack Besondere Funktionen bietet das Mobility Pack19 der NetBeans Entwicklungsumge- bung an. Teil des Moduls ist der Visual Mobile Designer und der Mobile Game Builder, zur einfachen Erstellung der grafischen Oberfläche, die Unterstützung für mehrere Zielplattformen, die automatische Erstellung von Proxyklassen für den Zu- griff auf Webservices und weitere Werkzeuge zum Erstellen und Testen der Anwen- dungen.

2.2.12 Besonderheiten der Plattform Die Java ME Plattform ist die am weitesten verbreitete Plattform und wird auf vielen Geräten eingesetzt. Sie wird als zusätzliches Modul in viele Betriebssysteme integriert. Programme werden in der objektorientierten Programmiersprache Java geschrieben und der kompilierte Byte-Code durch eine optimierte Laufzeitumgebung ausgeführt. Die Plattform bietet eine Programmierschnittstellen die durch optionale Pakete erweitert werden kann.

19 http://www.netbeans.org/features/javame/index.html Windows Mobile 23

2.3 Windows Mobile Windows Mobile ist ein Betriebssystem für mobile Endgeräte und gehört zur Embed- ded Produktreihe von Microsoft. Es basiert auf dem Windows CE Betriebssystemkern und erweitert die Funktionalität um gerätespezifische Eigenschaften für Mobiltelefo- ne und Digitale Assistenten. Der Windows CE Kernel ist für den Einsatz auf Geräten mit beschränkten Ressourcen optimiert. Er ist für die Verwaltung der Prozesse, des Speichers und der Energie zuständig und enthält die wichtigsten Gerätetreiber. Der Kernel steht für unterschiedliche Prozessorarchitekturen zur Verfügung und wird in mobilen Geräten und eingebetteten Systemen verwendet. Windows Mobile wird auf telefoniezentrierten Smartphones und datenzentrierten Pocket PC's verwendet. Für die unterschiedlichen Gerätearten existieren drei Versio- nen von Windows Mobile. Die Windows Mobile Classic Version enthält typische An- wendungen für Taschencomputer mit Stiftbedienung, wie z.B. Terminplaner, Adress- verwaltung und Synchronisationssoftware. Die zweite Version ist Windows Mobile Standard und für Smartphones mit mobiltelefontypischer Tastatur und kleinem Bild- schirm optimiert. Die Windows Mobile Professional Version erweitert die Classic Version um Telefonfunktionen und wird auf Smartphones mit Touchscreen eingesetzt. Das Design der Windows Mobile Oberfläche ist stark an die PC-Version von Win- dows angelehnt. Über das Hauptelement (Start) können die installierten Programme gestartet werden. Bekannte Programme, wie der Internet Explorer, der Windows Me- dia Player und Büroprogramme wurden auf die mobile Plattform übertragen. Das Windows Mobile SDK ermöglicht nur die Entwicklung von nativen Anwendun- gen. Daneben wird das .NET Compact Framework unterstützt.

2.3.1 .NET Compact Framework Das .NET Compact Framework ist ein direkter Ableger des Desktop- und Server-Fra- meworks. Es ermöglicht die einfache und effiziente Erstellung robuster Anwendun- gen mit dem Ziel, diese zu jeder Zeit, an jedem Ort und auf jedem Gerät zur Verfü- gung zu stellen. Das .NET Compact Framework wurde für Geräte mit beschränken Ressourcen entwickelt. Um es auf mobilen und eingebetteten Systemen mit wenig Arbeitsspeicher und geringer Prozessorleistung einsetzen zu können, wurde sehr viel Wert auf hohe Leistung und geringe Größe gelegt. Das Framework wurde dafür von Grund auf neu erstellt. Dennoch bietet es die Funktionen des Standard .NET Frame- work. Die direkte Verwandtschaft zum Standard .NET Framework steigert die Pro- duktivität, da bereits erlernte Fähigkeiten aus der Desktop- und Server-Entwicklung genutzt werden können. Von außen betrachtet erscheint es als direkte Portierung des .NET Framework. Die Gemeinsamkeiten der beiden Produkte sind auf den höheren Ebenen beabsichtigt. Sie verwenden das gleiche Programmiermodell und Dateifor- mat. Beide basieren auf dem ECMA20 Common Language Infrastructure (CLI) Stan- dard21, einer Spezifikation für sprach- und plattformunabhängige Anwendungsent- wicklung. Dieser definiert die Architektur und die Komponenten eines Systems, auf dem der standardisierte Zwischencode, der Common Intermediate Language22 (CIL), 20 European Computer Manufacturers Association internationale Normierungsorganisation 21 ECMA-335 22 früher Microsoft Intermediate Language 24 Windows Mobile ausgeführt werden kann. Der Common Type System (CTS) Standard definiert wie Da- tentypen im Speicher abgebildet werden. Es ist Teil der CLI Spezifikation und erlaubt die Entwicklung mehrsprachiger Anwendungen. Das Virtual Execution System (VES) des Standards bietet die Ausführungsumgebung für verwalteten Code. Es ist für die Übersetzung des CIL-Codes in Maschinencode verantwortlich und führt die Anwendung auf der Plattform aus. Dadurch wird die Ausführung von Anwendungen auf verschieden Betriebssystemen und unterschiedlichen Prozessorarchitekturen er- möglicht. Der Zwischencode wird vom Compiler des .NET Compact Framework erstellt und ist mit dem des Standard .NET Framework binär kompatibel. Durch die Kompilierung in CIL-Code ist der Quellcode von der Entwicklungssprache unabhän- gig. Das .NET Compact Framework unterstützt derzeit die Programmiersprachen C# und Visual Basic .NET. Weitere Programmiersprachen können durch Bereitstellung eines Compilers, der CIL-Code erzeugt, hinzugefügt werden. Aufgrund der unterschiedlichen Bedingungen unterscheidet sich die Laufzeitumgebungskomponente der beiden Frameworks. Sie ist an die speziellen Anforderungen des mobilen Gerätes angepasst. Das .NET Compact Framework besteht aus der Common Language Runtime (CLR) und einer Klassenbibliotheken. Die Klassenbibliothek des Framework wird in Com- mon Intermediate Language ausgeliefert. Eine vorkompilierte Bibliothek benötigt den vierfachen Speicherplatz und ist nur auf einer Prozessorarchitektur lauffähig. Der CIL-Code wird zur Laufzeit in Maschinencode umgewandelt. Die Verwendung von verwaltetem Code und die Unterstützung für neue Technologien erlaubt die Entwick- lung von neuartigen Anwendungen auf verschiedenen mobilen Endgeräten. [Will04]

2.3.2 Architektur Die Architektur des Framework folgt dem gleichen Aufbau wie das Standard .NET Framework. Sie wird in die, in Abbildung 10 dargestellten, Bereiche für Maschinen- code (Native Code) und verwalteten Code (Managed Code) aufgeteilt.

Abbildung 10: .NET Compact Framework Architektur [Wigl03] Der native Teil besteht aus dem Platform Adaption Layer (PAL), der Ausführungs- umgebung und dem Basisbetriebssystem. Im Gegensatz zum Desktop-Framework, kann das .NET Compact Framework auf einer Vielzahl unterschiedlicher Betriebssysteme ausgeführt werden. Dies wird durch Windows Mobile 25 die Abstraktionsschicht zwischen Betriebssystems und Laufzeitumgebung gewähr- leistet. Der PAL setzt die Programmierschnittstellen des Betriebssystems auf die An- forderungen des .NET Compact Framework um und erlaubt die Ausführung der Laufzeitumgebung und der Klassenbibliothek auf verschiedenen Hardware- und Softwareplattformen, da sie die Unterschiede des darunter liegenden Betriebssystems versteckt. Über dem PAL befindet sich die Hauptkomponente des .NET Compact Frameworks, die Laufzeitumgebung (Execution Engine). Sie ist für die Ausführung der Anwen- dungen verantwortlich. Eine der Hauptaufgaben ist die Verwaltung des Speichers. Der integrierte Just-In-Time23 (JIT) Compiler übersetzt den CIL-Code in ausführba- ren Maschinencode. Für jeden unterstützen Prozessortyp wird eine Implementierung der Laufzeitumgebung zur Verfügung gestellt. Der verwaltete Teil der Architektur besteht aus der Klassenbibliothek des .NET Com- pact Framework, gerätespezifischen Bibliotheken und den Anwendungen. Die Klassenbibliothek besteht aus hierarchischen Namensräumen, in denen die Klas- sen und Typen enthalten sind. Die CLI-konforme Bibliothek ist auf mehrere Dateien aufgeteilt. Diese werden durch Referenzen an die Anwendung gebunden. Dadurch wird der Speicherverbrauch reduziert, da nur die benötigten Dateien Teil der Anwen- dung sind. Eine Datei kann mehrere Namensräume enthalten und ein Namensraum kann auf mehrere Dateien verteilt sein. Bei der Erstellung der Anwendungen sucht der Compiler in den referenzierten Bibliotheken nach den verwendeten Klassen und Schnittstellen. Die Basisklassen sind im Namensraum System enthalten und bilden das Fundament jeder Anwendung. Sie bieten unter anderen Datei-I/O, Aufzählungen, primitive Datentypen und Netzwerkunterstützung. Zur Einhaltung der ECMA Spezi- fikation sind die Funktionen für die Verarbeitung von XML-Daten und Webservice- unterstützung in zusätzlichen Bibliotheken enthalten. Der interoperable Mechanis- mus des Frameworks leitet Aufrufe zwischen der CLR und dem Betriebssystem weiter und bietet Zugriff auf native Softwarekomponenten. Auf der Klassenbibliothek bauen die Anwendungen des .NET Compact Framework auf. Sie können durch eigene oder vom Hersteller bereitgestellte Bibliotheken erweitert werden. [Yang07]

2.3.3 Laufzeitumgebung Die Laufzeitumgebung des .NET Compact Framework ist die Common Language Runtime. Sie ist für die Verwaltung und Ausführung der .NET Anwendungen zustän- dig und für Geräte mit eingeschränkten Ressourcen optimiert. Sie nutzt die Funktio- nalität der Anpassungsschicht um auf die Betriebssystemdienste zuzugreifen. Dieser Unterschied zur Desktop-Variante bietet eine höhere Flexibilität. Durch den Aus- tausch der Schicht kann ein anderes Betriebssystem unterstützt werden. Anwendun- gen werden, im Gegensatz zu anderen Plattformen, im Prozess der CLR ausgeführt. Dieser wird vom Application Domain Host des Betriebssystems bereitgestellt. Die Anwendung wird in dem Prozess in einer eigenen Anwendungsdomäne gestartet und voneinander isoliert. Die CLR verwaltet die Anwendungsdomänen und stellt sicher, dass die Ressourcen nach Beendigung der Anwendung freigeben werden. Eine der wichtigsten Aufgaben der Laufzeitumgebung ist die Übersetzung des ver-

23 Kompilierung während der Laufzeit 26 Windows Mobile waltetem Code. Diese findet in drei Schritten während der Laufzeit statt. Im ersten Schritt wird der CIL-Code geladen. Anschließend übersetzt der optimierte JIT-Com- piler diesen in Maschinencode. Im dritten Schritt werden referenzierte Bibliotheken geladen und der benötigte Teil übersetzt. Nachdem der ClassLoader die Assembly- Information geladen hat, wird der TypeChecker gestartet. Dieser führt vor der Über- setzung des CIL-Code eine Typprüfung durch. Die verwendeten Datentypen in Me- thoden und von Variablen werden auf Typverletzungen geprüft. Dadurch werden nicht initialisierte Variablen und Aufrufe von Methoden mit falschen Parametern verhindert. Anschließend wird die Kompilierung des CIL-Codes auf Methoden- und Ty- penebene durchgeführt. Es wird nur der benötigte Code übersetzt und für den späte- ren Aufruf im Anwendungsspeicher gesichert. Bereits kompilierter Code steht somit für die sofortige Ausführung zur Verfügung. Im Gegensatz zu interpreterbasierten Systemen wird die Ausführungsgeschwindigkeit durch den nativen Code gesteigert. Für das .NET Compact Framework existieren zwei unterschiedliche JIT-Compiler. Der IJIT-Compiler ist schnell und erzeugt nativen Code für die vom Framework un- terstützen Prozessortypen. Er ist, im Vergleich zum SJIT-Compiler, nicht optimal. Der SJIT ist der meist genutzte Compiler für die Pocket PC Plattform und speziell für ARM-Prozessoren optimiert. Die Kompilierung benötigt mehr Zeit, erzeugt aber nativen Code, der vom Prozessor schneller ausführt werden kann. Die zusätzlich be- nötigte Zeit wird durch die Wiederverwendung von zwischengespeicherten Maschi- nencode und der beschleunigten Ausführung unerheblich. Optimierungen des Quell- codes durch den Compiler verhindern eine exzessive Nutzung der JIT-Kompilierung. Durch das Method Inlining werden beispielsweise aufgerufene Methoden mit der anderen Methoden zusammengefasst. Beide Compiler übersetzen nur den benötigten Code. Die Laufzeitumgebung versucht diesen, während der gesamten Laufzeit der Anwendungen im Speicher zu halten, da die Wiederverwendung von kompilierten Codes die Anzahl der Übersetzungsvorgänge reduziert. Wird mehr Speicher benötigt als zur Verfügung steht, entfernt die CLR einzelne kompilierte Methoden aus dem Speicher. Das Kriterium für die Auswahl ist die Aufrufhäufigkeit. Die am wenigsten genutzte Methode wird ausgewählt und entfernt. In Extremsituationen, bei komplexen Anwendung die viel Speicher benötigen oder viele Anwendungen parallel ausge- führten werden, wird der gerade übersetzte Maschinencode sofort wieder aus dem Speicher entfernt. [Rubi03], [Wigl07], [Salm05], [Will04]

2.3.4 Speicherverwaltung Eine der Stärken des .NET Compact Framework liegt in der effizienten Nutzung der Ressourcen. Es übernimmt die Aufgaben der Speicherverwaltung und setzt keine Memory Management Unit, virtuellen Speicher oder Speicherschutzfunktionen voraus. Der verfügbare Speicher besteht aus Read Only Memory und Random Access Memory (RAM). Im ROM befindet sich das Betriebssystem und die Dateien des .NET Compact Framework. Die Integration des Frameworks in den ROM spart wert- vollen Speicherplatz im RAM ein, da dieser gleichzeitig als Daten- und Arbeitsspei- cher genutzt wird. Zum einem enthält er die Datenstrukturen und den kompilierte CIL-Code der ausgeführten Anwendungen und zum anderen die Anwendungsdateien. Der Speicher wird bis zu einer, vom Gerät vorgegebenen, Obergrenze belegt. Nicht mehr referenzierte Objekte oder bereits übersetzter Maschinencode werden beim Er- reichen der Grenze entfernt. Dadurch können umfangreiche Programme mit minima- Windows Mobile 27 len Leistungseinbußen auch auf Systemen mit geringem Speicher ausgeführt werden. Wird mehr Speicher benötigt als zur Verfügung steht, wird eine Ausnahme ausgelöst oder die Anwendung beendet und die verwendeten Ressourcen freigegeben. Dadurch wird ein stabiles System gewährleistet. Eine .NET Anwendung wird in einer eigenen Anwendungsdomäne gestartet. Der Do- mänenhost wird vom Windows CE Betriebssystem bereitgestellt und benötigt keinen zusätzlichen Speicherplatz. Die CLR legt für die Verwaltung der Anwendung eine kleine Menge statischer Daten im Speicher an. Der ClassLoader der Laufzeitumge- bung kann einzelne Blöcke einer Datei lesen. Dadurch kann er Teile des zu überset- zenden CIL-Codes laden ohne eine vollständige Kopie der Bibliothek im Speicher anzulegen. Die Bereinigung des Speichers führt der Garbage Collector aus. Er verwendet den Mark-and-Sweep Algorithmus. In periodischen Abständen werden die Objekte mar- kiert, die sich nicht mehr im Gültigkeitsbereich befinden. Bei Überschreitung der definierten Grenze des Speichernutzungsverhältnisses werden die markierten Objekte entfernt. Anschließend wird der Speicher defragmentiert. Die Objekte im Speicher werden neu angeordnet und dadurch größere zusammenhängende Bereiche geschaf- fen. Da die Laufzeitumgebung die Position der noch verwendeten Objekte kennt, stellt die Bewegung im Speicher kein Problem dar. Die Garbage Collection wird ent- weder in einer oder in allen Anwendungsdomänen gleichzeitig durchgeführt. Wäh- rend der Bereinigung wird die Ausführung der Anwendung angehalten. Nachdem alle nicht mehr verwendeten Objekte entfernt wurden, wird diese fortgesetzt. Zusätzlich kann der Garbage Collector den kompilieren Maschinencode entfernen. Wenn der verfügbare Speicher knapp wird, versucht das Betriebssystem Hintergrun- danwendungen zu beenden. Die .NET Anwendung wird über das Deactivate-Ereignis benachrichtigt und kann ihre Anwendungsdaten sichern. [Salm05]

2.3.5 Grafische Benutzungsoberfläche Für die grafische Oberfläche wurde ein Großteil der Steuerelement aus dem Desktop- Framework übernommen. Diese sind in ihren Eigenschaften und Funktionen einge- schränkt. Anwendungen werden immer als Vollbild dargestellt. Diese erhält ein Menü, welches am unteren Bildschirmrand angezeigt wird. Eine Konsole ist im .NET Compact Framework nicht enthalten. Bei der Entwicklung der Grafikbibliothek wurde auf zwei Ziele Wert gelegt. Zum einem soll sie die Erstellung von grafischen Oberflächen aus den High-Level-Steuer- elementen und zum anderen das grafisches Zeichnen und Bitmapoperationen für 2D- Objekte unterstützen. Die Klassen befinden sind in zwei verschiedenen Namensräu- men. Die Grafikbibliothek nutzt die Fähigkeiten des darunter liegenden Windows CE Betriebssystem. Zum Bereich der High-Level-Elemente wird der Namensraum Mi- crosoft.WindowsCE.Forms gezählt werden. Dieser wird durch Referenzieren der Windows CE Bibliothek bereitgestellt und enthält Klassen um spezielle Funktionen des Betriebssystems nutzen zu können. Diese bieten beispielsweise Zugriff auf die Hardwaretasten und Eingabegeräte des Geräts oder spezielle Eigenschaften des Sys- tems, wie die Orientierung des Bildschirms. Der Namensraum System.Windows.Forms bietet eine Teilmenge der High-Level- Steuerelemente des Standard .NET Framework. Er enthält die wichtigsten Elemente, 28 Windows Mobile z.B. Button, TextBox, Label, RadioButton, ComboBox, ListBox, TreeView, Message- Box und ein WebBrowser-Steuerelement. Die Implementierung der Steuerelemente ist auf geringen Speicherverbrauch und hohe Leistung optimiert. Daher werden nicht alle Eigenschaften und Ereignisse unterstützt. Eigene Steuerelemente können durch das Ableiten von den Basisklassen erweitert oder benutzerdefinierte Steuerelemente erstellt werden. Die Klassen der Low-Level-Programmierung befinden sich im Namensraum Sys- tem.Drawing. Auch dieser Namensraum beinhaltet eine Teilmenge der Bibliothek des Desktop-Framework. Die Klasse Graphics stellt Methoden zum Ausführen von Zei- chen-, Füll- und Transformationsoperationen bereit. Die CreateGraphics-Methode der High-Level-Elemente erzeugt das Graphics-Objekt zum Zeichnen in dem Steuer- element. Die abstrakte Image-Klasse stellt Funktionen für die Erzeugung von Bildern aus verschiedenen Quellen und einfache Operationen bereit. Über die DrawImage Methode des Graphics-Objekts wird das Bild auf den Bildschirm oder in den Ar- beitsspeicher gezeichnet. Prozessorintensive Funktionen und Eigenschaften sind im .NET Compact Frame- work nicht vorhanden. Einige Elemente stehen aufgrund der Eingabemöglichkeiten nur auf der Pocket PC Plattform zur Verfügung. [Yang07]

2.3.6 Persistente Datenspeicherung Das .NET Compact Framework bietet verschiedene Möglichkeiten an, um Daten per- sistent zu sichern. Seit Version 2.0 des Frameworks kann, über die Registry-Klasse aus dem Micro- soft.Win32 Namensraum, auf die Registrierungsdatenbank des Windows Betriebssys- tem zugegriffen werden. Anwendungen können in dieser Einstellungen ablegen. Die- se stehen beim nächsten Start der Anwendung zur Verfügung. Der Aufbau der Daten- bank ist an den der anderen Windows Versionen angelehnt. Über statische Methoden können Schlüssel-Wert-Paare aus der Datenbank abgerufen oder abgelegt und Unter- schlüssel erzeugt oder gelöscht werden. Eine weitere Möglichkeit bietet der System.IO Namensraum. Er enthält Klassen um Dateioperationen durchzuführen. Die File-Klasse enthält Funktionen zum Lesen und Schreiben von Dateien. Informationen können über die FileInfo- und DirectoryInfo- Klassen abgerufen werden. Der Zugriff auf den Inhalt der Datei wird über spezielle Reader- und Writer-Klassen bereitgestellt. Der BinaryReader wird verwendet um primitive Datentypen aus einem Datenstrom zu lesen, während der TextReader Zeichen- ketten lesen kann. Dieser wird durch die abstrakte Klasse Stream repräsentiert. Der Zugriff auf das Dateisystem kann vom Hersteller gesperrt sein und führt zu einer Si- cherheitsausnahme. [Yang07] Die umfangreichste Funktionalität bietet die Technologie ADO.NET des .NET Fra- mework. Sie bietet eine Datenbankschnittstelle und effiziente Verwaltung von Daten aus verschiedenen Quellen. Im Namensraum System.Data befinden sich die Klassen zur Verwaltung, Anzeige und Synchronisation der Daten. Der Zugriff auf die Daten kann direkt, über SQL Anweisungen, oder indirekt, über ein Datenobjekt im Ar- beitsspeicher, erfolgen. Das Hauptelement der ADO.NET Architektur ist das Data- Set. Es besteht aus Tabellen, die durch Relationen verbunden sein können, und kann ein XML-Schema enthalten. Die DataTable-Klasse bietet Zugriff auf die Spalten und Windows Mobile 29

Zeilen einer Tabelle und enthält die Einschränkungen. Im Gegensatz zu anderen Da- tenbanktechnologien ist in ADO.NET die Unterstützung für XML integriert. Das Da- taSet und die DataTable können XML-Dateien lesen und schreiben. [Pant05],

Abbildung 11: ADO.NET DataSet Struktur [Micr03] Darüber hinaus steht für die Betriebssysteme Windows Mobile und Windows CE eine optionale Komponente zur Verfügung, der Microsoft SQL Server CE. Dieser bietet die Funktionen einer relationalen Datenbank und ist für mobile Geräte konzipiert. Er arbeitet effizient und kann komplexe SQL-Anfragen auf der lokalen Datenbank aus- führen. Der Server verfügt über die Standardeigenschaften einer Datenbank und kann als DataProvider genutzt werden. Dieser ermöglicht den Zugriff auf die Daten aus unterschiedlichen Datenquellen. Die Größe der Datenbank ist auf 2GB beschränkt. Der Server besteht aus der Datenbase Engine, dem Client Agent und dem Query Analyzer. Dieser bietet eine grafische Oberfläche zum Erstellen und Strukturieren einer Datenbank. Die Datenbank unterstützt die Befehle INSERT, UPDATE und DE- LETE und CREATE, DROP und ALTER. .NET Anwendungen nutzen die Schnittstelle DataProvider aus dem System.Data.Sql- ServerCE Namensraum um auf die Daten der Datenbank zuzugreifen. Über Remote Data Access (RDA) können Teile einer entfernten Datenbank lokal repliziert und von einer mobilen Anwendung genutzt werden. Veränderungen werden protokolliert und bei Verbindung zum Datenbankserver übertragen. [Fox03]

2.3.7 Multimediaunterstützung Das .NET Compact Framework bietet keine explizite Multimediaunterstützung an. Auf diese wurde wegen des zusätzlichen Speicherplatzes verzichtet. Über einen Shell-Aufruf kann der Windows Media Player zum Abspielen von Video- und Audi- odateien genutzt werden. Zusatzbibliotheken, wie das OpenNETCF Smart Device Framework24, bieten komfortablen Zugriff auf die multimedialen Eigenschaften des Gerätes. [Pant05] Dennoch kann das Waveform Audio Interface des Windows CE Betriebssystems genutzt werden. Der Zugriff auf die Schnittstelle wird durch die Platform Invoke (P/In- voke) Bibliothek ermöglicht. Diese erlaubt den Aufruf von native Funktionen. Im Ar- tikel [Schw04] wird eine Beispielimplementierung zur Wiedergabe und Aufnahme von Audiodaten vorgestellt.

24 http://www.opennetcf.org/ 30 Windows Mobile

2.3.8 Kommunikationsschnittstellen Das .NET Compact Framework stellt Bibliotheken für den Zugriff auf Netzwerk- funktionen im Namensraum System.Net bereit. Dieser bietet einen Teil der Funktio- nalität des .NET Framework an, darunter Socketprogrammierung und Verbindungen über das Hypertext Transport Protokoll. Die abstrakte Klasse WebRequest ist die Basisklasse für Protokolle der Anwendungs- schicht des OSI-Referenzmodells. Die statische Methode Create erzeugt unter Anga- be eines Uniform Resource Identifier (URI) eine Instanz der Verbindung. Für die Pro- tokolle http, https und file werden spezifische Klassen bereitgestellt, die Funktionen für Zugriff auf die speziellen Eigenschaften enthalten. Über die HttpWebRequest- Klasse können beispielsweise die Werte des HTTP-Headers und die HTTP-Methode festgelegt werden. Den Aufruf der GetResponse-Methode stellt die Verbindung zum Webserver her und liefert das WebResponse-Objekt. Diese enthält Informationen über den Status und die Antwort als Datenstrom. Aus dem Datenstrom wird über spezielle StreamReader einzelne Zeichen oder die komplette Nachricht gelesen werden. Über die Socket-Klasse wird der Zugriff auf die Transportschicht des OSI-Referenzmo- dells ermöglicht. Der System.Net.Sockets Namensraum bietet Klient- und Serverim- plementierungen für die Transportprotokolle TCP und UDP an. Das .NET Compact Framework bietet darüber hinaus eine Bibliothek für die Infrarot- schnittstelle des Gerätes an. Diese arbeitet über Sockets und enthält Funktionen um andere Geräte zu suchen. Für die Bluetooth-Schnittstelle wird keine Bibliothek angeboten. [Wigl07]

2.3.9 Sicherheitsmechanismen Grundsätzlich erlaubt die Sicherheitsrichtlinie des .NET Compact Framework die un- eingeschränkte Ausführung von Anwendungen. Gerätehersteller können eine eigene Sicherheitsrichtlinie definieren und die Ausführung von Programmen verweigern und den Zugriff auf Ressourcen einschränken. Softwarehersteller können eigene Sicher- heitsanforderungen in der Anwendung implementieren. Die Richtlinien unterscheiden sich je nach Art des Gerätetyps. Die Anwendungen werden innerhalb einer Anwendungsdomäne isoliert ausgeführt. Die CLR verwaltet mehrere Anwendungsdomänen, von denen jede eine eigene Ko- pie der Klassenbibliothek nutzt. Dies bietet den Vorteil der Fehlerisolation und verbessert die Stabilität des Gesamtsystems. Die Laufzeitumgebung behält die Kontrolle über die Anwendungen, verhindert den Zugriff auf fremden Speicherbereich und stellt sicher, dass die genutzten Ressourcen nach Beendigung der Anwendung freigegeben werden. Ein weiteres Sicherheitskonzept ist im Entwurf der Laufzeitumgebung zentral veran- kert. Basierend auf einem Beweis werden Zugriffsrechte durch definierte Regeln er- teilt. Die Überprüfung kann anhand einer kryptographische Signatur des Herstellers oder den sogenannten starken Namen25 einer Softwarekomponente erfolgen. Dieser setzt sich aus dem Namen, der Versionsnummer sowie einem öffentlichen Schlüssel und einer digitalen Signatur zusammen und wird aus der Assembly erstellt. Anhand dieser Informationen werden die Rechte der Anwendungen eingeschränkt. Diese beeinflussen die Ausführung der Anwendungen oder den Zugriff auf Ressourcen.

25 eng.: strong name Windows Mobile 31

Das Windows Mobile Sicherheitsmodell bestimmt ob eine Anwendungen ausgeführt wird. Der Anwendungscode wird zuerst auf eine Signatur geprüft und die Rechte der Anwendung festgelegt. Enthält die Anwendung keine Signatur wird die Sicherheits- richtlinie des Gerätes verwendet. In dieser ist festgelegt, ob Anwendungen ohne Si- gnatur ausgeführt werden. Ist die Ausführung erlaubt, wird eine weiterer Wert der Richtlinie geprüft. Über diesen wird festgelegt, ob der Benutzer seine Zustimmung geben muss. Stimmt dieser zu oder wird die Zustimmung nicht benötigt erhält die Anwendung vollständigen Zugriff auf das Gerät. [Yang07]

2.3.10 Native Programmierung Über den Platform Invoke (P/Invoke) Mechanismus können native Funktionen, die in C oder C++ geschrieben sind, aus verwalteten Code aufgerufen werden. Dies erlaubt die Verwendung vorhandener Funktionen. Beispielsweise können dadurch Funktio- nen des Betriebssystems oder native Bibliotheken des Geräteherstellers genutzt werden, die nicht als verwalteten Code angeboten werden. Die Funktionalität wird im Namensraum System.Runtime.InteropServices bereitgestellt. Das .NET Compact Framework unterstützt seit Version 2.0 die Interaktion mit dem Component Object Model (COM). Über dieses objektorientierte Programmiermodell können native Komponenten genutzt werden. Diese wird über eine bereitgestellte Typenbibliothek oder eine manuell definierte Schnittstelle der Anwendung zur Verfügung gestellt. [Maue09], [Wigl07]

2.3.11 Entwicklungsumgebung Microsoft stellt für die Entwicklung von Anwendungen für intelligenten Geräte ein Software Development Kit zur Verfügung. Dieses enthält Bibliotheken, Dokumentati- on und Beispielcode. Weiterer Bestandteil sind die Abbilder der unterstützten Geräte- plattformen. Diese werden vom Device Emulator ausgeführt. Auf diese Weise kön- nen die Anwendungen getestet werden. Da das SDK nur die Bibliotheken für Win- dows Mobile enthält, muss das .NET Compact Framework zusätzlich installiert werden.

Abbildung 12: Visual Studio IDE Die Werkzeuge des SDK integrieren sich in die Entwicklungsumgebung Visual Stu- dio. Damit bietet sie umfassende Unterstützung für die Erstellung von nativen und verwalteten Anwendungen für mobile Geräte. Sie stellt, unabhängig von der verwendeten Programmiersprache, einen Quellcodeeditor mit Syntaxprüfung, Schlüsselwor- thervorhebung und eine Onlinehilfe bereit. Der Formulardesigner unterstützt die Er- stellung von Benutzeroberflächen und der Debugger bietet Funktionen zum Finden 32 Windows Mobile von Fehlern. Die Visual Studio Tools übernehmen das Verpacken der Anwendung und Ressourcen in ein komprimiertes CAB-Archiv. Diese vereinfacht die Bereitstellung der Anwendung auf dem Gerät.

2.3.12 Besonderheiten der Plattform Das .NET Compact Framework ist die mobile Version des .NET Framework und für Geräte mit beschränken Ressourcen konzipiert. Die Anpassungsschicht der Architek- tur erlaubt die Ausführung auf unterschiedlichen Betriebssystemen. Die optimierte Common Language Runtime überwacht die Ausführung der Anwendungen und die verwendeten Ressourcen. Der integrierte Just-In-Time-Compiler übersetzt den stan- dardisierten Byte-Code in Maschinencode. Die Klassenbibliothek ist eine Untermen- ge der .NET Framework Klassenbibliothek und enthält optimierte Funktionen. Die Eigenschaften des Betriebssystems können über nativer Funktionen genutzt werden. Für die Entwicklung von Anwendungen werden die gleichen Werkzeuge, Program- miermodell und Dokumentation genutzt. Derzeit wird das .NET Compact Frame- work nur von den Betriebssystemen Windows CE und Windows Mobile unterstützt. Android 33

2.4 Android Auf Initiative von Google wurde im Jahr 2007 die Open Handset Alliance26 gegrün- det, um offene Standards für mobile Geräte zu entwickeln. Zu den Mitgliedern zäh- len mehr als 30 namhafte Unternehmen, darunter die Gerätehersteller (Original Equipment Manufacturer) Samsung, Motorola und HTC, die Chiphersteller (Core Technology Vendor) Texas Instruments und Intel, die Netzbetreiber (Operators) T- Mobile und Telefonica und die Softwareunternehmen (Independent Software Vendor) E-Bay und Nuance. Das gemeinsames Ziel ist die Entwicklung einer mobilen Platt- form für eine neue Klasse von Mobiltelefonen, dem Handset-Standard. Diese standardisierte Plattform trägt den Namen Android27 und soll durch verbesserte und neue Funktionen, intuitive Bedienung, eine hohe Individualisierung des Endgerätes und geringe Kosten der Endgeräte beim Kunden zur verstärkten mobilen Onlinenutzung führen. Die Geräte sollen die Entwicklung neuer und innovative Anwendungen er- möglichen. Android ist die erste offene und freie mobile Plattform für Smartphones. Bereits im Juli 2005 erwarb Google die bis dahin unbekannte Android-Plattform durch Übernah- me der Firma Android Inc. [Elgi05]

2.4.1 Android-Plattform Android definiert den gesamten Aufbau der Plattform, vom Betriebssystem bis zu den Anwendungen, und ist deshalb mehr als eine Ausführungsumgebung und An- wendungsframework. Die Komponenten der Plattform stehen alle unter der Open- Source Lizenz. Dies bedeutet, dass für die Verwendung des Systems keine Lizenz- kosten für den Endgerätehersteller anfallen. Aus diesem Grund wird ein Linux Kern als Betriebssystem eingesetzt und durch eine große Menge an austauschbaren Open- Source Bibliotheken vervollständigt. Vollendet wird die Plattform durch die Laufzeit- umgebung und das umfangreiche Anwendungsframework. Die Offenheit steht im Mittelpunkt der Android-Plattform. Diese Philosophie unterscheidet sie von anderen Plattformen und erstreckt sich über alle Komponenten. Der Programmierer kann die Hardware über das Anwendungsframework ohne großen Aufwand nutzen. Bereits vorinstallierten Anwendungen können angepasst oder ersetzt werden. Beispielsweise kann die übliche Anzeige der Telefontastatur zum Wäh- len durch eine eher altertümliche Wahlscheibe ersetzt werden oder der integrierte E- Mail-Klient angepasst werden, so dass er nur über die sichere Verbindung des Fir- menservers arbeitet. Die offene Einstellung setzt sich bei den Integrationsmöglichkeiten der Hardware fort. Die Gerätehersteller haben die freie Wahl bei der Ausstattung ihrer Geräte. Ne- ben den verbreiteten Übertragungstechniken, GSM, GPRS, Bluetooth oder WLAN, wird auch Satellitentelefonie unterstützt. Die Plattform stellt keine Anforderungen an die Form und Größe des Bildschirms. Die Eingabe kann über Touchscreen, Tastatur, Wahlräder, Tasten am Gehäuse oder über Sprachsteuerung erfolgen. Über die typi- schen Merkmale, wie die integrierte Digitalkamera, Speicherkartenerweiterungen und GPS-Empfänger, hinaus ist das System offen für die Integration weiterer Hard-

26 http://www.openhandsetalliance.com/ 27 http://www.android.com/ 34 Android warekomponenten, z.B. hochqualitative Soundausgabe, DVB-H- und 3D-Grafik- chips. Die Android-Plattform stellt keine hohen Anforderungen an die Hardware. Das System benötigt ca. 40 MB Speicher und 10 MB Speicher für die Anwendungsbiblio- theken. Somit ist es bereits auf Geräten mit 64 MB Arbeitsspeicher lauffähig. Die OHA geht davon aus, dass die Kombinationsmöglichkeiten zu einer Vielfalt an Handsets führt, welche sich nicht nur von Design, sondern auch durch die Ausstat- tungsmerkmale unterscheiden. Nur eine knappe Woche nach Ankündigung der Plattform veröffentlichte Google im November 2007 das erste Software Development Kit. Seit August 2008 steht es in der Version 1.0 zur Verfügung. Zusätzlich wird Google eine Internetplattform für Andro- id-Anwendungen bereitstellen, auf der Nutzer suchen und Entwickler ihre Anwen- dungen anbieten können. Mit der Android Developer Challenge hat Google zudem einen Wettbewerb gestartet, um Anwendungen für Android-Geräte zu entwickeln. [Cond08], [Scha08]

2.4.2 Architektur Die Architektur der Android-Plattform teilt sich in die 4 Schichten.

Abbildung 13: Architektur [Goog08] Die unterste Schicht bildet das Betriebssystem von Android. Die Plattform setzt, statt kompletter Neuentwicklung, auf ein Betriebssystem aus dem Open-Source Bereich. Aufgrund der freien Verfügbarkeit des Quelltextes kommt der unter GNU General Public License (GPL) stehende Linux Kernel 2.6 zum Einsatz. Dieser bietet die Sys- temdienste Sicherheit, Speicherverwaltung, Prozessverwaltung, Netzwerkunterstüt- zung und Dateisystemzugriff. Die Lizenz gestattet die Optimierung des eingesetzten Kernels für den Einsatz auf mobilen Endgeräte. Dieser steht derzeit für die ARM-Mi- kroprozessoren zur Verfügung, die in mobilen Geräten eingesetzt werden. Weitere Android 35

Prozessorarchitekturen sind durch spezielle Anpassungen möglich. Die Veränderun- gen am Kernel müssen unter der gleichen Lizenz veröffentlicht werden und stehen jedem kostenlos zur Verfügung. Der Linux Kernel bietet neben den Kernsystemdiensten eines Betriebssystems, eine modulare Architektur für gemeinsam genutzte Bibliotheken und ein bewährtes Trei- bermodell. Er bildet damit eine einheitliche Abstraktionsschicht zwischen Hardware und Software. Neue Hardware kann über Treiber der Hersteller in das Linux Be- triebssystem integriert werden. Der Android-Kernel enthält alle hardwarenahen Trei- ber (Abbildung 13) für den Zugriff auf den Bildschirm, Kamera, Bluetooth oder WiFi, Dateisystem und USB-Geräte, sowie Dienste für die Kommunikation zwischen Prozessen und eine erweiterte Energieverwaltung. Der Philosophie der Android-Platt- form entsprechend steht der Quellcode28 der Öffentlichkeit zur Verfügung. Für die Entwicklung des Kernel bietet Google eine Versionsverwaltung an, über die die neus- ten Verbesserungen und Fehlerbehebungen abgerufen werden können. Die zweite Schicht der Android-Plattform teilt sich in die nativen C und C++ Biblio- theken und die Laufzeitumgebung. Die Bibliotheken sind die Grundlage für die Dienste und das Anwendungsframe- work. Sie bieten grundlegende Funktionen und fördern die Wiederverwendung von Komponenten mit der Leistungsfähigkeit der nativen Implementierung. Auch die Bi- bliotheken sind für Geräte mit beschränkten Ressourcen optimiert. Da sie Bestandteil jeder Anwendung sind, wurde ihre Größe im Speicher minimiert und die Ausfüh- rungsgeschwindigkeit verbessert. Die Hauptbibliothek ist die Bionic libc, eine von Google entwickelte C Bibliothek. Sie ist nur halb so groß wie die GNU libc, enthält spezifische Funktionen des Android-Systems und ist die Basis für weitere native Bi- bliotheken. Diese sind in Abbildung 13 im grünen Bereich dargestellt. Die Schicht enthält die Systemdienste, den Surface Manager zur Darstellung mehrerer Schichten auf dem Bildschirm und Bibliotheken mit Browser-, Multimedia-, OpenGL- und Da- tenbankunterstützung. Zusätzlich beinhaltet die Schicht noch Bibliotheken der Hard- wareabstraktionsschicht, die die Schnittstelle zu den Treibern definieren und das An- droid-System mit der Hardware verbindet. Der gelbe Bereich in Abbildung 13 enthält die Laufzeitumgebung. In diesem befindet sich die Dalvik Virtual Machine (Dalvik VM), die Hauptkomponente der Android- Plattform. Sie wurde speziell für Android entwickelt und für Umgebungen, in denen die Rechenleistung, der Haupt- und Datenspeicher nur beschränkt zur Verfügung stehen, optimiert. Die Dalvik VM führt die Anwendungen auf dem System aus. Sie bildet die Basis für die Portabilität von Programmen auf verschiedene Android-Syste- me. Auf weitere Details wird im folgendem Kapitel Laufzeitumgebung eingegangen. Ein weiterer Bestandteil der Laufzeitumgebung sind die in Java implementierten Ba- sisbibliotheken (Core Libraries). Sie enthalten den größten Teil der Funktionalität der Java Programmiersprache. Die nächste Schicht bildet das umfangreiche Anwendungsframework der Android- Plattform. Dieses stellt Klassen, Schnittstellen und Typen für die Entwicklung von Anwendungen und Softwarekomponenten zur Verfügung und ist in der Programmier- sprache Java implementiert. Das Framework bietet zahlreiche vorgefertigte Kompo- nenten und ist die Schnittstellen für alle Anwendungen. Es besteht aus dem Apache Harmony Projekt, der Open Source Java SE-Implementierung der Apache Software

28 http://source.android.com/ 36 Android

Foundation, und spezifischen Paketen des Android-Systems. Weitere Bibliotheken enthalten Funktionen zum Testen der Anwendung und bieten Zugriff auf die Hardwa- re. Darüber hinaus bietet das Framework eine Vielzahl integrierter Manager und Content Provider. Diese verwalten die Darstellung auf dem Bildschirm bieten den Zugriff auf die unterstützten Eingabemöglichkeiten, das Netzwerk, Speichermedien, und Telefoniefunktionen. Das modulare Framework stellt damit die Basis für gleich- berechtigte und austauschbare Anwendungen dar. In der obersten Schicht befinden sich die Anwendungen. Im Gegensatz zu anderen Plattformen nutzen alle Anwendungen die gleiche Programmierschnittstelle. Durch die parallelen Ausführung können Anwendungen einfach verbunden und Funktionen von anderen Anwendungen genutzt werden. Die Anwendungen können durch Alter- nativen ergänzt oder ersetzt werden. Das Anwendungsmodell von Android besteht aus den drei Teilen Android Package, Task und Prozess. Im Gegensatz zu den meisten Betriebssystemen besteht in Android keine 1-zu-1 Relation zwischen Anwendungscode, der Anwendung und dem Prozess. Anwendungsteile können in einem eigenem Prozess ausgeführt oder als Teil ein anderen Anwendungen genutzt werden. Das Android Package (APK) enthält den An- wendungscode und die Ressourcen der Anwendung und wird in komprimierter Form abgespeichert. Dadurch können die Anwendungen einfach verteilt und auf den An- droid-Systemen installieren werden. Ein Task repräsentiert für den Nutzer eine An- wendung und besteht aus Komponenten mehrere Anwendungen. Die Dalvik VM wird in einem eigenem Linux Prozess gestartet und führt die Anwendung in einem Thread aus. Eine Anwendung kann aus vier kombinierbaren Anwendungsblöcken bestehen, der Activity, Broadcast Intent Receiver, Service oder Content Provider. Die eingesetzten Komponenten müssen in der globalen Datei AndroidManifest.xml deklariert werden. Sie befindet sich im Stammverzeichnis jeder Android-Anwendung und enthält globa- le Werte, die Beschreibung der Programmteile und deren Eigenschaften, sowie die benötigten Zugriffsrechte auf die Systemdienste. Die Aktivität ist der zentrale Baustein für Programme mit grafischer Oberfläche. Sie wird in einer separaten, von der Basisklasse Activity abgeleiteten, Klasse implementiert. Eine Aktivität repräsentiert eine einzelne Benutzeroberfläche der Anwendung. Eine Anwendung besteht meist aus mehreren Aktivitäten. Sie ist für die Anzeige auf dem Bildschirm und für die Behandlung von Nutzereingaben zuständig. Im Manifest wird die Startaktivität festgelegt. Die Aktivitäten können von anderen Anwendung gestartet werden. Beim Wechsel wird die aktuelle Aktivität pausiert, der Zustand gesichert und auf dem History Stack im Systemprozess abgelegt und die neue Aktivität angezeigt. Nach Beendigung wird die vorherige Aktivität wieder gestartet und ihr Zu- stand wiederhergestellt. Aktivitäten einer Anwendung können sich als Broadcast Intent Receiver im System registrieren und durch Nachrichten mit einer Absichtserklärung, dem Intent, gestartet werden. Die Nachrichten werden als Broadcast im System gesendet. Dieser Mecha- nismus wird genutzt um zu einer Aktivität oder zu einer anderen Anwendung zu wechseln. Die Absichtserklärung setzt sich aus einer Aktion und den Daten, die durch einen Uniform Resource Identifier repräsentiert werden, zusammen. Registrie- ren sich mehrere Aktivitäten zu einer Aktion werden diese in einer Auswahlliste angezeigt. Da die Anwendungen gleichberechtigt sind, können vorinstallierten Anwen- Android 37 dungen durch Eigene ersetzt werden, indem sie auf die gleichen Systemnachrichten reagieren. Der Mechanismus erlaubt das Wiederverwenden von Aktivitäten über die Grenzen einer Anwendung hinaus und ist nicht so trivial wie das Erstellen und An- zeigen eines Fensters auf anderen Plattformen.

Abbildung 14: Interaktion der Anwendungskomponenten [Huebn08] Ein Service ist ein Dienst der im Hintergrund für eine längere Zeit ausgeführt wird. Er besitzt meist keine grafische Oberfläche und verfügt über keine direkte Interaktion mit dem Benutzer. Dieser kann beispielsweise zum Abspielen von Mediendateien genutzt werden. Eine Anwendung kann sich mit dem Service verbinden und über eine definierte Schnittstelle kommunizieren. Die Daten einer Anwendung sind durch die User ID des Linux Prozesses vom Sys- tem geschützt. Fremde Anwendungen können aufgrund des Sicherheitsmodells nicht auf diese zugreifen. Um die Daten anderen Anwendungen zur Verfügung zu stellen wird ein Content Provider benötigt. Dieser bietet Standardfunktionen zum Abrufen, Einfügen, Ändern und Löschen der Daten an. Die genaue Implementierung der Da- tenspeicherung ist dem Content Provider überlassen. Er muss die Methoden der abstrakten Klasse ContentProvider implementieren um den Zugriff zu ermöglichen. Der Content Provider wird durch eine eindeutige URI mit dem Schema content:// re- präsentiert. Das Anwendungsframework enthält Provider für Audio-, Video- und Bilddaten oder für den Zugriff auf die Kontaktliste des Android-Systems. Diese Liste hält die Kontakte in einem globalen Datenbankobjekt bereit. [Morr08], [SDT08]

2.4.3 Laufzeitumgebung Hauptbestandteil der Laufzeitumgebung ist die von Dan Bornstein und anderen Goo- gle Ingenieuren für die Android-Plattform entwickelte Dalvik VM. Diese virtuelle Maschine wurde speziell für Umgebungen mit beschränktem Speicher, limitierter Energieversorgung und geringer Leistung optimiert. Sie ist für parallele Ausführung vorbereitet, da jede Anwendung in einer eigenen Instanz ausgeführt wird. Anwen- 38 Android dungen werden in der Programmiersprache Java geschrieben und nutzen die Biblio- theken der Java Standard Edition. Der Byte-Code wird durch den Standard Java Compiler erstellt. Die Dalvik VM ist, im Gegensatz zur Java VM (Stackmaschine), eine Registermaschine. Sie benötigt für die Ausführung von komplexen Operationen weniger Maschinencodebefehle, da die Operanden in Registern abgelegt sind. Dies bedeutet, dass der erzeugte Byte-Code des Standard Java Compiler nicht lauffähig ist. Deshalb müssen die kompilierten Klassendateien in sogenannte Dalvik Executables29 konvertiert werden, bevor sie auf der Android-Plattformen ausgeführt werden kön- nen. Die Transformation findet während der Erstellung des Android Package statt und wird vom Dalvik Cross Assembler durchgeführt. Aus mehreren Java Klassenda- teien wird eine Dalvik Executable erstellt. Sie enthält den Dalvik Byte-Code mit effi- zienter Speichernutzung und optimierten Datenstrukturen. Die Verwendung der Java SE-Bibliotheken der Apache Harmony Implementierung steigert die Chance, dass vorhandene Bibliotheken genutzt werden können. Die Android-Anwendung wird von der Dalvik VM ausgeführt. Die Instanz wird aus Sicherheitsgründen in einem eigenen Linux Prozess gestartet und dadurch die Beein- flussung des Gesamtsystems im Fehlerfall verhindert. Der Hauptprozess erzeugt durch Aufspaltung30 den Anwendungsprozess und startet die Dalvik VM Instanz. Die Anwendung wird durch den Intent mit der Aktion Action.MAIN gestartet und die im Manifest definierte Aktivität angezeigt. Die Anwendungen verbleiben nach Beendi- gung im Speicher. Das System entfernt unwichtige oder ungenutzte Anwendungen wenn zusätzlicher Speicher benötigt wird. Für die Kommunikation zwischen den Prozessen, z.B. grafischer Oberfläche und Service, wird die Android Interface Definition Language (AIDL), eine Schnittstellen- beschreibungssprache für Inter Process Communication (IPC), genutzt. Dafür muss das zu tauschende Objekt in die primitiven Datentypen des Systems überführt werden. Die AIDL besteht aus einer einfachen Syntax zur Definition von Funktionen einer Schnittstelle. Der Lebenszyklus einer Anwendung wird von der Laufzeitumgebung verwaltet. Der aktuelle Zustand wird durch das System ermittelt und der Anwendung mitgeteilt. Die Laufzeitumgebung analysiert die Anwendungsteile der gestarteten Prozesse und legt die Priorität der Anwendung anhand definierter Regeln fest. Abbildung 15 zeigt die Zustände einer Aktivität und die Methoden, die beim Zustandswechsel vom System aufgerufen werden. Eine Aktivität wird als aktiv bezeichnet wenn sich die Benutzero- berfläche im Vordergrund befindet. Beim Starten einer weiteren Aktivität wird der in- terne Status der aktuellen Aktivität gesichert und diese in einen pausierten Zustand gesetzt. Die Aktivität verbleibt im Speicher, sodass sie innerhalb kurzer Zeit wieder aktiviert werden kann. Benötigt eine andere Anwendung den Speicher, wird eine pausierte Aktivität entfernt und der zugehörige Prozess beendet. Kommt eine bereits beendete Aktivität wieder in den Vordergrund wird diese neu gestartet und der gesi- cherte Status wiederhergestellt. Der Prozess einer zerstörten Aktivität wird vom Sys- tem beendet. Bei der Entwicklung muss der Mechanismus der Priorisierung beachtet werden, damit eine zeitaufwendige Operation nicht vorzeitig durch das System beendet wird. Die genaue Auflistung der Prioritäten befindet sich in der Android Doku- mentation31 unter dem Punkt Application Life Cycle.

29 Android spezifisches Byte-Code Format 30 Linux fork 31 http://code.google.com/intl/de-DE/android/documentation.html Android 39

Abbildung 15: Lebenszyklus einer Android Aktivität [Goog08]

Die Energieverwaltung setzt auf dem im Kernel integrierten Energiemanagement auf. Sie verfolgt einen aggressiven Ansatz. Der Prozessor, der Bildschirm und andere Ge- räte werden deaktiviert, wenn sie nicht benötigt werden. Die automatische Deaktivie- rung kann über den Power Manager verzögert oder verhindert werden. Beispielswei- se muss für das Abspielen einer Musikdatei den Prozessor aktiv sein, während der Bildschirm nach ein paar Sekunden ausgeschaltet werden kann. [Born08], [Brad08], [Prin08]

2.4.4 Speicherverwaltung Die Bereitstellung von Speicher ist die Aufgabe des Betriebssystems. Das Memory Management Subsystem des Linux Kernel ist für die Verwaltung des Arbeitsspeichers zuständig. In den höheren Schichten ist die Dalvik VM und der optimierte Byte-Code für eine optimierte Speichernutzung verantwortlich. Der Standard Java Compiler erstellt eine virtuelle Abbildungstabelle mit den Signaturen der Methoden für jede Klasse, für gleiche Signaturen werden mehrfache Einträge angelegt. Diese Einträge verbrauchen zusätzlichen aber unnötigen Speicher. Nach der Konvertierung zu Dalvik Byte-Code zeigt jede Klasse nur auf eine einzige Kopie der Signatur. Dies bringt eine wesentli- 40 Android che Verringerung des Speicherverbrauchs innerhalb einer Anwendung mit sich. Jede Anwendung wird aus Sicherheitsgründen in einer eigenen Dalvik VM in einem einzelnen Linux Prozess ausgeführt. Aufgrund der Struktur einer Java Klassendatei enthält jeder Java VM Prozess eine eigene Kopie von vielfach genutzten Anwen- dungscode, beispielsweise einer HashMap. Die Dalvik VM nutzt ein anderes Spei- cherlayout für Byte-Code. Die Klassen verweisen alle auf ein einzige Kopie des An- wendungscodes im Speicher. Dies reduziert zusätzlich den benötigten Speicher. Die Optimierungen werden durch das Zusammenfassen mehrerer Java Klassendatei- en zu einer Dalvik Executable ermöglicht und bei der Erstellung des Android Packa- ge durchgeführt.

2.4.5 Grafische Benutzungsoberfläche Die Offenheit der Android-Plattform, bezüglich Bildschirmgröße, Auflösung und Eingabemöglichkeiten, verlangt nach speziellen Elementen für die grafische Benut- zungsoberfläche. Das Framework enthält neu entwickelte GUI-Komponenten, die einfacher als die Elemente der Swing32 Grafikbibliothek, aber mächtiger als die Items des LCDUI der Java Micro Edition sind. Die Klassen befinden sich im Paket android.view.

Abbildung 16: Hierarchie von Layout und View [Goog08] Ein einfacher grafischer Bildschirm wird in Android durch die Klasse View repräsen- tiert. Diese verwaltet einen rechteckigen Bereich des Bildschirms, ist für das Zeich- nen des eigenen Inhalts zuständig und gibt Benutzereingaben an den zuständigen View weiter. Diese Basisklasse bildet die Grundlage für alle interaktiven Benutzerele- mente, den Widgets. Diese vordefinierten Elemente verwalten sich selbst und ermög- lichen eine einfache und schnelle Erstellung grafischer Oberflächen. Das Framework enthält neben den Standardelementen Button, CheckBox, RadioButton, EditText, Pro- gressBar auch neuartige und komplexere Elemente wie ImageButton, Gallery, Ana-

32 http://java.sun.com/docs/books/tutorial/uiswing/index.html Android 41 log- und DigitalClock oder Date- und TimePickerDialog. Abbildung 16 zeigt, das mehrere Elemente in Gruppen, den ViewGroups, in einer Baumstruktur angeordnet werden können. Die ViewGroup-Klasse enthält spezielle Funktionen zur Verwaltung der Elemente. Die Anordnung der Elemente auf dem Bildschirm wird über Layouts realisiert. Das GUI-Framework enthält zu diesem Zweck vorgefertigte Layoutklassen, die die Steu- erelemente oder Gruppen anordnen. Die Kindelemente dieser Klassen werden anhand von Eigenschaften, den LayoutParams, in dem Layout positioniert. Die Höhe und Breite der Elemente kann dynamisch an den Inhalt oder absolut festgelegt werden. Die wichtigsten Layouts sind das Absolute-, Relative- und das LinearLayout. Im TableLayout können Daten in tabellarischer Form angezeigt werden. Die Layouts ge- hören zu den ViewGroups und lassen sich gleichermaßen hierarchisch anordnen. Da- durch können die besonderen Eigenschaften der Layouts kombiniert werden. Android unterstützt neben der programmatischen Erstellung auch die deklarative Be- schreibung der Benutzeroberfläche. Die Struktur und Eigenschaften der Elemente wird in einer XML-Datei definiert. Diese kann von einer Aktivität angezeigt werden. Zur Laufzeit kann auf die Elemente über das Attribut android:id des XML-Elements zugegriffen werden.