First look: Mozilla’s Boot2Gecko mobile platform and Gaia UI

The development of Mozilla's Boot2Gecko mobile operating system is progressing …

Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform's user interface and application stack will be built entirely with standards-based Web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox Web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.

The B2G team at Mozilla is preparing to give a demo of the platform's user experience at the upcoming Mobile World Congress (MWC) event. Mozilla's Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.

According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That's a highly ambitious target, but the project's impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.

The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.

The Linux kernel that is used in Gonk is said to be "reasonably close" to upstream Linux. According to Mozilla's documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It's currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.

Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.

The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual Web content and multimedia playback will be handled by separate processes that communicate with the B2G process.

Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to Web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.

The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device's battery level and status, sending and managing SMS messages, accessing the user's address book, and making a device vibrate. These capabilities are largely made accessible to Web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a Web page that uses a JavaScript function to initiate a call.

Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default Web browsers that ship with other platforms.

The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just Web content) to run in Web browsers on other platforms. At that heart of Mozilla's agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.

Because B2G's Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop Web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.

We tested the Gaia home screen user interface and several of the platform's applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.

When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.

B2G lock screen

If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It's quite simple and predictable Web content.

The B2G home screen

Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a Web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The Web browser is basically a Web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.

B2G sample map application

B2G's Web browser. It's practically begging for a Yo Dawg joke

The B2G dialer

The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional Web content can be used to create a smartphone user experience. It's possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.

Mozilla hasn't created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It's theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.

The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based Web technology stack is also tremendously compelling. It hints at the possibility that the open Web could someday provide a unified application platform for mobile devices.

It's also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla's engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.

There needs to be a native UI toolkit. Android apps by and large suffer greatly because so many of them require their developers to create a host of UI widgets. These apps end up running slow, scaling poorly and having unpredictable behavior (because everyone is making them differently).

So how does this compare to the webOS platform we were talking about yesterday?

Obviously there's different licencing, but the actual concept sounds almost identical. Could the different layers be mixed and matched between projects, if one wanted to?

Both projects aim to have the web as the development platform, and both projects use Linux as the underlying kernel.

Aside from that, the main difference is that WebOS invented its own APIs for letting JS+HTML apps do "native app" stuff (like accessing the phone dialer, for example), which made sense since WebOS was way ahead of its time; B2G on the other hand is using existing HTML5 APIs and adding new ones as necessary and starting a standardization process on them. The result is that, eventually, a B2G app will be just a webapp, runnable everywhere, while WebOS apps are WebOS specific (even though they use HTML+JS - just like Windows Metro apps, that also use HTML+JS, but are Windows-specific).

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

So how does this compare to the webOS platform we were talking about yesterday?

Obviously there's different licencing, but the actual concept sounds almost identical. Could the different layers be mixed and matched between projects, if one wanted to?

Both projects aim to have the web as the development platform, and both projects use Linux as the underlying kernel.

Aside from that, the main difference is that WebOS invented its own APIs for letting JS+HTML apps do "native app" stuff (like accessing the phone dialer, for example), which made sense since WebOS was way ahead of its time; B2G on the other hand is using existing HTML5 APIs and adding new ones as necessary and starting a standardization process on them. The result is that, eventually, a B2G app will be just a webapp, runnable everywhere, while WebOS apps are WebOS specific (even though they use HTML+JS - just like Windows Metro apps, that also use HTML+JS, but are Windows-specific).

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

I guess the now open WebOS could adopt the B2G APIs in short order, allowing developers to work across both. Anyone know how well Enyo works on B2G?

You mean in addition to Android, Meego, and (recently) webOS? Yup, another one.

While the more the merrier, and Mozilla are good guys, the part that's going to be a problem, as it is with Android AOSP ROMS, Meego, webOS and every alternative phone OS is going to come down to the question of "what can you run it on?"

