Großer Beleg. bearbeitet von. René Dienel. geboren am in Zittau. Matrikelnummer: Technische Universität Dresden

Transkript

1 Großer Beleg Vergleich von Plattformen für Mobile Geräte bearbeitet von René Dienel geboren am in Zittau Matrikelnummer: 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:

2

3 1 Inhaltsverzeichnis 1 Einleitung Mobile Geräte Limitierungen Plattformen Aufbau der Arbeit Plattformen Kriterienkatalog Architektur Laufzeitumgebung Speicherverwaltung Grafische Benutzungsoberfläche Persistente Datenspeicherung Multimediaunterstützung Kommunikationsschnittstellen Sicherheitsmechanismen Native Programmierung Entwicklungsumgebung Besonderheiten Symbian Java Micro Edition Architektur Laufzeitumgebung Speicherverwaltung Grafische Benutzungsoberfläche Persistente Datenspeicherung Multimediaunterstützung Kommunikationsschnittstellen Sicherheitsmechanismen Native Programmierung Entwicklungsumgebung Besonderheiten der Plattform Windows Mobile NET Compact Framework Architektur Laufzeitumgebung Speicherverwaltung Grafische Benutzungsoberfläche Persistente Datenspeicherung Multimediaunterstützung Kommunikationsschnittstellen Sicherheitsmechanismen Native Programmierung Entwicklungsumgebung Besonderheiten der Plattform Android Android-Plattform Architektur...34

4 Laufzeitumgebung Speicherverwaltung Grafische Benutzungsoberfläche Persistente Datenspeicherung Multimediaunterstützung Kommunikationsschnittstellen Sicherheitsmechanismen Native Programmierung Entwicklungsumgebung Besonderheiten der Plattform Vergleich der Plattformen Referenzanwendung Konzept Umsetzung Webservice Java ME Klient NET CF Klient Android Klient Auswertung Ausblick...59 Literaturverzeichnis...60 Abbildungsverzeichnis...64 Abkürzungsverzeichnis...65

5 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 Mobilfunkanschlüsse [BIT07]. Statistisch besitzt jeder fünfte Deutsche zwei Mobiltelefone. Diese werden inzwischen nicht mehr nur für ihren vorgesehenen Zweck verwendet. Technologische Entwicklungen haben die Leistungsfähigkeit der Geräte und ihre Eigenschaften enorm verbessert. Sie werden heutzutage als Digitalkamera oder Musikplayer 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 Fahrplanauskunft, fördern die Entwicklung von innovativen Anwendungen. Der Markt wird von verschiedenen geschlossenen oder lizenzpflichtigen Systemen dominiert. Die Programmierung von Anwendungen auf diesen ist sehr aufwendig oder nicht möglich. Die Systeme nutzen ihre eigenen Bibliotheken und unterstützen nur bestimmte Programmiersprachen. Die Vielzahl der Geräte und die große Unterschiede in der Leistungsfähigkeit, der Größe des Bildschirms und der verfügbaren Eingabegeräte, erschweren die gleichzeitige Entwicklung für eine große Anzahl an Geräten. Die Anwendungen 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 Assistenten 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öglichte die Entwicklung von kleineren und leistungsfähigeren Geräten. Das speziell entwickelte Betriebssystem wurde um neue Anwendungen, wie Rechner, Spiele, Multimediaplayer 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 Terminplaner zu einem kompakten Taschencomputer. Dieser ist nicht größer als die Handflä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

6 4 Mobile Geräte dem zusätzliche Anwendungen installiert werden können. Aus den beiden unabhängigen Entwicklungszweigen bildete sich ein neuer Gerätetyp, das Smartphone. Dieser vereinigt die Funktionen der beiden Geräteklassen und verfügt über einen lokalen Speicher, höhere Rechenleistung und Multimediafunktionen. 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 eingeschrä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 begrenzten Rechenleistung sollten Berechnungen auf dem Gerät mit Bedacht ausgefü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 Anwendungen 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 Informationen ein. Daher wird eine angepasste Menüführung benötigt, die auf die Eingabemö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. Datenverbindungen 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 Kommunikation. Diese werden durch die entsprechende Hardware angeboten. Die dafür erforderliche hardwarenahe Programmierung ist zeitintensiv und setzt Hardwarekenntnisse voraus. Deshalb wird eine abstrakte Sicht auf das System benötigt. Abbildung 1 zeigt die Architektur eines mobilen Gerätes, die aus vier aufeinander aufbauenden Schichten besteht. 1 besteht aus den Zahlen 0-9 und den Zeichen * und #

