Re create B2G based on Android

A few people (@lapineige, @TitanNano, @lissyx) started to discus the idea of re building B2G based on Android.

Therefore we would use a stripped down android (CM, AOSP) which then starts with a single gecko view. This way we wouldn’t need to take care of all the graphics and media stuff. We also would be able to create web services in order to bridge features like the camera into Gecko.

The questions we need to answer now are, do we want this? Does it make sense to build B2G based on Android? What would be the goal of such an OS?

At the moment we do not have any alternative plans. Feel free to and anything you think is important for this topic.

Firefox for Android is maintained by Mozilla.
Android is maintained by Google, Cyanogen Mod, AOSP and tons of manufacturers.
We only need to glue it together.

Pro of using Android:

yes we would remove every part of the original android UI.


Originally B2G was based on Android except the graphics stack. The method you discussed seems like Gecko running on Android base without touching any graphics stack. At this phase with the resources we have, basing on aosp or cm is a good plan.

1 Like

For the non tech guy it would be interesting to have the most exhaustive implication of this kind of switch…

Going to that path do we(can we) keep the spirit of B2G ?


1 Like

I’m not a programmer nor a technician, but in my opinion it can be a good option ONLY if we keep strictly following the b2g os original idea of a webcentric os.

No apps installed and no app stores. First of all.

Otherwise we’re going to work on another android mod, and this is not my intention.

p.s. may anyone help me understanding pro and cons in using Android open source, Cyanogen or Ubuntu touch?

1 Like

The method proposed above does not include ART nor any android specific components. We will reply on androids media stacks as B2G media stack will be removed.

1 Like

Pro of using Android:

yes we would remove every part of the original android UI.

What about chromium-os ? isn’t the same kind of concept but desktop based ?


1 Like

yes that’s the reason why we don’t want to just switch to android as our phone OS, so desperately :sweat_smile:

yes kind of.

1 Like

That’s the point I think.

As I proposed on Telegram, we could define what we would need to do to B2G-fy android, going back to a web-centric OS. That defined, how much work it is, and do we have enough time/workforce to do it.

And next: is it worth to do it ? Do we want to do it, what’s the goal of this kind of system :grey_question:

IMHO that’s our key question. Let’s discuss about it :slight_smile:

In my personal opinion, I’m B2G positive, I can’t go back to an user experience like Android or iOS. So I think it is worth doing it. The goal of this system would be to continue the webcentric UX and the spirit of B2G. As mentioned before. Everything Android user experience related like Apps and AppStores would be stripped away. We would create the same experience as B2G is now.

1 Like

On a theorycal level, I think it would worth, at least to offer people a free, open and webcentric alternative to other oses. This is the same need we were trying to cover with the original b2g os project, and I don’t think there’s any other alternative around there, even if ubuntu touch has received important updates, cause it still has the old appcentric structure we consider deprecated.

On the other hand, facing reality and considering our energies, it still remain unclear if we really can do that and, practically, how.

@TitanNano, I’m sorry if I’m repetitive, but can you make me understand if is there any difference between AOSP and Ubuntu Touch in terms of architecture? From what i know also ubuntu touch is based on android. And, if yes, why should we use aosp instead of cyanogen? I don’t see huge differences between those operating systems.

Once we overcame the base-os choice, it remain to understand what to do next.

Regarding that, can anyone draft a blueprint of the whole process, also considering what are we going to need (technically and, why not, economically if we need to set up an host, for example)?

I’m sorry I can’t really answer this questions.
For all I know CyanogenMod seems to support even more devices than AOSP but I’m not sure about that.
I don’t know about the relationship between AOSP and Ubuntu Touch but I could imagine that AOSP might be more lightweight.

Let’s give mine, even if I have no strong opinion yet:

I have the feeling that building on top of android (AOSP/CM, whatever) just to make a kind of mod, running our web apps as system apps, and just classic app aside, is somewhat pointless.

I really believe the app-store model is archaic, and a source of issues and troubles. The web is way more advanced and universal.

If we plan to build again b2g as a web centric os, with our system web apps + other web apps, why not. But I have the feeling that’s it’s a lot of efforts, without much more gain than a Cyanogen mob build + only web apps (except for the system apps, right now). I’m not sure it’s worth to do it.

But if we can re-create a web-centric experience, with all the power of add-on (for instance) as a webby customisation of the system, and so on. Combined with the growing web app ecosystem… It looks far more appealing. But it’s still a lot of efforts.

