Android als JCP-unabhängige Laufzeitumgebung für JCP-abhängige Implementierungen

Inhaltsverzeichnis

1 Abstract

2 Einführung
2.1 Android-Architektur
2.2 Programmiermodell
2.2.1 Activity
2.2.2 Service
2.2.3 Broadcast Intent Receiver
2.2.4 Content Provider
2.2.5 Ressourcen

3 Problemanalyse
3.1 JCP unabhängige Laufzeitumgebung
3.2 Dalvik-VM

4 Einsatz JCP anhängiger Bibliotheken
4.1 Voraussetzungen
4.1.1 Logging
4.2 Portierung

Referenzen

Internetadressen

1 Abstract

Das Internet und dessen Anwendungen werden zunehmend im mobilen Umfeld ein­gesetzt. Diese Entwicklung wird durch neue mobile Plattformen und immer leis­tungsfähigere Endgerate verstärkt. Mit Android hat Google im November 2007 ein eigenes Betriebssystem fär mobile Endgerate auf den Markt gebracht. Android wird unter der Apache Lizenz 2 in großen Teilen quelloffen entwickelt. Das Betriebssys­tem besteht aus mehreren Schichten, wobei die unterste Schicht ein Linux Kernel ist.

Auf Anwendungsebene setzt Android eine virtuelle Maschine ein. Diese Dalvik ge­nannte virtuelle Maschine wurde entwickelt, um den speziellen Anforderungen mo­biler Endgerate zu entsprechen. Als Sprache zur Applikationsentwicklung wird Java verwendet. Dabei unterstreicht Google jedoch ausdräcklich, dass es sich bei Android und Dalvik nicht um Java-Technologie handelt. Damit fählt sich Google nicht an den Java Community Prozess gebunden, welcher durch die Erstellung von Java Spe­cification Requests Java spezifiziert. Dies hat zur Folge, dass Implementierungen die auf Basis von Java Technologie entwickelt wurden nicht zwangslaäufig auf Android einsetzbar sind.

Diese Arbeit analysiert die Folgen dieser Umstande und beschreibt einen Weg, unter dessen Anwendung eine Portierung von bestehenden Java-Implementierungen durch­gefährt werden kann. Dazu wird ein iterativer Prozess beschrieben, unter dessen Anwendung alle unbefriedigten Abhängigkeiten einer Bibliothek gefunden werden koännen. Auf die Moäglichkeiten zur nachtraäglichen Befriedigung dieser Abhäangigkeiten wird ebenso eingegangen. Die Anwendbarkeit des dargestellten Schemas wird anhand einer größeren Java-Bibliothek beschrieben. [Sac09]

2 Einführung

Google hat im November 2007 die Gründung der Open Handset Alliance bekannt gegeben. Diese Gruppe aus über 30 Technologie Unternehmen ist beteiligt an der Entwicklung eines Betriebssystems für mobile Endgerüte. 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 über das eigentliche Betriebs­system 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ültigkeit der GPLv2 wird im Falle von J2ME vererbt. Alle auf J2ME basierenden Program­me sind somit automatisch den Bedingungen der GPLv2 unterstellt. Der Kern der Lizenz ist die Offenlegung des Quellcodes. Die Befürchtung ist, dass dies viele kom­merzielle 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 An­droid. Das Telefon, welches den Namen G1 tragt, wird von HTC hergestellt und von T-Mobile in den USA vertrieben. Die Vermarktung in Deutschland startete im Fe­bruar 2009. Trotz einer Verdreifachung der ursprünglich vorgesehenen Stuckzahlen haben bereits die Vorbestellungen zu einem Ausverkauf des Geräts geführt.

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 fuür 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 hoüheren Programmiersprachen, wie dem interpretierten Java, nicht performant ge­nug ausgeführt werden konnten. Die nativen Bibliotheken ubernehmen unter Ande­rem folgende Aufgaben:

