Android-Architektur: Wieviel Linux steckt in Googles OS?

Obwohl es sich bei Android um ein Linux-Betriebssystem handelt, laufen Standard-Linux-Anwendungen nicht auf Googles Mobilfunkbetriebssystem – auch nicht, wenn die Anwendungen für die ARM-Architektur kompiliert sind, denn mit einer Desktop-Distribution wie Ubuntu oder OpenSuse hat Android nur den Kernel gemeinsam. Und selbst der ist speziell auf die besondere Architektur von Android angepasst.

Streng genommen besteht Linux nur aus dem Linux-Kernel inklusive Treiber für Standard-Hardware, die wahlweise direkt in den Kernel hineingelinkt werden können oder als .ko-Datei nachladbar sind. Alle anderen Komponenten, darunter fallen auch Shells wie sh, ksh oder bash und Basiskommandos wie ls, cp, mv, chmod und vi gehören eigentlich nicht zu Linux.

In Desktop- und Server-Distributionen stammen die Basisbefehle meist aus dem GNU-Projekt, das ursprünglich ins Leben gerufen wurde, um ein freies unixoides Betriebssystem zu schaffen, das ohne proprietären Code auskommt.

1992 hatte das von Richard Stallman geleitete Projekt alle wesentlichen Komponenten eines rein textbasierten Betriebssystems ohne grafische Benutzeroberfläche fertiggestellt. Es fehlte lediglich ein Kernel. Bereits 1990 begann die Entwicklung am GNU-eigenen Kernel The Hurd, der aber bis heute keine ausreichende Stabilität für einen Produktiveinsatz bietet.

Am 17. September 1991 stellte Linus Torvalds seinen Kernel Linux 0.01 erstmals öffentlich auf einem FTP-Server zur Verfügung. Er hatte bereits einige GNU-Komponenten wie bash und gcc zu Linux portiert, um sein neues Betriebssystem überhaupt testen zu können.

Richard Stallman hielt es damals für eine gute Idee, für eine Übergangszeit den Linux-Kernel mit GNU zu kombinieren, um ein vollständiges Betriebssystem zu besitzen. So entstanden die ersten Distributionen. Allerdings war Stallman wenig begeistert davon, dass die Kombination des Linux-Kernels mit den GNU-Usermode-Komponenten üblicherweise nur als Linux bezeichnet wurde.

Der GNU/Linux-Namensstreit

Stallman hielt die Arbeit des GNU-Projekts für mindestens genauso bedeutend wie die von Linus Torvalds und besteht bis heute darauf, dass das Betriebssystem GNU/Linux heißen müsse. Bis auf Debian erwähnen alle bekannten Distributionen den Namen GNU jedoch nicht. Canonical verwendet zum Beispiel „Ubuntu 11.04 with Linux“.

Die Gegner des Namens GNU/Linux argumentieren, dass eine moderne Linux-Distributionen nicht nur GNU-Komponenten enthält. Wenn man alle berücksichtigen wolle, die einen signifikanten Beitrag zu einer Linux-Distributionen geliefert haben, dann käme ein Name wie „GNU/Linux/X.Org/kde/Mozilla/OpenSSH/Apache/Samba/kvm/TeX/Perl/Python/FreeCiv“ heraus.

Linux läuft auch ohne GNU

Wenig bekannt ist, dass es durchaus Linux-Implementierungen gibt, die völlig ohne GNU auskommen und bei denen die Bezeichnung GNU/Linux objektiv falsch ist. Das ist etwa bei vielen Embedded-Linux-Versionen für NAT-Router, digitale Satellitenreceiver und NAS-Speichersysteme der Fall.

Sie verwenden meist BusyBox. Wie bei den GNU-Core-Utilities handelt es sich um eine Sammlung der wichtigsten Unix-Befehle, die in einer einzigen ausführbaren Datei zusammengefasst sind. Optimiert wird nicht auf Geschwindigkeit, sondern auf geringen Verbrauch von Hauptspeicher und Plattenplatz. Ferner bieten die Busybox-Befehle nicht alle Kommandozeilenoptionen der GNU-Utilities.

Google verbietet GPL-Programme in Android

Auch Android kommt ganz ohne GNU aus. Es beinhaltet auf Retailgeräten nicht einmal BusyBox. Das hat allein schon lizenzrechtliche Gründe, denn das Android Open Source Project (AOSP) verbietet außer beim Linux-Kernel selbst die Verwendung von Code, der unter der GPL lizenziert ist. Auf einem „gerootetem“ Android-Handy ist BusyBox jedoch meist installiert, damit Profis direkt auf der Kommandozeile arbeiten können.