7 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 Systemprogramm kontrolliert die Ressourcen des Systems. Es ermöglicht die Ausführung von Anwendungen und bildet die Basis für die Entwicklung von Anwendungsprogrammen. 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 Plattform definiert zum einen eine Ausführungsumgebung und zum anderen eine Programmierschnittstelle. Die Laufzeitumgebung stellt die erforderlichen Basisfunktionen und -dienste für Anwendungen zur Verfügung und übernimmt, unabhängig von den darunter liegenden Schichten, die Verwaltung des Speichers und weiterer Ressourcen. 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 Wiederverwendung 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

8 6 Plattformen 2 Plattformen In der heutigen Anwendungsentwicklung beschreibt der Begriff Plattform eine Softwareebene zwischen Betriebssystem und den Anwendungen. Sie stellt die benötigten Funktionen zur Ausführung von Anwendungen zur Verfügung, unabhängig von tieferen Systemschichten. Für den Vergleich wird zunächst ein Kriterienkatalog entwickelt. Die zu untersuchenden Plattformen werden, nach einer Beschreibung der Basissysteme, anhand der Kriterien vorgestellt. Abschließend wird der direkte Vergleich der Plattformen durchgeführt. 2.1 Kriterienkatalog Im folgenden werden die Kriterien einer mobilen Plattform definiert. Anhand dieser kann eine Plattform untersucht und mit anderen verglichen werden 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 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 Plattform 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 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 Speicher 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 Gerä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 mehrfach genutzte Ressourcen in einem globalen Speicherbereich abzulegen und den Speicherbedarf zu minimieren.

9 Kriterienkatalog 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 Eigenschaften 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 elementaren Grafikfunktionen und spezielle Möglichkeiten, wie 3D-Unterstützung, der Plattform aufgezeigt werden 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 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 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 Protokolle eingegangen Sicherheitsmechanismen Die Sicherheit innerhalb der Plattform ist auf mobilen Geräten von großer Bedeutung. Die Plattformen muss die Anwendungen sicher ausführen und die Beeinflussung des Systems verhindern. In diesem Kriterium wird auf die Sicherheitsmechanismen der Plattform eingegangen, vordergründig auf die Prüfung des Byte-Code und der Integrität der Anwendungen. Zudem wird auf die Schutzmechanismen, das Rechtemodell und die Fehlerbehandlung eingegangen 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 Programme oder Bibliotheken genutzt werden können Entwicklungsumgebung Für die Entwicklung von Anwendungen wird eine Entwicklungsumgebung für die

10 8 Kriterienkatalog Plattformen benötigt. Daher soll auf das Software Development Kit und unterstützte Entwicklungsumgebungen eingegangen werden Besonderheiten Diesem Kriterium dient zum Beschreiben von besonderen Merkmalen der Plattform. Zudem kann auf spezielle Funktionen und Konzepte eingegangen werden.

11 Symbian 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 Hardwareanforderungen. Die wichtigsten Klassen der Symbian OS Version 6 waren Pearl, Crystal und Quartz. Das Pearl-Design beschreibt ein Mobiltelefon mit numerischem Eingabegerät und kleinem Farbbildschirm. Crystal-Design Geräte besitzen eine vollständige 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 übertragen. 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 Funktionen, 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 schnellerer 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 Programmiersprachen C++ und Java für die Anwendungsentwicklung. Die native Programmierung in C++ bietet den Programmierern hohe Flexibilität bei der Anwendungsentwicklung und Zugriff auf alle öffentlichen Funktionen des Betriebssystems. Die Programme nutzen die gleichen Schnittstellen, wie die integrierten Anwendungen. 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-Ar5 eng.: Look & Feel

12 10 Symbian chitektur kompiliert und wird dadurch wesentlich schneller ausgeführt. Die Entwickler 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 Verwendung mehrerer Threads für die Ausführung erreicht. Der Zugriff auf Betriebssystemfunktionen 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] 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 Laufzeitumgebung 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] Architektur Die Java Micro Edition, früher Java Plattform 2 Micro Edition, besteht aus horizontalen Konfigurationen, vertikalen Profilen und optionalen Paketen. Abbildung 2: Java ME in der Java Plattform [Sun08] 6

