Inhaltsverzeichnis

1  Abstract  3

2  Einf uhrung  4

2.1  Android-Architektur  4

2.2  Programmiermodell  6

2.2.1  Activity  6

2.2.2  Service  7

2.2.3  Broadcast Intent Receiver  7

2.2.4  Content Provider  7

2.2.5  Ressourcen  7

3  Problemanalyse  8

3.1  JCP unabh angige Laufzeitumgebung  8

3.2  Dalvik-VM  9

4  Einsatz JCP anh angiger Bibliotheken  10

4.1  Voraussetzungen  11

4.1.1  Logging  13

4.2  Portierung  14

Referenzen   17

Internetadressen   17

1 Abstract

Das Internet und dessen Anwendungen werden zunehmend im mobilen Umfeld eingesetzt. Diese Entwicklung wird durch neue mobile Plattformen und immer leistungsf¨ ahigere Endger¨ ate verst¨ arkt. Mit Android hat Google im November 2007 ein eigenes Betriebssystem f¨ ur mobile Endger¨ ate auf den Markt gebracht. Android wird unter der Apache Lizenz 2 in großen Teilen quelloffen entwickelt. Das Betriebssystem besteht aus mehreren Schichten, wobei die unterste Schicht ein Linux Kernel ist.

Auf Anwendungsebene setzt Android eine virtuelle Maschine ein. Diese Dalvik genannte virtuelle Maschine wurde entwickelt, um den speziellen Anforderungen mobiler Endger¨ ate zu entsprechen. Als Sprache zur Applikationsentwicklung wird Java verwendet. Dabei unterstreicht Google jedoch ausdr¨ ucklich, dass es sich bei Android und Dalvik nicht um Java-Technologie handelt. Damit f¨ uhlt sich Google nicht an den Java Community Prozess gebunden, welcher durch die Erstellung von Java Specification Requests Java spezifiziert. Dies hat zur Folge, dass Implementierungen die auf Basis von Java Technologie entwickelt wurden nicht zwangsl¨ aufig auf Android einsetzbar sind.

Diese Arbeit analysiert die Folgen dieser Umst¨ ande und beschreibt einen Weg, unter dessen Anwendung eine Portierung von bestehenden Java-Implementierungen durchgef¨ uhrt werden kann. Dazu wird ein iterativer Prozess beschrieben, unter dessen Anwendung alle unbefriedigten Abh¨ angigkeiten einer Bibliothek gefunden werden k¨ onnen. Auf die M¨ oglichkeiten zur nachtr¨ aglichen Befriedigung dieser Abh¨ angigkeiten wird ebenso eingegangen. Die Anwendbarkeit des dargestellten Schemas wird anhand einer gr¨ oßeren Java-Bibliothek beschrieben. [Sac09]

3

2 Einf¨ uhrung

Google hat im November 2007 die Gr¨ undung der Open Handset Alliance bekannt gegeben. Diese Gruppe aus ¨ uber 30 Technologie Unternehmen ist beteiligt an der

Entwicklung eines Betriebssystems f¨ ur mobile Endger¨ ate. Android lautet der Name dieses Betriebssystems, das seit dem 22. Oktober 2008 unter der Apache-Lizenz 2 Open Source ist. Die Bestandteile von Android gehen ¨ uber das eigentliche Betriebssystem hinaus. Neben diesem beinhaltet Android eine in C/C++ implementierte Middleware, eine virtuelle Maschine (VM) und ein Software Development Kit (SDK) zur Entwicklung von Android Applikationen. Die Implementierung einer eigenen VM ist nicht nur aus technischer Sicht eine wichtige Entscheidung. Google umgeht damit die Lizenzbestimmungen der GPLv2, unter welche SUN sowohl die J2ME-VM als auch die Referenzimplementierung von J2ME gestellt hat. Die G¨ ultigkeit der GPLv2 wird im Falle von J2ME vererbt. Alle auf J2ME basierenden Programme sind somit automatisch den Bedingungen der GPLv2 unterstellt. Der Kern der Lizenz ist die Offenlegung des Quellcodes. Die Bef¨ urchtung ist, dass dies viele kommerzielle Software Entwickler abschrecken k¨ onnte. Doch durch die Implementierung einer eigenen VM und die Nutzung von Teilen des Apache Harmony Projekts, einer Apache-Implementierung der J2SE-Spezifikation, konnte die Anwendung der GPLv2 umgangen werden [4].

