Wie funktioniert eigentlich Android?

Obwohl es schon unzählige Blogeinträge und Webseiten gibt, die das Android-Betriebssystem (Android Operating System oder kurz AOS) erklären, möchten wir unseren Lesern eine kleine Einführung ins AOS geben. Noch immer gewinnt Android an Popularität und bringt damit auch Neulinge in dieses Gebiet, die vielleicht gerne etwas genauer wissen möchten, wie das AOS aufgebaut ist und wie die einzelnen Komponenten interagieren.

Das Android OS – Ein Schichtkuchen

Grob gesagt kann man sich das AOS als eine Art Schichtkuchen vorstellen. Jede Schicht hat ihre eigenen Charakteristika und dient speziellen Zwecken. Diese Schichten sind jedoch nicht komplett voneinander getrennt, sondern fliessen oft in einander über und interagieren. Die unterste Schicht bildet der Linux-Kernel, der zwischen Hard- und Software vermittelt. Die zweite Schicht beinhaltet die Native Libraries (Bibliotheken) sowie die Android Runtime Umgebung, die im Wesentlichen aus den Kern-Libraries und der DalvikVM (Virtual Machine) besteht. In der dritten Schicht befindet sich die Application Framework, ein Programmiergerüst für eine bestimmte Klasse von Anwendungen, die Funktionen und Programmstrukturen zur Verfügung stellt, die wiederum für alle Anwendungen dieser Klasse von Bedeutung sind. Die vierte und letzte Schicht bilden schliesslich die Applikationen (Apps) selbst.

In den folgenden Abschnitten werden die einzelnen Elemente etwas genauer erklärt. Wir verzichten auf zu viel Information, denn es wird sehr schnell sehr komplex. Wir starten mit dem Linux-Kernel.

Basis-Schicht – Der Linux-Kernel

Android basiert auf Linux und dafür gibt es einige gute Gründe. Zunächst sei hier die Portabilität erwähnt, welche es ermöglicht, die Plattform relativ einfach auf verschiedenen Hardware-Umgebungen zu kompilieren. Das hat den Vorteil, dass man sich also nicht grossartig um die zugrunde liegende Hardware zu kümmern braucht.

Ein weiterer Vorteil bildet die Sicherheit. Linux wurde über Jahrzehnte in verschiedenen Umgebungen ausprobiert und getestet. Ein Sicherheitsaspekt ist beispielsweise, dass alle Android Apps als separate Linux-Prozesse laufen, die durch das Linux-System selbst ihre Berechtigungen erhalten. Zudem nutzt Android dabei einige Features des Linux-Systems wie das Speicher-Management, das Energiemanagement und das Netzwerk.

Der Linux-Kernel ist für die Speicher- und Prozessverwaltung zuständig und enthält auch die verschiedenen Hardware-Treiber für die Kamera, das Dispay, Wifi und andere. Der Kernel ist also Vermittler zwischen Hard- und Software.

Die 2. Schicht – Native Libraries und die DalvikVM

Die zweite Schicht bilden die Nativen, also die plattformspezifischen Libraries zusammen mit der Runtime Umgebung, welche die DalvikVM enthält und spezielle Kern-Libraries.

Native Libraries (plattformspezifische Libraries)

Native Libraries sind in C/C++ geschriebene Libraries, die oft von der Open Source-Community übernommen werden, um der App-Schicht die notwendigen Dienste (Services) zur Verfügung zu stellen, so z.B. Webkit, SQLite, OpenGL (eine 3D Grafik-Library) oder OpenSSL (Secure Socket Layer ).

DalvikVM

Die DalvikVM ist eine speziell für Android massgeschneiderte VM, welche speziell die beschränkte Akku- und Rechenleistung von mobilen Geräten berücksichtigt. VM werden dazu verwendet, Programme in einem architekturneutralen Format zugänglich zu machen, wo sie einfach übersetzt und kompiliert werden können. Allgemein gesprochen übersetzen VMs ein Set von Instruktionen, die beschreiben, wie eine Rechenoperation ausgeführt werden soll.