13 Symbian 11 Konfiguration: Basis-Klassen für IO-Streams, Basistypen, Threads, Ausnahmen, Auflistungen, grundlegende Netzwerkklassen Profile: GUI-Verwaltung, persistente Speicherung, Steuerung des Lebenszyklus, 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 Implementierungspflicht 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 Configuration (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 Funktionsumfang der JVM und die minimalen Anforderung an die Endgeräte. Der Prozessortyp, die minimale Kapazität des flüchtigen und permanenten Speicher und die Kommunikationsschnittstellen sind durch die Spezifikation festgelegt. Die Konfigurationen sind das Grundgerüst der Java Plattform für Geräte mit beschränkten Ressourcen. 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 Leistungsmerkmale und Teile der Klassenbibliothek voraussetzen. Sie enthalten zusätzliche 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 Systeme ohne Eingabegerät und dauerhafter Netzwerkanbindung ausgelegt. Sie wird in in High-End-PDAs, Set-top Boxen oder eingebetteten Systemen eingesetzt. 7

14 12 Symbian Die zweite Konfiguration der Java ME ist die Connected Limited Device Configuration. 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 Prozessor vor. Die CLDC ist damit für kleine mobile Endgeräte mit begrenzter Rechenleistung, geringer Speicherkapazität und drahtloser Kommunikationsschnittstelle mit niedriger Bandbreite geeignet. Sie findet Einsatz in Mobiltelefonen und Smartphones. Abbildung 3: CLDC Architektur [Brey06] Die CLDC bildet die Basis für das Mobile Information Device Profile (MIDP). Weitere 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 Anforderungen fest. Zusammen mit der CLDC bilden sie eine umfangreiche Programmierschnittstelle. Die Schwerpunkte der API liegen in der Benutzeroberfläche, Netzwerkfunktionen und die Speicherung persistenter Daten. Die zweiten Version enthält Verbesserung und neue Funktionen zur Wiedergabe von Medien, sichere Netzwerkverbindungen 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-

15 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 Zugriff auf statische Klassenvariablen und gemeinsame Ressourcen in der Suite. Die Anwendung wird in ein Java Archiv (JAR) verpackt, welches den kompilierten ByteCode, 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 benö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 Version 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 Ersteller der Anwendung über die erfolgreiche Installation oder Deinstallation benachrichtigen lassen. Diese Aufgaben übernimmt die Application Management Software (AMS), die auch den Lebenszyklus der Anwendung steuert und Teil der Laufzeitumgebung 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 Funktionen. 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 Spezifikation 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] Laufzeitumgebung Die Kilobyte Virtual Machine (KVM) ist die Laufzeitumgebung der CLDC. Sie unterstü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 Implementierung 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

16 14 Symbian da diese Bibliothek zu umfangreich ist. Die Funktionen der Introspektion10 sind nicht vorhanden, sodass die Serialisierung und Remote Method Invocation (RMI) nicht unterstützt wird. Die KVM verwendet nur nebenläufige Threads. Thread-Gruppen11 oder Daemon-Threads existieren nicht, da der Programmablauf mit dem letzten UserThread endet. Die Garbage Collection ist vorhanden, besitzt jedoch nicht die Fähigkeit 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 Erstellung 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] Speicherverwaltung Die Speicherbereinigung wird, wie die anderen Java Editionen, vom Garbage Collector 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 Programmierer eine Methode um die Speicherbereinigung auszulösen. Die Laufzeitumgebung entscheidet selbst, wann die Bereinigung durchgeführt wird. Der verwendete Algorithmus ist nicht vorgeschrieben und von der Implementierung der KVM abhängig. 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 zuverlässiges System ausschlaggebend. Tritt ein interner Fehler auf, erzeugt die Fehlerbehandlung eine Instanz einer Unterklasse der Error-Klasse. In der Konfiguration können bestimmte Fehler definiert werden, welche die Laufzeitumgebung beenden. Benötigt eine Anwendung mehr Speicher als zur Verfügung steht, wird der OutOfMemoryError ausgelöst. Er entsteht auf mobilen Geräten vor allem beim Laden 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

