Foxy Phones

Mozilla Firefox OS wants to be open, free, and modern. Also known as "Boot to Gecko" or B2G for short [1], this open source alternative to major smartphone operating systems uses known technologies to enable fast and easy distribution. At the same time, it aims to keep resource consumption low to help manufacturers equip their devices with cheaper hardware.

Emerging Markets

Mozilla is clearly aiming in the direction of the emerging markets – that is, threshold countries where smartphones are still rare and low prices offer a big advantage in the marketplace. Mozilla is not interested in offering an app store or payment services itself but points to the fact that mobile network operators or other stakeholders can build these services themselves.

The Mozilla Foundation sees itself as a developer and supplier of software, not a service provider. This opportunity for more control over the services that are provided with the phone creates a revenue model for the phone vendor that isn't available through Android or iOS.

With this clear separation, Mozilla Firefox OS looks ready to offer a product that is distinctly different from the other smartphone operating systems currently on the market. The question remains as to how the Foundation will finance development in the mid- to long term, if it is not earning on the system itself or on the services.

Simulator

The Firefox OS simulator [2] (Figure 1) has been available as a plugin for the normal Firefox browser for more than six months. As a testbed, the simulator is quite exciting for developers who don't want buy a smartphone and install the Firefox OS on it, and it is also useful for application development. The first version revealed a fast and usable graphical interface that the established smartphone systems rivaled only in terms of the plethora of applications available.

Figure 1: In the Firefox OS simulator, a browser add-on, interested developers can take their first steps with a few mouse clicks.

Considering the simulator runs on a powerful PC, an interesting question presents itself as to how the Firefox OS and any applications developed on the simulator will behave on real phone hardware, which often has a much weaker hardware basis. However, this turns out not to be a problem, as the two Geeksphone devices [3] Keon and Peak (Figures 2 and 3) prove.

Figure 2: The two Firefox OS devices do not differ from other mid-priced, modern smartphones …

Figure 3: … only the color (white for the Peak, orange for the Keon) and the logo on the back mark the difference.

Architecture

The heart of Firefox OS is – not surprisingly – Mozilla's web engine Gecko. All applications with which a user interacts on Firefox OS are web applications built with JavaScript, CSS, and HTML, which the Gecko engine then brings to life (Figure 4).

Figure 4: The architecture of Firefox OS is complex, but most of the components are known.

The engine-to-hardware connection is implemented by a new layer called Gonk. It uses quite well known libraries and interfaces to access the hardware. For driver access to specific hardware, Mozilla has adopted a similar approach to Ubuntu with its Touch distribution for cellphones and tablets [4]: It uses existing drivers and libraries that are already available for Android versions on the corresponding hardware. Thus, a Linux kernel runs at the lowest level.

Gonk, Gecko, and Gaia

On top of Gonk, various web APIs help the Gecko Runtime Environment access, for example, sensors, cameras, Bluetooth, or NFC. Gaia runs in the Application Layer; you can imagine this as something comparable to the Launcher in Android. Gaia displays the start screen, shows notifications (Figures 5--7, 10, 11), and lets the user start and manage applications.

Figure 5: The Settings dialogs resemble those of other systems.

Figure 6: Notifications allow quick access to data.

Figure 7: A simple App Store is already included.

Running native Linux applications is not intended with the current architecture, which could be a problem in particular for game or app vendors who need more computing power. The use of HTML, CSS, and JavaScript for application development is nothing new. Palm's WebOS [5] was based on this, but it also allowed native applications.

Developing and establishing a new software platform is complicated, especially without specific hardware on which it can be developed and used. Many free-software-based cellphone projects for Linux and the mobile devices that relied on them have failed to tackle this problem previously or are still eking out a niche existence.

Mozilla has recognized this problem and made two developer phones generally available in cooperation with Spain's Geeksphone. The devices also underline Mozilla's aim to make sure Firefox OS runs well and smoothly on comparatively cheap hardware. Table 1 shows the specifications of the two devices.

Keon and Peak

The smaller, orange Keon is equipped with a 1GHz single-core Qualcomm Snapdragon and an HVGA TFT display (320x480). The larger, white Peak impresses with a dual-core 1.2GHz Snapdragon, an IPS qHD display (540x960), and an additional front camera. These are definitely not luxury smartphones, which is exactly what a customer would expect for a price of EUR 110 for the Keon and EUR 180 for the Peak. However, the build quality is good, all the pieces fit, and nothing rattles or protrudes.

The housing of the Peak is made of smooth, white plastic, whereas the Keon uses distinctive Firefox orange; its surface is also slightly roughened, vastly improving the tactile experience compared with the Peak.