Die GPL schreibt vor, dass alle abgeleiteten Werke im Source-Code veröffentlicht werden müssen. Das hätte beispielsweise zur Folge, dass Google den Honeycomb-Code vollständig veröffentlichen müsste, was es derzeit nicht möchte, weil zu befürchten wäre, dass Hardwarehersteller Honeycomb-Tablets produzieren würden, obwohl der Code offensichtlich noch nicht ganz fertig ist. In das AOSP darf daher nur Code eingecheckt werden, der unter einer Lizenz wie BSD oder Apache steht, die zu nichts verpflichtet, außer der Namensnennung der ursprünglichen Autoren.

Man findet daher auf einem Android-Device nur eine rudimentäre Shell und einige wenige Unix-Befehle, die kaum Optionen bieten. Von der Single Unix Specification ist Android weit entfernt.

Eigene C-Library sorgt für Inkompatibilitäten

Android verwendet darüber hinaus eine eigene C-Library namens Bionic. Sie stammt von der BSD-Standard-C-Library ab und wurde von Google eigens für Linux und Android modifiziert. Sie ist kleiner und kompakter als die normalerweise für Linux genutzte GNU-C-Bibliothek glibc, aber nicht vollständig kompatibel.

Als Alternative hätte sich die uClibc angeboten, die BusyBox verwendet. Sie steht aber nicht unter der BSD-, sondern unter der GP-Lizenz. Die Verwendung der Bionic-Library führt dazu, dass es bereits bei einfachen Konsolenprogrammen für Standard-Linux zu Problemen bei der Portierung kommen kann, was aber meist leicht zu beheben ist.

Wer die Probleme allerdings vermeintlich dadurch beseitigt, dass er anstelle die Bionic-Library zu verwenden, einfach die uClibc in sein Binary hinein kompiliert, bekommt andere Schwierigkeiten. So funktioniert etwa die DNS-Auflösung nicht und uids und gids lassen sich nicht in Textform umwandeln, da Android und die Bionic-Library die Dateien /etc/passwd, /etc/group und /etc/resolv.conf nicht verwenden, die die uClibc zwingend erwartet.

Skia statt X11

Der nächste wesentliche Unterschied ist das grafische Subsystem. Wie bei anderen Linux-Betriebssystemen findet man ein Framebuffer-Device, das zur Ansteuerung des Grafikchips genutzt werden kann. Darauf wird aber nicht mit einem X11-System zugegriffen, sondern mit einem von Google entwickeltem Subsystem, das die Skia-Grafiklibrary implementiert.

Dabei handelt es sich um eine kompakte 2D-Grafiklibrary, die unter anderem auch bei Googles Browser Chrome zum Einsatz kommt und die Voraussetzung schafft, dass Chrome auf verschiedene Plattformen portiert werden kann. Bei Chrome werden Skia-Library-Calls in die jeweiligen Betriebssystem-APIs umgewandelt. Das Android-Grafiksystem zeichnet Skia-Befehle direkt auf dem Bildschirm des Devices. Wenn es die Grafikkarte unterstützt, werden die Skia-Befehle via OpenGL ES hardwarebeschleunigt dargestellt. Sämtliche Programme, die auf X11 basieren und einen X-Server wie X.Org benutzen, laufen unter Android nicht.

Damit unterscheidet sich Android etwa vom ebenfalls linuxbasierten MeeGo. Unter MeeGo ist es grundsätzlich möglich, X11-Programme mit nur geringem Aufwand zu portieren. Eventuell müssen darunterliegende Libraries wie Qt oder GTK ebenfalls portiert werden, wenn sie nicht oder nicht in der richtigen Version vorliegen. Das geht unter Android nicht so einfach. Grundsätzlich hat sich aber herausgestellt, dass ein vollständiger X-Server zumindest auf Smartphones zu viel Ressourcen verbraucht.

Kreative Zweckentfremdung der User IDs

Einer der wichtigsten Unterschiede zu einem Standard-Linux ist die Art und Weise, wie Android die eigentlich für die Benutzerverwaltung gedachten Identifier uid (User ID) und gid (Group ID) „zweckentfremdet“. Android ist nicht multiuserfähig in dem Sinne, dass sich ein Benutzer einloggt und seine eigene Umgebung mit eigenen Apps vorfindet oder dass Dateien eines anderen Benutzers geschützt sind.

Stattdessen weist Android jeder App eine eigene User-ID zu, unter der sie läuft. Jede App hat grundsätzlich nur Lese- und Schreibrechte auf das Unterverzeichnis /data/data/, etwa /data/data/com.android.browser. Eine andere App kann auf dieses Verzeichnis nicht zugreifen. Das dient der Sicherheit. So kann ein bösartiges Programm niemals auf das Verzeichnis einer Banking-App zugreifen, die möglicherweise Zugangsdaten zum Home-Banking gespeichert hat. Mit diesem Konzept unterscheidet sich Android deutlich von iOS, bei dem alle Apps unter der uid 501 (mobile) laufen.