As even those of us with Android phones painfully learned, you can have the most open OS in the world, but if your phone has a locked bootloader using encryption, you can't try anything else out. So, I guess all those of you who want alternative OS's out there better all buy Nexus Android phones, Samsung phones, or (let's pray Google reforms the wretched Motorola bootloader locking) some HTC phones sometimes. And of course the only reason that's even an option is because of Android - Microsoft's going to REQUIRE bootloader locking for Windows on ARM, and Apple is Apple.

So I guess if you're going to use Android's kernel, drivers, and phones to launch your open source project, you should at least give them credit for getting a foot in the door for 'real' open mobile operating systems to have something to install on, instead of hating them up, like Ryan Paul likes to do.

So how does this compare to the webOS platform we were talking about yesterday?

Obviously there's different licencing, but the actual concept sounds almost identical. Could the different layers be mixed and matched between projects, if one wanted to?

Both projects aim to have the web as the development platform, and both projects use Linux as the underlying kernel.

Aside from that, the main difference is that WebOS invented its own APIs for letting JS+HTML apps do "native app" stuff (like accessing the phone dialer, for example), which made sense since WebOS was way ahead of its time; B2G on the other hand is using existing HTML5 APIs and adding new ones as necessary and starting a standardization process on them. The result is that, eventually, a B2G app will be just a webapp, runnable everywhere, while WebOS apps are WebOS specific (even though they use HTML+JS - just like Windows Metro apps, that also use HTML+JS, but are Windows-specific).

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

I guess the now open WebOS could adopt the B2G APIs in short order, allowing developers to work across both.

That is possible, but it would mean a big change in the WebOS developer API, all their current apps use the current APIs.

So how does this compare to the webOS platform we were talking about yesterday?

Obviously there's different licencing, but the actual concept sounds almost identical. Could the different layers be mixed and matched between projects, if one wanted to?

Both projects aim to have the web as the development platform, and both projects use Linux as the underlying kernel.

Aside from that, the main difference is that WebOS invented its own APIs for letting JS+HTML apps do "native app" stuff (like accessing the phone dialer, for example), which made sense since WebOS was way ahead of its time; B2G on the other hand is using existing HTML5 APIs and adding new ones as necessary and starting a standardization process on them. The result is that, eventually, a B2G app will be just a webapp, runnable everywhere, while WebOS apps are WebOS specific (even though they use HTML+JS - just like Windows Metro apps, that also use HTML+JS, but are Windows-specific).

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

I guess the now open WebOS could adopt the B2G APIs in short order, allowing developers to work across both.

That is possible, but it would mean a big change in the WebOS developer API, all their current apps use the current APIs.

Not possible to maintain both? say keeping the existing ones around, but marked as no longer primary, while introducing the B2G ones, once the details have been hammered out?

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

I would welcome B2G making inroads into the mobile market to offer some competition to the WebKit monoculture. With Microsoft's renewed (novel?) interest in web standards even Windows Phone getting a respectable market share would probably help to maintain the health of the Open Web (tm) in the long-term with 3 independent implementations of web standards on mobiles. But where does that leave Opera? I kinda feel sorry for them. They have excellent engineers (can't be said for their UI designers though), have been a major contributor to the current standards and are fierce advocates of the open web, but somehow they aren't able to capitalize on it.

Another main difference is that WebOS uses WebKit while B2G uses Gecko.

I would welcome B2G making inroads into the mobile market to offer some competition to the WebKit monoculture. With Microsoft's renewed (novel?) interest in web standards even Windows Phone getting a respectable market share would probably help to maintain the health of the Open Web (tm) in the long-term with 3 independent implementations of web standards on mobiles. But where does that leave Opera? I kinda feel sorry for them. They have excellent engineers (can't be said for their UI designers though), have been a major contributor to the current standards and are fierce advocates of the open web, but somehow they aren't able to capitalize on it.

They seem to do very well with Opera mobile and mini (Mini keeps getting bundled by various carriers in Asia and elsewhere). I think they also have licensed their engine to various third parties, like Nintendo. They offer a option that is standard compliant but not tangled with copyleft licensing the way webkit and gecko are.