An yes, a free (as freedom) OS on phone is super important.


then why was it worth it to maintain B2G?

Please note that I’m talking without having much time to digest this decision. That means I’m surely still disappointed, not really speaking with my mind.

Because I love it, I love its idea(l) ! :heart:
Because we need a free as freedom mobile OS. Because mobile world should be open, as the web is.
That’s what I’m targeting since the beginning.

I wish we can maintain a web-centric B2G OS. If we cannot archive this goal, well it’s difficult for me to see the point (assuming there are others “free and open source” OS on phone).

and this is the point why we should continue with this new approach. I think you are seeing this too much from an end user standpoint. Actually we are “simply” going to change the technical aspects to create the same experience you love.

Lets say you’d like to write a letter. You always used MS Word to do that. But since today it doesn’t fit your needs anymore, you can’t write the letter you want. So you choose to switch to LibreOffice. You are still going to write that letter, only the software you used has changed.

1 Like

I can add some hints on this:

  • Ubuntu touch is based on CyanogenMod. “You can find all the needed Android code on the Android layer’s public git repositories. This is essentially a mirror of the CyanogenMod, but containing only the needed low level services used by Android (e.g. no Dalvik at all)”.

  • Regarding, CyanogenMod vs Android, instead, About 1-2 times a year, the vanilla Android operating system (known as AOSP, or the Android Open Source Project) is internally developed, then released to the public, by Google. They provide the source code to anyone who wants to download
    it. The CyanogenMod community, comprised mostly of unpaid volunteers
    and enthusiasts from around the world, takes this newest Android code
    and “ports” it to dozens of new and older (aka “legacy”) devices. At
    the same time, other CyanogenMod developers start adding features,
    fixes, and improvements that Google didn’t include to the CyanogenMod
    code, which benefits all the devices. The CyanogenMod community has a
    whole infrastructure for people to build and test experimental versions,
    report bugs, and contribute back to the source code".

So, in my opinion, CyanogenMod seems a little more appropriate to a community driven project as B2G.


How about a custom Android OS that have a simple SystemUI (No statusbar and no background) and a modified Settings app that controls the Web APIs to interact with System flawlessly (through Gecko and B2GDroid-like app or Firefox) and disallow other APK installation?

1 Like


Firstly, I want to say that the proposal sounds like an exciting direction to go in. I would however like to suggest that we discuss the overall architecture of this proposal a bit so that we understand the “big picture” direction being proposed here.

My understanding of what is being proposed here at a very high level (so ignoring whether this is Android or whatever for now) would be:

  1. There is a web service running on the device that hooks into the device’s existing runtime (e.g. Java/ART on Android devices) and provides access to hardware, services, etc. that don’t have web APIs using REST / WebSockets, whatever.

  2. We have web apps that are living wherever (could be on the device, on another server, it shouldn’t matter), that know how to talk to our web service in order to provide control over the system’s hardware, etc. from a browser window.

  3. We have some way of opening web browser window(s) on the device and loading our web apps. This enables users to manage their device from the web. The browser would of course have access to all the web APIs that a “normal” web browser on this platform would have (e.g. sound, vibration, webrtc, service workers, whatever).

Does that sound right to others? What I like about this set-up in particular is that there seems to be loose coupling between the three above components:

  • Someone might want to just use the web service part to remote-control their device, so this project could have broad appeal to hackers wanting to do more with their devices. Maybe an effort already exists that we can tag onto.

  • The web apps would presumably be able to run anywhere where they could access the web service, so they would be extremely portable. For instance they could be used on the device without installing the cut-down UI, if someone wanted to continue to use the standard host UI. If someone wanted, they could wrap them with cordova or whatever to make them look like Android/whatever apps.

  • if someone implements the web service on a new platform, they get the webapps for free!

I also like the idea that we would be standing on the shoulders of giants by reusing existing platform support. I agree with what others have said that this is a very small community with extremely limited people power.

I have one initial concern/query about part 3 in my list: how would window management and browser chrome work? I don’t know 100%, but I believe there are some pretty severe limitations to what one could do with standard iframes as they are available to webapps. In B2G, there’s a special Browser API (also available in Firefox chrome) for this. Would the plan be to implement the basic window manager and chrome in the host system’s stack (e.g. Android), or do the proponents envisage running an HTML5 chrome window, like we are doing at present with the system app?