17 Symbian Grafische Benutzungsoberfläche Für die grafische Ausgabe und die Verarbeitung von Eingaben ist das Lowest Common Denominator User Interface (LCDUI) verantwortlich. Anwendungen müssen auf verschiedenen Geräten, mit unterschiedlichen Eingabemöglichkeiten und Bildschirmformaten lauffähig sein. Daher beinhaltet die Bibliothek den kleinsten gemeinsamen Nenner der Fähigkeiten, die aus den minimalen Anforderungen des MID-Profils 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 Eigenschaften 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 Grafikbibliothek kann durch Funktionen des Herstellers erweitert werden. Die Portabilität der Anwendung wird gewährleistet, wenn der plattformunabhängige Teil der API verwendet wird. Abbildung 4 zeigt die Aufteilung der grafischen Programmierschnittstelle 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 Softwareabbild 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 Bildschirmeigenschaften, des aktuell angezeigten Dialoges, sowie das Aufrufen der Vibrationsfunktion. Die Klassen der Benutzungsschnittstelle befinden sich im Paket javax.microedition.lcdui. Dialoge werden durch die abstrakte Klasse Displayable repräsentiert. In einem MIDlet wird jeweils nur ein Displayable-Objekt dargestellt. Dieses wird auf dem Bildschirm angezeigt, kann aber durch ein anderes MIDlet überlagert werden. Die Basisklasse 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

18 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 Benutzer die Bedienung zu erleichtern. Dies bedeutet im Umkehrschluss, das ein MIDlet keine visuellen Veränderungen der Bedienelemente vornehmen kann, da diese im Ermessen der LCDUI Implementierung liegen. Die High-Level-API ist verantwortlich für das Zeichnen und Aktualisieren der Komponenten und unterstützt einfache Interaktionen, 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 Ausgabefelder, Auswahlfelder oder Bilder wird über Eigenschaften festgelegt. Mit geringen Programmieraufwand 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 CommandListener 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 enthält Klassen zur Erstellung von Spielen auf mobilen Geräten. Sie bietet DoubleBuffering12, Animationen, Kollisionserkennung und weitere Funktionen. Diese und andere Erweiterungen nutzen die Low-Level-API um Zugriff auf den Bildschirm zu erhalten. [Hopk07] 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ärschlü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

19 Symbian 17 Abbildung 5: RMS Struktur [Ghos02] Die Datensätze können aus strukturierten Byte-Sequenzen bestehen. Über die Klassen DataInputStream und DataOutputStream können diese in das und aus dem ByteArray ü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 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 MIDProfil 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 Gerätes. Die Version der MMAPI, die unterstützten Aufzeichnungsquellen und Datenformate werden über die Methoden getsupportedprotocols und getsupportedcontenttypes des Manager abgerufen und sind von der Implementierung des Geräteherstellers abhängig. 13

20 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 Hauptkomponente 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 enthä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 sicherzustellen. Der aktuelle Status kann direkt abgerufen oder über einen vorher registrierten 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 Controllable. 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] 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 Protokollen und der geringen Flexibilität beim Austausch von Protokollimplementierungen. Die Klassen des GCF befinden sich im Paket javax.microedition.io. Das GCF ist ein erweiterbares, generisches Framework für Endgeräte mit beschränkten Ressourcen. Es ist mobil einsetzbar und ermöglicht die Kommunikation über 14 klassifiziert die Daten

21 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 DatagramConnection, 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 Schnittstelle ContentConnection bereitgestellt. Die StreamConnectionNotifier-Schnittstelle kann eine Anwendung über das Eintreffen eines asynchronen Datenstromes informieren. Das GCF bietet eine einheitliche Programmierschnittstelle für verschiedene Protokolle. Abbildung 7: Generic Connection Framework [Orti03] Ausgangspunkt jeder Kommunikation ist die Schnittstelle Connection. Sie repräsentiert die Verbindung, unabhängig vom Übertragungsprotokoll. Sie stellt die Funktionalitä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 Parameter als Schlüssel-Wert-Paare definiert. Der Aufbau folgt der Struktur scheme:target[;parameters]. Weitere Parameter legen die Art der Kommunikation und die Behandlung 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