OpenMoko (http://wiki.openmoko.org/wiki/Main_Page) predates even Android or iOS, and even gives you the phone schematics. The only thing you don't get is a single binary blob for the software defined radio, as by FCC law they can't or it would allow license violations and interference.

You mean in addition to Android, Meego, and (recently) webOS? Yup, another one.

Android isn't a truly "open" OS. The source code is released after the development of that version is complete.

The full source code is available under an OSI-compatible open source license. To define that as 'not open' is inane. What you, personally, in your own head (along with Ryan Paul) THINKS 'truly' open means is irrelevant. Android does not use a open governance model. That does not change the fact that it is, actually, open source. But sure, keep trying to sabotage the open-source movement by trying to start infighting. Microsoft and Apple with their locked bootloaders, closed source operating systems, restricted app installs and the ones who benefit when you try to tear down Android offer you their thanks. But sure, lets keep talking about which open-source projects are the 'openest'. Cause that's helpful.

You mean in addition to Android, Meego, and (recently) webOS? Yup, another one.

Android isn't a truly "open" OS. The source code is released after the development of that version is complete.

The full source code is available under an OSI-compatible open source license. To define that as 'not open' is inane. What you, personally, in your own head (along with Ryan Paul) THINKS 'truly' open means is irrelevant. Android does not use a open governance model. That does not change the fact that it is, actually, open source. But sure, keep trying to sabotage the open-source movement by trying to start infighting. Microsoft and Apple with their locked bootloaders, closed source operating systems, restricted app installs and the ones who benefit when you try to tear down Android offer you their thanks. But sure, lets keep talking about which open-source projects are the 'openest'. Cause that's helpful.

Yes, Android is OSS, just not Open Development.My question is: why be open source at all if they aren't going to take advantage of open development?I'm not complaining since code dumps at least give us the opportunity to put an, arguably, better version of Android on devices than would otherwise be the case, but open development can be done in such a way so that there is a group in charge (your "cabal", if you will), but anyone can, and do, have the opportunity to send in patches.While Google would still do the brunt of the work (at least, for awhile), they'd get code for free before long, and, by developing openly, the hope would be that many currently closed source drivers would join the tree so code-to-device times came be reduced.I can't imagine that Google is happy with the way updates are now, but if they made this code open to EVERYONE, not just their partners, it is at least possible that things could develop as I stated above.

well the idea is interesting and i wish the B2G people the best of luck but this looks scary to me.what things are in place to keep malicious sites from sending SMS messages on my phone when i visit them, this opens a whole new realm for XSS.

there is the advantage that malware will now be open source. rather than worrying about exes we need to worry about js and html files

There needs to be a native UI toolkit. Android apps by and large suffer greatly because so many of them require their developers to create a host of UI widgets. These apps end up running slow, scaling poorly and having unpredictable behavior (because everyone is making them differently).

I'd agree, and even go further: There needs to be a unified UI User experience.

I'd love to see a world where applications are developed, but a platform vendor (the device manufacturer, a network, someone else who gets paid somehow) does the unified UI experience customization. There are limits to what you can do with JS and java Scripts, like can't easily add a field to the page.

But would that not be a great world where some people would focus on the data services and may be a layer that does some merging with local data and caching (maps, images, address book integration, ...) Some one else would design the views (pages) and actions (buttons and gestures) and a third layer would do the visual layout and design to make it uniform.

It would be like a VW designed by Pininfarina with a BMW 6 cylinder straight engine and a Porsche suspension. :-)

"but open development can be done in such a way so that there is a group in charge (your "cabal", if you will), but anyone can, and do, have the opportunity to send in patches."

Because other OS vendors would have an opportunity to mimic the new features of the next version of Android before the new version is even released. So much for competitive advantage. Instead, with the current model, we have Android catching iOS by surpise with things like the notification drawer or the data meter.

Because other OS vendors would have an opportunity to mimic the new features of the next version of Android before the new version is even released. So much for competitive advantage. Instead, with the current model, we have Android catching iOS by surpise with things like the notification drawer or the data meter.

Right, and this probably makes sense for Google, so Android is not developed in the open. Hence "Android is open [source]" and "Hey look, an actual open[ly developed] mobile phone platform" are both accurate. "Android is open" has always annoyed me for precisely this reason — c.f. the Oracle press release blurb,

Oracle (NASDAQ: ORCL) is the world's most complete, open, and integrated business software and hardware systems company.