© pictureguy66, 123RF.com

Javascript, HTML 5 und jede Menge Linux- und Android-Erbschaften: Das ist Firefox OS, das Smartphone-Betriebssystem, mit dem Mozilla auf den Markt der günstigen Smartphones drängt. Das Linux-Magazin hat die ersten beiden Referenz-Entwicklergeräte Keon und Peak von Geeksphone getestet.

Offen, frei und modern – das will Mozilla mit dem Firefox OS sein. Die auch “Boot to Gecko” oder kurz B2G [1] genannte Open-Source-Alternative zu gängigen Smartphone-Betriebssystemen soll bekannte Technologien verwenden, um dem System eine möglichst schnelle und einfache Verbreitung zu ermöglichen. Gleichzeitig soll der Ressourcenverbrauch gering bleiben, damit Hersteller ihre Geräte mit möglichst günstiger Hardware ausstatten können.

Emerging Markets

Mozilla zielt hiermit ganz klar in Richtung der so genannten Emerging Markets, also der Schwellenländer, in denen Smartphones wegen ihres Preises noch eine recht geringe Verbreitung und billige Geräte somit gute Chancen haben. Mozilla legt es aber nicht darauf an, selbst einen Applikationen-Shop oder Bezahldienste anzubieten, sondern betont, dass Mobilfunkbetreiber oder andere Interessenten diese selbst aufbauen können. Die Foundation versteht sich nur als Entwickler und Anbieter der Software, nicht als Diensteanbieter.

Mit dieser klaren Trennung macht Mozilla bei Firefox OS praktisch alles anders als bei anderen derzeit verfügbaren Smartphone-Betriebssystemen. Die Frage bleibt, wie die Foundation die Entwicklung mittel- und langfristig finanzieren möchte, wenn sie weder mit dem System selbst noch mit den Diensten drum herum ein kommerzielles Interesse verfolgt.

Simulant

Seit gut einem halben Jahr gibt es den Firefox OS Simulator (Abbildung 1, [2]) als Plugin für den normalen Firefox-Browser. Der Simulator ist als Testumgebung durchaus auch für Entwickler spannend, die nicht gleich ein Telefon kaufen und Firefox OS darauf installieren möchten. Außerdem ist er für die Applikationsentwicklung nützlich. Bereits in seiner ersten Version zeigte er eine flüssig bedienbare grafische Oberfläche, die den etablierten Smartphone-Systemen lediglich in der Fülle der verfügbaren Applikationen nachstand.

Abbildung 1: Im Firefox OS Simulator, einem Browser-Addon, können Interessierte mit wenigen Mausklicks erste Gehversuche unternehmen.

Abbildung 2: Die beiden Firefox-OS-Geräte unterscheiden sich kaum von anderen modernen Smartphones der unteren Mittelklasse …

Allerdings läuft der Simulator auch auf einem leistungsfähigen PC. Die spannende Frage lautet daher, wie das Firefox OS sich auf echter Telefonhardware verhalten würde, die ja oft über eine wesentlich schwächere Hardware-Ausstattung verfügt. Dass dies kein Problem darstellt, sollen jetzt die beiden Geeksphone-Geräte [3] Keon und Peak (Abbildungen 2 und 3) beweisen.

Abbildung 3: … nur die Farbe (Weiß beim Peak, Orange beim Keon) und das Logo auf dem Rücken machen den Unterschied.

Architektur

Herzstück von Firefox OS ist – wenig verwunderlich – Mozillas Webengine Gecko. Alle Anwendungen, mit denen ein Benutzer unter Firefox OS interagiert, sind Webapplikationen und bestehen aus Javascript, CSS und HTML, welche die Gecko-Engine zum Leben erweckt (siehe Abbildung 4).

Abbildung 4: Komplex, aber überwiegend mit bekannten Komponenten – die Architektur von Firefox OS.

Die Anbindung der Engine an die Hardware realisiert eine neue Schicht namens Gonk. Die greift über recht bekannte Bibliotheken und Schnittstellen auf die Hardware zu. Für die Treiberanbindung an konkrete Hardware verfolgt Mozilla einen ähnlichen Ansatz wie Ubuntu mit seiner Touch-Distribution für Mobiltelefone und Tablets [4]: Es verwendet existierende Treiber und Bibliotheken, die bereits für Android-Versionen auf der entsprechenden Hardware zur Verfügung stehen. Ergo läuft auf der untersten Ebene ein Linux-Kernel.

Gonk, Gecko und Gaia