22 20 Symbian werden die Verbindungen Socket, Server-Socket, Secure-Socket-Layer (SSL), UDPDatagramm, 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] Sicherheitsmechanismen Die Java Plattform ist für sicherheitskritische Umgebungen ausgelegt. Der Einsatz des Sicherheitsmodells der Java Standard Edition ist aufgrund der beschränkten Ressourcen 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 ausgefü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 Referenzen auf ungültige Speicherbereiche. Fehlerhafte Dateien werden zurückgewiesen. Die rechenintensive Überprüfung ist, wie in Abbildung 8 dargestellt, zweigeteilt. Die Präverifikation wird während der Erstellung des Archivs in der Entwicklungsumgebung durchgeführt und übernimmt den Großteil der Überprüfung. Die Laufzeitumgebung 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 Anwendungen werden in einer abgeschlossenen Umgebung, der Java Sandbox, ausgeführt und können nur vorher definierte Bibliotheken nutzen. Dadurch wird die Beeinträchtigung des Systems und der Ressourcen durch schadhafte Programme verhindert. Die Implementierung der CLDC unterbindet das Überschreiben von Klassen der Systempakete. Das Trusted Application Model des MID-Profils ergänzt den Schutz auf der dritten Ebene. Die Spezifikation definiert ein erweiterbares System von Berechtigun-

23 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 Edition 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] Native Programmierung Die Java Micro Edition unterstützt aus Sicherheitsgründen keinen Zugriff auf native Programme oder Hardwarefunktionen. Die Implementierung des Java Native Interface 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] Entwicklungsumgebung Für die Entwicklung existiert neben den herstellerspezifischen Software Development 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 optionaler Pakete, die Dokumentation der Programmierschnittstellen, Programme für die Erstellung 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 Funktionen wie Quellcodevervollständigung, intelligente Hinweise für die Fehlerkorrektur und Syntaxhervorhebung

24 22 Symbian Abbildung 9: NetBeans IDE mit Mobility Pack Besondere Funktionen bietet das Mobility Pack19 der NetBeans Entwicklungsumgebung 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 Zugriff auf Webservices und weitere Werkzeuge zum Erstellen und Testen der Anwendungen 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

25 Windows Mobile Windows Mobile Windows Mobile ist ein Betriebssystem für mobile Endgeräte und gehört zur Embedded Produktreihe von Microsoft. Es basiert auf dem Windows CE Betriebssystemkern und erweitert die Funktionalität um gerätespezifische Eigenschaften für Mobiltelefone 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 Versionen von Windows Mobile. Die Windows Mobile Classic Version enthält typische Anwendungen für Taschencomputer mit Stiftbedienung, wie z.b. Terminplaner, Adressverwaltung und Synchronisationssoftware. Die zweite Version ist Windows Mobile Standard und für Smartphones mit mobiltelefontypischer Tastatur und kleinem Bildschirm 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 Windows angelehnt. Über das Hauptelement (Start) können die installierten Programme gestartet werden. Bekannte Programme, wie der Internet Explorer, der Windows Media Player und Büroprogramme wurden auf die mobile Plattform übertragen. Das Windows Mobile SDK ermöglicht nur die Entwicklung von nativen Anwendungen. Daneben wird das.net Compact Framework unterstützt NET Compact Framework Das.NET Compact Framework ist ein direkter Ableger des Desktop- und Server-Frameworks. Es ermöglicht die einfache und effiziente Erstellung robuster Anwendungen 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 Framework. Die direkte Verwandtschaft zum Standard.NET Framework steigert die Produktivitä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 Dateiformat. Beide basieren auf dem ECMA20 Common Language Infrastructure (CLI) Standard21, einer Spezifikation für sprach- und plattformunabhängige Anwendungsentwicklung. 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 früher Microsoft Intermediate Language

26 24 Windows Mobile ausgeführt werden kann. Der Common Type System (CTS) Standard definiert wie Datentypen 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 ermö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ängig. 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 Common 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 Entwicklung von neuartigen Anwendungen auf verschiedenen mobilen Endgeräten. [Will04] 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 Maschinencode (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ührungsumgebung und dem Basisbetriebssystem. Im Gegensatz zum Desktop-Framework, kann das.net Compact Framework auf einer Vielzahl unterschiedlicher Betriebssysteme ausgeführt werden. Dies wird durch

27 Windows Mobile 25 die Abstraktionsschicht zwischen Betriebssystems und Laufzeitumgebung gewährleistet. Der PAL setzt die Programmierschnittstellen des Betriebssystems auf die Anforderungen 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 Anwendungen verantwortlich. Eine der Hauptaufgaben ist die Verwaltung des Speichers. Der integrierte Just-In-Time23 (JIT) Compiler übersetzt den CIL-Code in ausführbaren 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 Compact Framework, gerätespezifischen Bibliotheken und den Anwendungen. Die Klassenbibliothek besteht aus hierarchischen Namensräumen, in denen die Klassen 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 Anwendung 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 Spezifikation sind die Funktionen für die Verarbeitung von XML-Daten und Webserviceunterstützung in zusätzlichen Bibliotheken enthalten. Der interoperable Mechanismus 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] 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ändig und für Geräte mit eingeschränkten Ressourcen optimiert. Sie nutzt die Funktionalität der Anpassungsschicht um auf die Betriebssystemdienste zuzugreifen. Dieser Unterschied zur Desktop-Variante bietet eine höhere Flexibilität. Durch den Austausch der Schicht kann ein anderes Betriebssystem unterstützt werden. Anwendungen 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 ver23 Kompilierung während der Laufzeit