Die Grundkomponenten der DalvikVM sind ein Registerset, das über eine Anordnung ganzer Zahlen simuliert wird; ein Instruktionsset, das beschreibt, welche Operationen und welche Operanden unterstützt werden; als letzte Komponente eine Ausführeinheit, welche die Instruktionen vom Programm holt, diese dekodiert und dann ausführt.

Bei der DalvikVM wird der Java Code zwei Mal kompiliert, was zwar umständlich erscheint, den Code aber im Endeffekt effizienter macht. Die Quelldatei wird auch in Java geschrieben und mittels Java Kompilierer in Java Bytecode kompiliert. Dieser Java Bytecode wird dann ein zweites Mal kompiliert, diesmal mit dem Dalvik Kompilierer in Dalvik Bytecode. Erst dieser wird als .dex Datei (Dalvik executable) auf der DalvikVM ausgeführt. Obwohl die Android-Libraries den Standard-Libraries von Java sehr nahe kommen, wurden speziell die Java User Interface Libraries durch Android-spezifische Libraries ersetzt und durch weitere Features ergänzt. Kommen wir nun zur dritten Schicht unseres Kuchens, dem Application Framework.

Die dritte Schicht – Application Framework

Wie eingangs schon erwähnt, ist das Application Framework ein Programmiergerüst für eine bestimmte Klasse von Anwendungen, die Funktionen und Programmstrukturen zur Verfügung stellt, die wiederum für alle Anwendungen dieser Klasse von Bedeutung sind. Im Application Framework finden sich zahlreiche Java Libraries, die speziell für Android gebaut wurden. Ebenfalls hier befinden sich viele Services oder Managers (also Dienste), welche ein ganzes Ökosystem an Fähigkeiten für Apps verfügbar machen wie zum Beispiel den Standort, Sensoren, Wifi, Telefonie usw. Jetzt, da wir den Unterbau kennen, kommt endlich die letzte Schicht, die Schicht der eigentlichen Apps.

Die letzte Schicht – Die eigentlichen Apps

Eine App ist eigentlich eine Application Package (APK) Datei, die grob gesprochen drei Komponenten enthält: die Dalvik executable Datei (.dex; siehe weiter oben), welche den Code der App ausführt; die Ressourcen (alles, was nicht Code ist, also beispielsweise Bilder oder Video- und Audioclips) und die Native Libraries (siehe weiter oben).

Jede App läuft in einem eigenen Linux-Prozess. Jeder Prozess hat in Android seine eigene Instanz in der DalvikVM, die zeitgleich mit dem Prozess kreiert wird und beim Beenden des Prozesses wieder zerstört wird. Ein Hauptprozess, der „init“-Prozess, wird beim Aufstarten des Smartphones oder Tablets gestartet. Dieser Prozess lädt und initialisiert eine Instanz der DalvikVM. Wenn wir nun eine App starten, sendet diese eine Nachricht an diesen Prozess, der dann den Android Activity Manager Service kontaktiert, um die Java-Klasse dieser App zu laden (Näheres dazu in einem später erscheinenden Artikel).

Die Sicherheitsarchitektur des AOS ist so ausgelegt, dass eine App grundsätzlich über keinerlei Berechtigungen verfügt, die erlauben würde, Operationen auszuführen, die anderen Apps, dem System oder dem Benutzer schaden könnten. Dies beinhalten das Lesen oder Schreiben von privaten Benutzerdaten (wie die Kontakte oder e-Mails), das Lesen oder Schreiben von Dateien anderer Apps, Netzwerkzugang zu bekommen etc. Weil im AOS die Apps voneinander abgekapselt sind, müssen sie Ressourcen und Daten explizit miteinander teilen. Dies wird über das Erteilen von Berechtigungen ermöglicht, so die Apps über Zugriffe verfügen können, die nicht in ihrem eigenen Prozess zur Verfügung stehen.

Quellen: 

http://developer.android.com/guide/index.html;

http://en.wikipedia.org/wiki/Dalvik_(software);

http://de.wikipedia.org/wiki/Android_(Betriebssystem)