Spezielle Rechte, etwa Zugriff auf die SD-Karte, werden über Gruppenmitgliedschaften einer App geregelt. Das hebelt das Sicherheitskonzept von Android teilweise wieder aus. Die SD-Karte ist in der Regel mit FAT32 ohne jede Security formatiert. Anwendungen können immer auf die gesamte SD-Karte zugreifen.

Besser wäre es gewesen, den Zugriff auf Verzeichnisse über lxc und cgroups zu regeln. So hätte man zum einen eine Multiuserfähigkeit später nachrüsten können, zum anderen ließe sich der Zugriff genauer und feiner einstellen. Ferner könnte man Programme, die glauben, sie müssen ständig im Hintergrund aktiv sein, beschränken, um den Akku zu schonen.

Allerdings ist lxc erst seit der Linux-Kernel-Version 2.6.29 offiziell verfügbar. Android 1.5 verwendete noch den Kernel 2.6.27. Daher war die Nutzung dieses Features bei der Entwicklung von Android nicht möglich.

Die Dalvik-VM

Bei der Bereitstellung einer Laufzeitumgebung für Apps geht Android ebenfalls eigene Wege. Jede App muss grundsätzlich in der Dalvik Virtual Machine laufen. Das ist eine VM, die weitgehend Sourcecode-kompatibel zu Java ist. Allerdings verwendet Google einen anderen Bytecode. Ein Java-Compiler kompiliert zunächst den auf dem Prinzip des Kellerautomaten basierenden Java-Bytecode, der später in den registerbasierten Bytecode von Dalvik umgewandelt wird.

Auch native Apps laufen zunächst in der Dalvik-VM, aus der sie später mittels API ausbrechen und nativen Code ausführen dürfen. Ohne Unterstützung von nativem Code ließen sich Anwendungen wie Firefox oder Flash nur schwer zu Android portieren.

Reiner Bytecode ohne native Teile ist auch auf Nicht-ARM-Plattformen lauffähig. Sollte Intel irgendwann eine x86-CPU herstellen, die vom Stromverbrauch her für Smartphones geeignet ist, stünden bereits zahlreiche Apps zur Verfügung, die unmodifiziert auf einem x86-Android-System liefen.

Generell ist jedoch die Situation für Entwickler, die Anwendungen für verschiedene Smartphone-Plattformen bereitstellen möchten, denkbar schlecht. Idealerweise entwickelt man für Android in Java, für iOS in Objective-C und für Windows Phone 7 in C#. Da nahezu keine Sourcecode-Kompatibilität besteht, müssen Multi-Plattform-Apps faktisch dreimal entwickelt und gepflegt werden.

Fazit

Ob Android ein eigenes Betriebssystem mit Linux-Kernel oder nur eine Variante des Linux-Betriebssystems ist, lässt sich nur schwer beantworten. In den 80er-Jahren hätte man einen Kernel mit einigen Kommandozeilenbefehlen sicherlich als vollständiges Betriebssystem bezeichnet.

Das ist heute anders. Zum Betriebssystem gehören ein grafisches Benutzerinterface und zahlreiche Subsysteme für Audio, Netzwerkanbindung und vieles mehr.

Android weicht ziemlich stark von einem Standard-Linux ab, wie man es von einer Desktop-Distribution kennt. Das geht beim Kernel los und zieht sich durch alle Ebenen. Es verwendet sogar eine eigene C-Bibliothek. So ist Android weiter entfernt von einem Desktop-Linux als andere Smartphone-Linux-Varianten wie MeeGo oder auch als iOS von MacOS.

Vergleicht man Android mit anderen Smartphone-Plattformen wie iOS oder Windows Phone 7, so muss man feststellen, dass diese sich so sehr unterscheiden, dass die Entwicklung von Multi-Plattform-Apps nahezu unmöglich ist. Das gilt insbesondere auch für iOS und Android, obwohl beide auf einem unixoiden Kernel basieren.

Das heißt nicht, dass Google bei der Entwicklung von Android keine gute Arbeit geleistet hat. Im Gegenteil, es zeigt, was mit einem modularen System möglich ist. Und der Erfolg von Android im Gegensatz zu MeeGo, das sich zu stark an einem Desktop-Linux orientiert hat, gibt dem Suchmaschinenriesen recht.

Der Windows-NT-Kernel ist im Gegensatz dazu so weit mit seinen Usermode-Komponenten verwoben, dass es Microsoft nicht möglich ist, ein schlankes Betriebssystem für Smartphones auf Basis des NT-Kernels zu bauen. Es musste für Windows Phone 7 ein komplett anderes OS implementieren, das keine Sicherheitsfeatures auf Kernelebene bietet. Daher kann Microsoft keinen nativen API-Zugriff erlauben.