Oberhalb von Gonk unterstützen diverse Web-APIs das Runtime Environment Gecko beim Zugriff auf beispielsweise Sensoren, Kameras, Bluetooth oder NFC. Auf dem Application Layer läuft Gaia, das vielleicht noch am ehesten mit dem Launcher unter Android vergleichbar ist. Gaia stellt den Startbildschirm dar, zeigt Benachrichtigungen an (Abbildungen 5, 6, 7, 10 und 11) und ermöglicht es dem Benutzer, Applikationen zu starten und zu verwalten.

Abbildung 5: Die Einstellungsdialoge ähneln denen anderer Systeme.

Abbildung 6: Die Notifications erlauben den Schnellzugriff auf Daten.

Abbildung 7: Ein einfacher App-Store ist bereits enthalten.

Das Ausführen nativer Linux-Applikationen ist in der aktuellen Architektur nicht vorgesehen, was gerade für die Hersteller von Spielen oder Applikationen, die etwas mehr Rechenleistung benötigen, ein Problem darstellen könnte. Der Ansatz, HTML, CSS und Javascript für die Applikationsentwicklung einzusetzen, ist zudem auch nicht neu. Bereits Palms Web OS [5] basierte darauf, gestattete aber auch native Applikationen.

Das Entwickeln und Etablieren einer neuen Softwareplattform ist kompliziert, insbesondere ohne konkrete Hardware, auf der sie entwickelt und auch verwendet werden kann. Viele auf freier Software basierende Handy-Projekte für Linux und die darauf aufbauenden Mobilgeräte sind bereits an diesem Problem gescheitert oder fristen immer noch ein Nischendasein.

Mozilla hat dieses Problem erkannt und mit dem Partner Geeksphone aus Spanien gleich zwei Entwicklertelefone allgemein verfügbar gemacht. Die Geräte unterstreichen auch gleich den Anspruch Mozillas, Firefox OS auf vergleichsweise sparsamer Hardware gut und fließend zum Laufen zu bringen. Tabelle 1 zeigt die Spezifikationen der beiden Geräte.

Keon und Peak

Das kleinere, orangefarbene Keon ist mit einem 1-GHz-Singlecore-Qualcomm-Snapdragon und HVGA-TFT-Display (320 mal 480) ausgestattet, das große, weiße Peak glänzt mit einem doppelkernigen 1,2-GHz-Snapdragon, einem IPS-Display in qHD (540 mal 960) und einer zusätzlichen Frontkamera. Die preisbewusste Herstellung merkt man den Geräten zwar an, es sind keine Smartphones der Luxusklasse, doch für den Preis von nur 110 Euro für das Keon und 180 Euro für das Peak wird das auch kein Kunde erwarten. Die Verarbeitung ist gut, alle Teile passen, nichts klappert oder steht über.

Das Gehäuse des Peak besteht aus glattem weißen Kunststoff, das des Keon ist in dem für Firefox charakteristischen Orange gehalten, auch ist seine Oberfläche leicht aufgeraut, was den haptischen Eindruck gegenüber dem Peak deutlich verbessert.

Grundsätzlich sind die Geräte sehr ähnlich ausgestattet: Die wichtigsten Unterschiede zwischen Peak und Keon sind das geringer auflösende Display, die langsamere Singlecore-CPU und die fehlende Frontside-Kamera des Keon. Sein Akku ist auch etwas kleiner ausgefallen, doch die 220 mAh Unterschied gleicht der zweite Core des Peak vermutlich schnell wieder aus.

Arbeitsspeicher und Kernel

Nach dem Start stehen für den Userspace auf dem Keon 406 MByte und auf dem Peak 384 MByte RAM zur Verfügung. Dies liegt daran, dass die Geräte Teile des 512 MByte umfassenden Arbeitsspeichers für die restliche Hardware des Qualcomm-System-on-Chip (SoC) reservieren, zum Beispiel für den Open-GL-Grafikpuffer oder auch für das UMTS-/GSM-Modem. Als Linux-Kernel kommt auf dem Keon Version 3.0.8 zum Einsatz, das Peak verwendet den Kernel 3.0.21.

In der Praxis verhalten sich beide Geräte sehr ähnlich. Nach nur 21 Sekunden haben beide den Kaltstart hinter sich gebracht, es zeigt sich der Gaia-Startbildschirm. Die Bedienung ist auf beiden Smartphones sehr fließend und steht durchschnittlichen Android-Geräten in nichts nach. Lediglich der Umfang der einstellbaren Optionen entspricht noch nicht dem, was der Smartphone-User heutzutage erwartet.

Schnelle Updates