The units are equipped very similarly: The main differences between Peak and Keon are the low-resolution display, the slower single-core CPU, and the lack of a front-facing camera in the Keon. The Keon's battery is also somewhat smaller, but the 220mAh difference will probably be consumed by the Peak's second core.

Memory and Kernel

After starting, 406MB of user space is available on the Keon, and 384MB of RAM on the Peak. The reason for the apparently short capacity is that the devices reserve some of the 512MB memory for the rest of the hardware of the Qualcomm system-on-a-chip (SoC) – for example, the OpenGL graphics buffer or the UMTS/GSM modem. The Linux kernel used on the Keon is version 3.0.8, whereas the Peak uses kernel 3.0.21.

In practice, the devices behave very similarly. After only 21 seconds, both have completed their cold start and display the Gaia home screen. Operation is very smooth on both phones and compares well with an average Android device; however, the extent of the configurable options is not what smartphone users expect today.

Fast Updates

Mozilla is working hard on the options issue, too. When the phones were delivered to our editorial office in Germany, for example, there was neither a German keyboard layout for the virtual on-screen keyboard nor German language localization. This arrived shortly before the deadline in the form of an update.

The functionality of this first version is roughly to what you would expect from a smartphone today: an address book application with support for a local address book and an import function for importing contacts from the SIM card and Facebook contacts. Unfortunately, no other contact sources can be integrated.

The calendar app can manage a local or network-based calendar by Google, Yahoo, or CalDAV. The options for calendar entries are still very limited; for example, the application does not support regular dates.

Minimal Software

The remaining pre-installed applications, such as the media player, camera, and gallery, are fairly rudimentary but fine for their initial purpose. However, the Keon did not play any movies. The phone played back the sound, but the screen stayed black. An email client is also available, but it does not support SSL for connecting to a mail server; its use is thus not recommended for security reasons.

As a source for other applications, you have two options: First, an externally maintained bookmark collection has dozens of links to websites with web apps that developers have tested on Firefox OS. You can create shortcuts on the home screen, which – like bookmarks – point to the actual online services; they are not usable without an online connection. A second source is the Firefox OS Marketplace, which is considered an example of a possible implementation of an app store. Here, you can pick up packaged applications that install all of their data locally on the phone and thus work, at least in principle, without an active Internet connection. It is difficult for users to tell at run time whether an icon is just a bookmark or a packaged app.

Early Bird – Not All OSS

You will notice the early stage of development in other areas as well, for example, the Peak's higher resolution screen causes problems in some applications because the fonts are too small. Apparently Firefox OS does not evaluate the DPI correctly in some places. Also, the scrolling behavior sometimes feels strange, in that the scrolling content moves faster than your finger moves on the screen. These two effects were only observed with the Peak, not with the Keon.

Mozilla promises that Firefox OS will be based on open standards and open source software. That is true for all layers from Gonk upward, but lower down, things look less open. The basic sources for the B2G build system are available on GitHub [6]. The config.sh script pulls in the other repositories and downloads the content – more than 13GB of source code. Many of these sources come from Android's open source project, and B2G uses them to build the basic Linux system, to which libc or the shell belong, for example.

Within the source code, you will also find a vendor subdirectory that contains about 20MB of binary files (in the case of the Peak), for which there seems to be no source code. They implement hardware-related functions, on which Gonk builds, and were originally developed and offered for Android by Qualcomm.

You can't blame Mozilla for this; the Foundation does not really want to develop hardware drivers. The trick of using the existing Android drivers is quite clever, but if you're a free software enthusiast, it will tend to leave a bad taste in your mouth.

Realistically, however, it should be clear that implementing a modern smartphone with completely free software is practically impossible given the current state of development. Whenever a hardware accelerator for the graphical user interface or multimedia support enters the game, free software usually has a tough time.

A subsequent call to the build.sh script also taps the Android Debug Bridge (ADB) to download more than 250MB of data to a connected Keon or Peak phone. To compile the operating system manually, the developer must therefore own one of these phones and have the Android Development Tools in place to retrieve the data via ADB. At least, however, you can use the Debug Bridge for your future application development.

Browser Reloaded

A single program runs on the hardware described here, and that is the browser. The phone apps the user perceives as applications are technically sites that you open by clicking on a link. However, these are not static HTML pages but web applications. Thanks to many new Internet standards, the differences between native desktop programs are even more blurred now than was the case with the first generation of Ajax applications (Figure 8). Because it also works offline, the client-side JavaScript run-time environment is particularly in demand, but you can also use server-side programming.