28 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-Compiler diesen in Maschinencode. Im dritten Schritt werden referenzierte Bibliotheken geladen und der benötigte Teil übersetzt. Nachdem der ClassLoader die AssemblyInformation geladen hat, wird der TypeChecker gestartet. Dieser führt vor der Übersetzung des CIL-Code eine Typprüfung durch. Die verwendeten Datentypen in Methoden 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 Typenebene durchgeführt. Es wird nur der benötigte Code übersetzt und für den späteren 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 unterstü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 benötigte Zeit wird durch die Wiederverwendung von zwischengespeicherten Maschinencode und der beschleunigten Ausführung unerheblich. Optimierungen des Quellcodes 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 ausgeführten werden, wird der gerade übersetzte Maschinencode sofort wieder aus dem Speicher entfernt. [Rubi03], [Wigl07], [Salm05], [Will04] 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 wertvollen Speicherplatz im RAM ein, da dieser gleichzeitig als Daten- und Arbeitsspeicher 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 Erreichen der Grenze entfernt. Dadurch können umfangreiche Programme mit minima-

29 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 Domä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 Laufzeitumgebung kann einzelne Blöcke einer Datei lesen. Dadurch kann er Teile des zu übersetzenden 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 markiert, 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 geschaffen. Da die Laufzeitumgebung die Position der noch verwendeten Objekte kennt, stellt die Bewegung im Speicher kein Problem dar. Die Garbage Collection wird entweder in einer oder in allen Anwendungsdomänen gleichzeitig durchgeführt. Während 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 Hintergrundanwendungen zu beenden. Die.NET Anwendung wird über das Deactivate-Ereignis benachrichtigt und kann ihre Anwendungsdaten sichern. [Salm05] Grafische Benutzungsoberfläche Für die grafische Oberfläche wurde ein Großteil der Steuerelement aus dem DesktopFramework übernommen. Diese sind in ihren Eigenschaften und Funktionen eingeschrä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-Steuerelementen und zum anderen das grafisches Zeichnen und Bitmapoperationen für 2DObjekte unterstützen. Die Klassen befinden sind in zwei verschiedenen Namensräumen. Die Grafikbibliothek nutzt die Fähigkeiten des darunter liegenden Windows CE Betriebssystem. Zum Bereich der High-Level-Elemente wird der Namensraum Microsoft.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 Systems, wie die Orientierung des Bildschirms. Der Namensraum System.Windows.Forms bietet eine Teilmenge der High-LevelSteuerelemente des Standard.NET Framework. Er enthält die wichtigsten Elemente,

30 28 Windows Mobile z.b. Button, TextBox, Label, RadioButton, ComboBox, ListBox, TreeView, MessageBox 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 System.Drawing. Auch dieser Namensraum beinhaltet eine Teilmenge der Bibliothek des Desktop-Framework. Die Klasse Graphics stellt Methoden zum Ausführen von Zeichen-, Füll- und Transformationsoperationen bereit. Die CreateGraphics-Methode der High-Level-Elemente erzeugt das Graphics-Objekt zum Zeichnen in dem Steuerelement. 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 Arbeitsspeicher gezeichnet. Prozessorintensive Funktionen und Eigenschaften sind im.net Compact Framework nicht vorhanden. Einige Elemente stehen aufgrund der Eingabemöglichkeiten nur auf der Pocket PC Plattform zur Verfügung. [Yang07] Persistente Datenspeicherung Das.NET Compact Framework bietet verschiedene Möglichkeiten an, um Daten persistent zu sichern. Seit Version 2.0 des Frameworks kann, über die Registry-Klasse aus dem Microsoft.Win32 Namensraum, auf die Registrierungsdatenbank des Windows Betriebssystem zugegriffen werden. Anwendungen können in dieser Einstellungen ablegen. Diese stehen beim nächsten Start der Anwendung zur Verfügung. Der Aufbau der Datenbank ist an den der anderen Windows Versionen angelehnt. Über statische Methoden können Schlüssel-Wert-Paare aus der Datenbank abgerufen oder abgelegt und Unterschlü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 DirectoryInfoKlassen 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 Zeichenketten 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 Sicherheitsausnahme. [Yang07] Die umfangreichste Funktionalität bietet die Technologie ADO.NET des.net Framework. 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 Arbeitsspeicher, erfolgen. Das Hauptelement der ADO.NET Architektur ist das DataSet. 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