Doch Mozilla arbeitet auch hier fleißig weiter: Als die Telefone in der Magazin-Redaktion angeliefert wurden, gab es beispielsweise weder ein deutsches Tastaturlayout für die virtuelle Bildschirmtastatur noch eine deutsche Sprachlokalisierung. Die lieferte schließlich ein Update kurz vor Redaktionsschluss.

Der Funktionsumfang dieser ersten Version entspricht dem, was man heute von einem Smartphone erwarten kann. Eine Adressbuchapplikation mit Unterstützung für ein lokales Adressbuch sowie eine Importfunktion für Kontakte von der SIM-Karte und für Facebook-Kontakte sind vorhanden. Leider lassen sich keine weiteren Kontaktquellen einbinden.

Der Kalender kann einen lokalen oder einen Netzwerk-basierten Kalender von Google, Yahoo oder aus Caldav verwalten. Die Optionen für Kalendereinträge sind noch sehr eingeschränkt, beispielsweise unterstützt die Applikation keine Terminwiederholungen.

Minimale Software

Auch die restlichen vorinstallierten Anwendungen wie die Medienwiedergabe, Kamera und Galerie funktionieren eher rudimentär, erfüllen aber für den Anfang ihren Zweck. Allerdings ließen sich auf dem Keon keine Videos wiedergeben. Den Ton spielte das Handy zwar ab, aber das Bild blieb schwarz. Auch ein E-Mail-Client ist vorhanden, doch unterstützt er kein SSL für den Verbindungsaufbau zum Mailserver, weshalb der Einsatz nicht guten Gewissens zu empfehlen ist.

Als Quelle für weitere Applikationen bieten sich zwei Optionen an: Zunächst gibt es eine extern gepflegte Bookmark-Sammlung mit Dutzenden Links zu Webseiten mit Web-Apps, welche die Entwickler unter Firefox OS getestet haben. Sie legen Verknüpfungen auf dem Startbildschirm an, die wie Lesezeichen auf die eigentlichen Onlinedienste verweisen, ohne Onlineverbindung sind sie nicht verwendbar. Als zweite Quelle gibt es den Firefox OS Marketplace, der als Beispiel für eine mögliche Implementierung eines App-Shops gilt. Dort gibt es so genannte Packaged Applications, die all ihre Daten lokal auf dem Telefon installieren und somit, zumindest prinzipiell, auch ohne eine aktive Internetverbindung funktionieren. Zur Laufzeit ist es für den Benutzer allerdings fast nicht unterscheidbar, ob ein Icon nur ein Lesezeichen oder eine Packaged-App ist.

Früher Stand und nicht alles OSS

Auch an weiteren Stellen bemerkt man den frühen Stand der Entwicklung: Das deutlich höher auflösende Display des Peak sorgt beispielsweise in einigen Applikationen für Probleme, weil sie Schriften viel zu klein darstellen. Offenbar wertet Firefox OS die DPI nicht überall korrekt aus. Auch das Scrollverhalten wirkt manchmal seltsam: Der zu scrollende Inhalt wird schneller verschoben, als sich der Finger auf dem Touchscreen bewegt. Diese beiden Effekte sind nur auf dem Peak zu beobachten, nicht aber auf dem Keon.

Mozilla verspricht, dass Firefox OS auf offenen Standards und quelloffener Software basieren soll. Das ist auch für alle Schichten ab Gonk aufwärts richtig, doch darunter sieht es weniger offen aus. Die Basisquellen für das B2G-Buildsystem sind auf Github [6] verfügbar. Das darin enthaltene »config.sh«-Skript setzt die weiteren Repositories auf und lädt deren Inhalte herunter – über 13 GByte Sourcecode! Ein großer Teil dieser Quellen stammt aus Androids Open-Source-Projekt – B2G verwendet sie zum Aufbau des Basis-Linux-Systems, zu dem etwa die Libc oder die Shell gehören.

Innerhalb der ausgecheckten Quelltexte befindet sich auch ein Unterverzeichnis »vendor«, das im Falle des Peak knapp 20 MByte Binärdateien enthält, für die es scheinbar keinen Sourcecode gibt. Diese implementieren Hardware-nahe Funktionen, auf die Gonk aufsetzt und die von Qualcomm ursprünglich für Android entwickelt und angeboten wurden.

Daraus kann man Mozilla keinen Vorwurf machen, die Foundation will ja schließlich keine Hardwaretreiber entwickeln. Der Kniff, die existierenden Android-Treiber zu verwenden, ist in der Tat recht clever, doch dem Freie-Software-Enthusiasten wird dieser Umstand sicherlich etwas unangenehm aufstoßen.