Figure 8: Many new technologies from the HTML5 environment make the browser a powerful run-time environment for phone apps.

The technologies attributed to HTML5 provide graphical and multimedia features that were impossible to implement without plugins in HTML4: Free-form drawing in real time (Canvas), animations (CSS3, SVG), sound without plugins ("audio" tag), and even OpenGL-based 3D graphics (WebGL). Modern browsers also store data sets locally (local storage, Files API) that far exceed the size of a cookie.

With IndexedDB, they can even provide a simple NoSQL database. Cache manifests instruct the browser to keep resources from the Internet even after terminating the online connection. Additionally, WebSockets and server-sent events finally implement true, two-way communication between client and server. Web workers launch background threads that do not block the GUI.

Regardless of whether these new APIs are mature enough to use on public websites, they are definitely available for apps in Firefox OS.

Table 2 lists the Mozilla documentation for the aforementioned technologies.

Hardware

Web applications that you expect to behave like normal Android or iOS apps need regular access to the hardware of the mobile device. The W3C Geolocation API [7] that lets a browser access the current GPS coordinates is a start, but obviously not enough: The phone apps need access to the cellular network status, display lighting, and battery status.

Hardware access is mainly controlled by Mozilla's Firefox OS focused Web API (Figure 9) [8]. A manifest [9] requests the permissions that the user can grant or deny a particular domain (application) [10].

Figure 9: Depending on their origin, some web applications are only granted various rights to access the hardware after the user confirms.

Some rights are always reserved for locally installed apps (packaged apps), and some even only for privileged apps from the Mozilla App Store. They receive this status after a review by the store operator. Firefox assigns packaged apps to a pseudo-random domain locally during installation; this domain handles the rights management of the browser as for normal web pages.

Look and Feel

Certified apps (i.e., Firefox OS system applications) reside at the top level. They are the only apps given critical authorizations, such as the ability to dial a phone number. Again, these are web applications whose rights the browser manages in line with the guidelines of the Web API [8].

Despite the use of advanced HTML5 techniques, they do not feel like apps (Figure 10) while the programs run in a browser window. The Open Web Apps standard [11] lets you hide all of the browser elements. At the same time, a start icon appears in the Start menu of the Gaia GUI.

Figure 10: The browser goes into hiding: Web apps usually start in full-screen mode.

In Firefox OS, the starter icons end up on a home screen that looks no different from that of other mobile systems (Figure 11). The aforementioned app manifest governs the building of elements like the starter icon. Each web page can link apps with Firefox OS via a JavaScript interface [12].

Figure 11: The buttons on the home screen of Firefox OS are just links to HTML pages.

Not Quite Local

As a result, the software feels like a local program, but appearances can be deceptive. Under certain circumstances, the browser continues to load the entire application code every time you start a server from the Internet. Apps installed in this way are not necessarily packaged apps that Firefox OS has unpacked on the local filesystem. Purely on the basis of the starter icon, the user cannot currently distinguish local apps from Internet services.

The browser run time in which the application runs remains an Internet browser: It opens links to HTML pages without any notification that it is leaving the local filesystem. Only time will tell whether users feel comfortable with this blurring of the boundaries between online and offline content, and this approach could potentially create new security problems.

Web developers need to learn very few new tricks to develop an app for Firefox OS: The same basic techniques are used as for normal web applications. Developers can implement programs in JavaScript on both the server and client sides.

The first specific challenge is the small screen. At this point, the apps do not greatly differ from the long-established mobile versions of larger websites. The only requirement for the installation of an app is the manifest [9], a simple JSON file. Of course, the user will prefer client-side apps, which can also be used offline thanks to cache management or local installation.

JavaScript Is Mature

The art of client-side programming in JavaScript has long reached a certain level of maturity: JavaScript is now as powerful as many of the classic scripting languages. The browsers come with a debugger, and IDEs [13] [14] support the language well. A wide selection of libraries and frameworks are present that often follow the model-view-controller paradigm (Table  3).

Light and Shadow

Many animation effects, but also functional features of a user-friendly GUI, are definitely easier to implement in HTML5 and CSS3 than in native graphical toolkits. One advantage of Firefox OS, however, is that there are more potential programmers around than for Android or iOS: Virtually any web developer can get started, with no major barriers to entry, although there are some undeniable drawbacks: JavaScript as a scripting language is inevitably slower than Java or C++, which has an effect on battery life.

In terms of security, browsers do not have good reputations. Although JavaScript is better than many C++ or Java developers might think, it still has inherent defects, such as the 64-bit limitation for floating point numbers. Additionally, whether users will be comfortable with the blurring of the online-offline boundary is not yet known.