31 Windows Mobile 29 Zeilen einer Tabelle und enthält die Einschränkungen. Im Gegensatz zu anderen Datenbanktechnologien ist in ADO.NET die Unterstützung für XML integriert. Das DataSet 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 ausfü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 DELETE und CREATE, DROP und ALTER..NET Anwendungen nutzen die Schnittstelle DataProvider aus dem System.Data.SqlServerCE 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] 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 Audiodateien 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/Invoke) Bibliothek ermöglicht. Diese erlaubt den Aufruf von native Funktionen. Im Artikel [Schw04] wird eine Beispielimplementierung zur Wiedergabe und Aufnahme von Audiodaten vorgestellt. 24

32 30 Windows Mobile Kommunikationsschnittstellen Das.NET Compact Framework stellt Bibliotheken für den Zugriff auf Netzwerkfunktionen im Namensraum System.Net bereit. Dieser bietet einen Teil der Funktionalitä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 Anwendungsschicht des OSI-Referenzmodells. Die statische Methode Create erzeugt unter Angabe eines Uniform Resource Identifier (URI) eine Instanz der Verbindung. Für die Protokolle http, https und file werden spezifische Klassen bereitgestellt, die Funktionen für Zugriff auf die speziellen Eigenschaften enthalten. Über die HttpWebRequestKlasse 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-Referenzmodells ermöglicht. Der System.Net.Sockets Namensraum bietet Klient- und Serverimplementierungen für die Transportprotokolle TCP und UDP an. Das.NET Compact Framework bietet darüber hinaus eine Bibliothek für die Infrarotschnittstelle 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] Sicherheitsmechanismen Grundsätzlich erlaubt die Sicherheitsrichtlinie des.net Compact Framework die uneingeschrä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 Sicherheitsanforderungen 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 Kopie 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 verankert. Basierend auf einem Beweis werden Zugriffsrechte durch definierte Regeln erteilt. 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

33 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 Sicherheitsrichtlinie des Gerätes verwendet. In dieser ist festgelegt, ob Anwendungen ohne Signatur 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] 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 Funktionen 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] 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, Dokumentation und Beispielcode. Weiterer Bestandteil sind die Abbilder der unterstützten Geräteplattformen. Diese werden vom Device Emulator ausgeführt. Auf diese Weise können die Anwendungen getestet werden. Da das SDK nur die Bibliotheken für Windows 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 Studio. 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üsselworthervorhebung und eine Onlinehilfe bereit. Der Formulardesigner unterstützt die Erstellung von Benutzeroberflächen und der Debugger bietet Funktionen zum Finden

34 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 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 Architektur 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 standardisierten Byte-Code in Maschinencode. Die Klassenbibliothek ist eine Untermenge 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, Programmiermodell und Dokumentation genutzt. Derzeit wird das.net Compact Framework nur von den Betriebssystemen Windows CE und Windows Mobile unterstützt.