Realistisch betrachtet sollte aber klar sein, dass ein modernes Smartphone mit völlig freier Software beim aktuellen Stand der Entwicklung praktisch nicht umzusetzen ist. Sobald etwa eine Hardwarebeschleunigung für die grafische Oberfläche oder eine Multimedia-Unterstützung ins Spiel kommen, hat freie Software meist schlechte Karten.

Ein anschließender Aufruf des »build.sh«-Skripts zieht zudem über ADB, die Android Debug Bridge, gut 250 MByte an Daten von einem angeschlossenen Keon- oder Peak-Telefon. Für das eigenhändige Kompilieren des Betriebssystems muss der Entwickler also eines dieser Telefone besitzen und die Android-Entwicklungswerkzeuge installiert haben, um per ADB die Daten zu holen. Immerhin kann er die Debug Bridge auch zur späteren Applikationsentwicklung verwenden.

Browser reloaded!

Auf der beschriebenen Hardware läuft ein einziges Programm, nämlich der Browser. Die Telefon-Apps, die der Benutzer als Anwendungen wahrnimmt, sind technisch betrachtet nur Webseiten, die ein Klick auf einen Link öffnet. Doch handelt es sich nicht um statische HTML-Seiten, sondern um Webanwendungen. Dank zahlreicher neuer Internetstandards verschwimmen die Unterschiede zu nativen Desktop-Programmen inzwischen noch stärker, als dies bei den Ajax-Anwendungen der ersten Generation der Fall war (Abbildung 8). Da sie auch offline funktioniert, ist die Client-seitige Javascript-Laufzeitumgebung besonders gefragt, doch der Einsatz Server-seitiger Programmierung ist ebenfalls möglich.

Abbildung 8: Zahlreiche neue Technologien aus dem HTML-5-Umfeld machen den Browser zu einer potenten Laufzeitumgebung für Phone-Apps.

Die HTML 5 zugerechneten Technologien bieten grafische und multimediale Features, die sich in HTML  4 nicht ohne Plugins umsetzen ließen: Freiform-Zeichnen in Echtzeit (Canvas), Animationen (CSS3, SVG), Sound ohne Plugins (»audio«-Tag), sogar Open-GL-basierte 3-D-Grafik (Web GL). Moderne Browser speichern auch lokal (Local Storage, Files-API) Datenmengen, die weit über die Größe eines Cookies hinausgehen.

Mit Indexed DB stellen sie sogar eine einfache NoSQL-Datenbank bereit. Cache-Manifests weisen den Browser an, Ressourcen aus dem Internet auch nach Beendigung der Onlineverbindung verfügbar zu halten. Außerdem setzen Websockets und Server-sent-Ereignisse endlich eine echte, bidirektionale Kommunikation zwischen Client und Server um. Web-Worker starten Hintergrund-Threads, die das GUI nicht blockieren.

Ungeachtet dessen, ob diese neuen APIs bereits weit genug verbreitet sind, um sie auf öffentlichen Websites zu benutzen: Für Apps in Firefox OS stehen sie auf jeden Fall zur Verfügung. Tabelle 2 listet die Mozilla-Dokumentationen für die genannten Technologien auf.

Harte Ware

Webanwendungen, die sich wie normale Android- oder I-OS-Apps verhalten sollen, brauchen geregelten Zugriff auf die Hardware des mobilen Geräts. Das Geolocation-API des W3C [7], mit dem ein Browser auf die aktuellen GPS-Koordinaten zugreift, ist ein Anfang, aber offensichtlich nicht genug: Die Phone-Apps benötigen Zugriff auf den Mobilfunk-Status, die Display-Beleuchtung oder den Batteriezustand.

Diesen Hardwarezugriff regelt Mozillas vorwiegend auf Firefox OS konzentriertes Web-API (Abbildung 9, [8]). Ein Manifest [9] fordert die Berechtigungen an, die der Anwender einer bestimmten Domain (Anwendung) gewähren oder verweigern kann [10].

Abbildung 9: Je nach Herkunft erhalten die Webanwendungen, teilweise erst nach Bestätigung durch den Benutzer, unterschiedliche Rechte für den Hardwarezugriff.

Manche Berechtigungen bleiben grundsätzlich lokal installierten Apps (Packaged-Apps) vorbehalten, einige sogar nur den privilegierten Apps aus Mozillas App-Store. Diesen Status erhalten sie erst nach einer Prüfung durch den Store-Betreiber. Firefox weist Packaged-Apps bei der Installation lokal eine zufällige Pseudo-Domain zu, die das Rechtemanagement des Browsers analog zu normalen Internetseiten handhabt.

Look & Feel