Im Oktober 2008 startete der Verkauf der ersten Mobiltelefone auf Basis von Android. Das Telefon, welches den Namen G1 tr¨ agt, wird von HTC hergestellt und von T-Mobile in den USA vertrieben. Die Vermarktung in Deutschland startete im Februar 2009. Trotz einer Verdreifachung der urspr¨ unglich vorgesehenen St¨ uckzahlen haben bereits die Vorbestellungen zu einem Ausverkauf des Ger¨ ats gef¨ uhrt.

2.1 Android-Architektur

Android basiert auf dem Linux Kernel 2.6, der eine robuste Hardwareabstraktion bietet. Da sich das Speichermanagement, die Prozesskontrolle und das Treibermodell seit Jahren als stabil erwiesen haben, bietet Linux eine gute Basis f¨ ur Android. Auf dieser Basis bauen zahlreiche native, und somit in Maschinencode kompilierte, Bibliotheken auf.

Viele zeitkritische Algorithmen sind in diesen Bibliotheken enthalten, da sie in h¨ oheren Programmiersprachen, wie dem interpretierten Java, nicht performant genug ausgef¨ uhrt werden k¨ onnten. Die nativen Bibliotheken ¨ ubernehmen unter Anderem folgende Aufgaben:

• Zeichnen von Fenstern

4

• Rendering von 2D (SGL) und 3D (OpenGL) Grafik

• Webseiten Rendering mittels der Webkit Browser Engine

• decodieren und encodieren von Streaming Formaten

• Datenspeicherung mittels SQLite

Auf gleicher Architekturebene befindet sich die Implementierung einer virtuellen Maschine die den Namen Dalivik tr¨ agt. Die Dalvik-VM ist eine f¨ ur mobile Hardware optimierte virtuelle Maschine. Diese speziell f¨ ur Android entwickelte VM f¨ uhrt .dex -Dateien aus, die durch einen zus¨ atzlichen Konvertierungsvorgang aus kompilierten Java-Klassen erzeugt werden. Durch die Konvertierung wird der Bytecode den besonderen Anforderungen der Architektur der Dalvik-VM angepasst. Zudem werden sowohl die Speicherbelegung als auch CPU-Nutzung f¨ ur die schw¨ achere Hardware eines mobilen Endger¨ ats optimiert. Dieser hohe Optimierungsgrad erlaubt es, jeden Prozess von einer eigenen Instanz der VM ausf¨ uhren zu lassen. Alle Anwendungen die auf Android ausgef¨ uhrt werden sind in Java programmiert. Um eine m¨ oglichst breite Funktionalit¨ at zu erm¨ oglichen ist in Android eine umfangreiche Kernbibliothek enthalten. Eine große Zahl von Klassen entspringen dem Apache Harmony Projekt, durch welches Kernmodule von J2SE in Android integriert werden konnten. Android enh¨ alt jedoch keine komplette Implementierung von J2SE. Viele Pakete der J2SE-Spezifikation sind nicht vorhanden. Dies hat den Grund, dass Android zum Teil Alternativen f¨ ur diese Packages bereitstellt. Dies gilt beispielsweise f¨ ur die Java Pakete zur Erzeugung und Darstellung von Benutzeroberfl¨ achen. Als Ersatz f¨ ur java.awt und javax.swing bietet Android eigene Klassen an, deren Implementierungen auf die Besonderheiten mobiler Endger¨ ate angepasst ist. Auf der obersten Abstraktionsebene der Android-Architektur verbindet das Android Application Framework die Funktionalit¨ aten aus den nativen Bibliotheken mit den in Java implementierten Bibliotheken und Programmen. Dieses Framework stellt die Umgebung bereit in denen Android-Applikationen ausgef¨ uhrt werden. Der Activity Manager, als ein wichtiger Teil des Android Application Frameworks, verfolgt den Navigationspfad, den ein Anwender bei der Benutzung von Android aufbaut. Somit ist der Activity Manager jederzeit in der Lage einen zur¨ uck -Sprung in die letzte Ansicht zu realisieren. Er stellt ¨ uberdies sicher, dass f¨ ur jede Applikation gen¨ ugend

Systemressourcen zur Verf¨ ugung gestellt werden k¨ onnen. Das Android Application Framework ist direkt mit dem Kontext einer jeden Android-Applikation verkn¨ upft. Dies erm¨ oglicht es Android, Dienste und Datenstrukturen prozess¨ ubergreifend zu teilen, anzubieten und anzufordern.

5