- Zeichnen von Fenstern
- 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 Ma­schine die den Namen Dalivik tragt. Die Dalvik-VM ist eine für mobile Hardware optimierte virtuelle Maschine. Diese speziell für Android entwickelte VM fuhrt .dex -Dateien aus, die durch einen zusützlichen Konvertierungsvorgang aus kompilierten Java-Klassen erzeugt werden. Durch die Konvertierung wird der Bytecode den be­sonderen Anforderungen der Architektur der Dalvik-VM angepasst. Zudem werden sowohl die Speicherbelegung als auch CPU-Nutzung fur die schwüchere Hardware eines mobilen Endgerüts optimiert. Dieser hohe Optimierungsgrad erlaubt es, jeden Prozess von einer eigenen Instanz der VM ausfuühren zu lassen.

Alle Anwendungen die auf Android ausgefuhrt werden sind in Java programmiert. Um eine müglichst breite Funktionalität zu ermöglichen ist in Android eine umfang­reiche Kernbibliothek enthalten. Eine große Zahl von Klassen entspringen dem Apa­che Harmony Projekt, durch welches Kernmodule von J2SE in Android integriert werden konnten. Android enhült jedoch keine komplette Implementierung von J2SE. Viele Pakete der J2SE-Spezifikation sind nicht vorhanden. Dies hat den Grund, dass Android zum Teil Alternativen fur diese Packages bereitstellt. Dies gilt beispielswei­se fur die Java Pakete zur Erzeugung und Darstellung von Benutzeroberflachen. Als Ersatz für java.awt und javax.swing bietet Android eigene Klassen an, deren Implementierungen auf die Besonderheiten mobiler Endgerate 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 ausgefuührt 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ück-Sprung in die letzte Ansicht zu realisieren. Er stellt uüberdies sicher, dass fuür jede Applikation genuügend Systemressourcen zur Verfuügung gestellt werden küonnen. Das Android Application Framework ist direkt mit dem Kontext einer jeden Android-Applikation verknupft. Dies ermüglicht es Android, Dienste und Datenstrukturen prozessübergreifend zu teilen, anzubieten und anzufordern.

2.2 Programmiermodell

Das Android Application Framework verwendet eine Reihe von Klassen und Schnitt­stellen, die dem Entwickler zur Verfügung gestellt werden. Auf deren Basis können Applikationen entwickelt werden. Durch die Verwendung von Basisklassen besteht, innerhalb einer Applikation, jederzeit die Möglichkeit Dienste des Frameworks zu verwenden. Dadurch, dass der Applikations-Entwickler von den zur Verfuügung ge­stellten Klassen ableitet und wenn nötig bestimmte Teile überschreibt, konnen Ap­plikationen innerhalb des Android Appliation Frameworks einheitlich verwaltet wer­den. Für die Entwicklung von Applikationen stellt Android Application Framework folgende Komponenten in Form von Klassen bereit:

- Activities
- Services
- Broadcast Intent Receiver
- Content Provider

Um die Bestandteile einer Applikation dem Application Framework bekannt zu ma­chen, benötigt jede Applikation eine Datei mit dem Namen AndroidManifest.xml. In dieser XML-Datei werden außerdem Angaben zu Anforderungen und Fühigkeiten der Applikation deklariert. Events werden innerhalb von Android in Form von Intents ausgedruckt. Ein Intent ist eine Klasse, uber deren Datenstruktur ver­mittelt wird, welche abstrakte Aktion mit welchen Daten ausgeführt werden soll. Intents können von Activity- und Broadcast Intent Receiver Klassen behandelt wer­den. Uber Intent-Filter wird innerhalb der AndroidManifest.xml angegeben, welche Intents eine Activity oder ein Broadcast Intent Receiver verarbeiten kann.

2.2.1 Activity

Die am hüufigsten verwendete Klasse zur Implementierung von Anwendungen ist die Activity-Klasse. Sie ist in der Lage eine Benutzeroberflache darzustellen und kann Geschüftslogik enthalten. Activities beinhalten die darstellbaren Elemente einer ein­zelnen Seite der Anwendung. Darstellbare Elemente werden in Android als Views bezeichnet. Dazu zühlen eine Vielzahl von Interaktionselementen. Die Bandbreite reicht von sehr einfachen Views, wie Checkboxen, bis hin zu komplexen Elementen, wie WebViews, die komplette Webseiten darstellen konnen.

[...]