Auf der obersten Stufe stehen so genannte zertifizierte Apps, also Firefox-OS-Systemanwendungen. Sie allein erlangen kritische Berechtigungen wie das Wählen einer Telefonnummer. Auch bei ihnen handelt es sich um Webanwendungen, deren Rechte der Browser gemäß den Vorgaben des Web-API [8] verwaltet.

Trotz Einsatz fortschrittlicher HTML-5-Techniken stellt sich noch kein App-Feeling ein (Abbildung 10), solange die Programme in einem Browserfenster starten. Der Open-Web-Apps-Standard [11] gestattet das Ausblenden aller Browser-Elemente. Zugleich erscheint ein Start-Icon im Startmenü des Gaia-GUI.

Abbildung 10: Der Browser macht sich optisch rar: Web-Apps starten gewöhnlich im Fullscreen-Modus.

Bei Firefox OS landen die Starter-Icons in einem Homescreen, der sich optisch nicht von dem anderer Mobilsysteme (Abbildung 11) unterscheidet. Den Aufbau von Elementen wie dem Starter-Icon regelt das bereits erwähnte App-Manifest. Jede Webseite kann Apps über eine Javascript-Schnittstelle [12] mit Firefox OS verknüpfen.

Abbildung 11: Die Buttons im Homescreen von Firefox OS sind nur Links auf HTML-Seiten.

Nicht ganz lokal

In der Folge fühlt sich die Software zwar wie ein lokales Programm an, doch gerade das kann täuschen. Unter Umständen lädt der Browser weiterhin den gesamten Anwendungscode bei jedem Start von einem Server aus dem Internet. Bei den so installierten Apps muss es sich nämlich nicht zwangsläufig um Packaged-Apps handeln, die Firefox OS ins lokale Filesystem entpackt. Nur anhand des Starter-Icon kann der Anwender lokale Apps bislang nicht von Internetdiensten unterscheiden.

Auch bleibt die Browser-Runtime, in der die Anwendung läuft, ein Internetbrowser: Dieser öffnet Links auf HTML-Seiten ohne jeden Hinweis darauf, dass er gerade das lokale Filesystem verlässt. Ob sich Anwendern mit dieser Aufweichung der Grenzen zwischen Online- und Offline-Inhalten wohl fühlen, wird sich zeigen. Potenziell entstehen dabei neue Sicherheitsprobleme.

Webentwickler müssen nur wenig dazulernen, um eine App für Firefox OS zu entwickeln: Es kommen die gleichen Basistechniken zum Einsatz wie bei normalen Webanwendungen. Entwickler dürfen die Programme sowohl Server- als auch Client-seitig in Javascript umsetzen.

Die erste spezifische Herausforderung ist der kleine Bildschirm. Doch in diesem Punkt unterscheiden sich die Apps kaum von den lange etablierten Mobilversionen größerer Websites. Die einzige Voraussetzung für die Installation als App ist das Manifest [9], eine einfache Json-Datei. Natürlich werden die Anwender Client-seitig programmierte Apps bevorzugen, die dank Cachemanagement oder lokaler Installation auch offline nutzbar sind.

Javascript ist ausgereift

Das Handwerk der Client-seitigen Programmierung in Javascript hat längst einen gewissen Reifegrad erreicht: Javascript ist inzwischen so performant wie viele der klassischen Skriptsprachen. Die Browser liefern einen Debugger mit, die meisten IDEs ([13], [14]) unterstützen die Sprache gut. Es gibt auch eine reichhaltige Auswahl an Bibliotheken und Frameworks, die oft dem MVC-Paradigma folgen (Tabelle 3).

Licht und Schatten

So manche Animationseffekte, aber auch funktionale Features eines benutzerfreundlichen GUI lassen sich zwar in HTML 5 und CSS 3 leichter umsetzen als auf der Basis nativer grafischer Toolkits. Ein Vorteil von Firefox OS liegt aber darin, dass es mehr potenzielle Programmierer gibt, als bei Android oder I-OS: Praktisch jeder Webentwickler kann ohne größere Einstiegshürden loslegen. Dem stehen unbestreitbare Nachteile gegenüber: Javascript bleibt als Skriptsprache zwangsläufig langsamer als Java oder C++, was sich auch auf die Akkulebensdauer auswirkt.

Was die Sicherheit angeht haben Browser keinen guten Ruf. Javascript ist zwar besser, als viele C++- oder Java-Entwickler denken, dennoch haften ihm Mängel an, zum Beispiel die Beschränkung von Fließkommazahlen auf 64 Bit. Ob das Konzept, die Online-Offline-Grenze zugunsten einer konsistenten Bedienung zu verwischen, bei den Benutzern auf Gegenliebe stößt, muss sich auch erst zeigen. (mfe)