35 Android Android Auf Initiative von Google wurde im Jahr 2007 die Open Handset Alliance26 gegründet, um offene Standards für mobile Geräte zu entwickeln. Zu den Mitgliedern zählen 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) TMobile und Telefonica und die Softwareunternehmen (Independent Software Vendor) E-Bay und Nuance. Das gemeinsames Ziel ist die Entwicklung einer mobilen Plattform 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 ermö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 Übernahme der Firma Android Inc. [Elgi05] Android-Plattform Android definiert den gesamten Aufbau der Plattform, vom Betriebssystem bis zu den Anwendungen, und ist deshalb mehr als eine Ausführungsumgebung und Anwendungsframework. Die Komponenten der Plattform stehen alle unter der OpenSource Lizenz. Dies bedeutet, dass für die Verwendung des Systems keine Lizenzkosten für den Endgerätehersteller anfallen. Aus diesem Grund wird ein Linux Kern als Betriebssystem eingesetzt und durch eine große Menge an austauschbaren OpenSource Bibliotheken vervollständigt. Vollendet wird die Plattform durch die Laufzeitumgebung 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ählen durch eine eher altertümliche Wahlscheibe ersetzt werden oder der integrierte -Klient angepasst werden, so dass er nur über die sichere Verbindung des Firmenservers 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. Neben 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 typischen Merkmale, wie die integrierte Digitalkamera, Speicherkartenerweiterungen und GPS-Empfänger, hinaus ist das System offen für die Integration weiterer Hard

36 34 Android warekomponenten, z.b. hochqualitative Soundausgabe, DVB-H- und 3D-Grafikchips. 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 Anwendungsbibliotheken. 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 Ausstattungsmerkmale 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 Android-Anwendungen bereitstellen, auf der Nutzer suchen und Entwickler ihre Anwendungen 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] 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 Systemdienste Sicherheit, Speicherverwaltung, Prozessverwaltung, Netzwerkunterstützung 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-Mikroprozessoren zur Verfügung, die in mobilen Geräten eingesetzt werden. Weitere

37 Android 35 Prozessorarchitekturen sind durch spezielle Anpassungen möglich. Die Veränderungen 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 Treibermodell. Er bildet damit eine einheitliche Abstraktionsschicht zwischen Hardware und Software. Neue Hardware kann über Treiber der Hersteller in das Linux Betriebssystem integriert werden. Der Android-Kernel enthält alle hardwarenahen Treiber (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-Plattform entsprechend steht der Quellcode28 der Öffentlichkeit zur Verfügung. Für die Entwicklung des Kernel bietet Google eine Versionsverwaltung an, über die die neusten Verbesserungen und Fehlerbehebungen abgerufen werden können. Die zweite Schicht der Android-Plattform teilt sich in die nativen C und C++ Bibliotheken und die Laufzeitumgebung. Die Bibliotheken sind die Grundlage für die Dienste und das Anwendungsframework. Sie bieten grundlegende Funktionen und fördern die Wiederverwendung von Komponenten mit der Leistungsfähigkeit der nativen Implementierung. Auch die Bibliotheken 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ührungsgeschwindigkeit 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 Bibliotheken. 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 Datenbankunterstützung. Zusätzlich beinhaltet die Schicht noch Bibliotheken der Hardwareabstraktionsschicht, die die Schnittstelle zu den Treibern definieren und das Android-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 AndroidPlattform. 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-Systeme. Auf weitere Details wird im folgendem Kapitel Laufzeitumgebung eingegangen. Ein weiterer Bestandteil der Laufzeitumgebung sind die in Java implementierten Basisbibliotheken (Core Libraries). Sie enthalten den größten Teil der Funktionalität der Java Programmiersprache. Die nächste Schicht bildet das umfangreiche Anwendungsframework der AndroidPlattform. Dieses stellt Klassen, Schnittstellen und Typen für die Entwicklung von Anwendungen und Softwarekomponenten zur Verfügung und ist in der Programmiersprache Java implementiert. Das Framework bietet zahlreiche vorgefertigte Komponenten 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

38 36 Android Foundation, und spezifischen Paketen des Android-Systems. Weitere Bibliotheken enthalten Funktionen zum Testen der Anwendung und bieten Zugriff auf die Hardware. 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 gleichberechtigte 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 Alternativen 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 Anwendungscode und die Ressourcen der Anwendung und wird in komprimierter Form abgespeichert. Dadurch können die Anwendungen einfach verteilt und auf den Android-Systemen installieren werden. Ein Task repräsentiert für den Nutzer eine Anwendung 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 globale 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 Zustand 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 Mechanismus 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. Registrieren sich mehrere Aktivitäten zu einer Aktion werden diese in einer Auswahlliste angezeigt. Da die Anwendungen gleichberechtigt sind, können vorinstallierten Anwen-

39 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 Anzeigen 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 System 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 Datenspeicherung 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:// reprä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] Laufzeitumgebung Hauptbestandteil der Laufzeitumgebung ist die von Dan Bornstein und anderen Google 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-