Re create B2G based on Android

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)”. https://wiki.ubuntu.com/Touch/Contribute

  • 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". https://wiki.cyanogenmod.org/w/About#So_what_is_the_difference_between_Android_and_CyanogenMod.3F

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

2 Likes

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

Hello,

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?

2 Likes

that’s basically what we’re talking about.

yes the idea would be to use the current gaia apps, so also current system app.

I did a bit of research on Ubuntu Touch, etc. when I was looking into whether a glibc-based Linux environment could ease some B2G dev pains (see here; never really went anywhere), so I will attempt to give a bit of explanation.

I think Ubuntu Touch is not really based on Cyanogen anymore – see
https://wiki.ubuntu.com/Touch/FAQ#How_is_Ubuntu_Touch_connected_to_Android.3F. The core of the Ubuntu Touch environment is really just an ARM port of Ubuntu. For instance, apt-get package management is there, the system uses Upstart to manage services, etc. Notably it’s glibc-based, instead of bionic-based (bionic is Android’s libc implementation).

Ubuntu Touch boots pretty much like desktop linux; then runs a tiny Android environment in an LXC container, which is sort of like a chroot on steroids. The only reason to do this is to support binary blobs from vendors which were compiled to run on bionic (the android libc) – e.g. OpenGL drivers, the telephony daemon, etc. Ubuntu then uses a library called libhybris to bridge between the container and the Ubuntu environment. You can see details about this here.

So I would say that Ubuntu Touch actually has more in common with Sailfish OS (and KDE Plasma Mobile) than it does with Cyanogen. For one, they both use QT5 extensively (Unity8 for Ubuntu is QT-based), they are using things like libhybris to be able to run on Android-oriented devices, and they are both using dbus services like ofono for IPC. They also have quite a few differences, like different build systems, Wayland vs. Mir for the display manager; systemd vs. Upstart for the init system, etc.

Ubuntu Touch would definitely not be a good basis for any project that planned to use Android’s Java APIs. Probably a system based on Ubuntu Touch would be based on Unity8 / QT5 and Mir. There’s a bit of a discussion from last year about what QT support in gecko would take here. I would say based on our recent experiences, it’s doubtful that it would be supported.

There is probably more prospect of Gecko running in Sailfish or KDE Plasma, given that there are open bugs for Wayland support – see here. However, the Wayland support will be GTK3-based, so that would make things more difficult.

EDIT: It turns out that the Sailfish OS browser is already Gecko based, and has it’s own QT wrapper! See https://github.com/sailfishos/sailfish-browser

1 Like

That is mostly the idea I expressed that triggered that topic: make an Android homescreen app that uses a fullscreen GeckoView component and implement needed APIs as external services. This way we gain from the support of Android stack as part of GeckoView/Fennec, we can have our special needs covered without cluttering Gecko, and relying on an Android homescreen make it easy (nearly trivial?) to support new devices. We might need to make a few hacks to make sure nothing interferes with the UI, but this would be no big deal.

2 Likes

We tried the homescreen option with b2gdroid, and that has several UX issues:

  • the system app’s notification bar interferes with the system one.
  • we end up with web apps managed by the homescreen, and other apps managed by the system window manager. That’s quite a mess for the user (we tried to have the webapps managed also by android, but that was not a great experience).
    Overall, the system app and the settings app don’t really belong to something that runs as a homescreen. We can clearly see that you try to run an OS in another OS and that they fight quite a bit :wink:

So we are left with two options:
1- build a homescreen, based on the homescreen app only. I don’t think this would be a very interesting project, but feel free to try :wink:
2- replace the “system UI” from android by our system app. We would get the full b2g user experience, and no android app support at all, which I actually like. We need to be opinionated!

Implementation wise, I’m doing an aosp build to check if replacing the system UI app is actually doable. I’ll start by using Fennec, and if that works, I’ll replace it by something close to what b2gdroid was.

That means that from a gecko point of view, we would be “android” which I think will guarantee some long term support. We will still need external daemon/services to implement eg. the telephony apis and a few others. I’m not sure yet if we should use the java bindings for that or go one level deeper in the stack.

1 Like

yes I agree. We want b2g experience, no android :slight_smile:

Am I right that in the end it wouldn’t matter if we use AOSP or CyanogenMod? The modifications would be the same, right?
Also fennec already supports XPIs, could we retain this with “something close to what b2gdroid was”?

The idea of asppsa to use D-Bus https://discourse.mozilla-community.org/t/should-we-worry-about-this/10407/17?u=sizvix is possible with just AOPS and few dependencies ?

For the Gecko-view I’m thinking about what append if an app crash ? or freeze ? We could use exceptions, but will it be enough to keep the system stable and not slowly ?
Tabs with e10s are good things, we just need to hide chrome’s parts and make preview of those tabs for the app selector screen ( we need to make a communication between tabs and how to change focus on tab, ok )

I think we would stay with the current model. Only one gecko view (window / tab) and all apps are handled inside the system app.

I really like the idea !

We should get rid of Java !!

My main problem is that i don’t have any idea of what are the implication but if we go that way I’m totally onboard !

Regarding ASOP VS CyanogenMod(CM), I understand that CM support more devices, right ?
Finally does this model give us the possibility to keep all already existing App ?

Matth

1 Like

I’m not sure if we can do that. Fennec requires Java.

I think so, but as far as I know it shouldn’t matter if AOSP or CM, I believe we can apply our Gecko + Gaia onto either.

Concerning Fennec, what would happen if Mozilla decides in the future to abandon Firefox for Android? I hope I am wrong, but I am guessing there is some chance that this could happen, given that it is not widely used (see http://caniuse.com/usage-table). Isn’t there a danger that this could lead to another dead end?

Thinking along those lines, is it possible for this architecture to be planned in such a way that it could potentially work with any web view, or is it that not really a possibility?

1 Like

The custom SystemUI I meant is a SystemUI only for touch input, excludes notifications, system bar, home screen wallpaper, etc.

Even Google now starts to use OpenJDK, that’s why Oracle vs Google occurs.

I do agree, and that’s a great chance, as it suddenly multiply the number of people able to test and use it.

Definitely option 2 !
And years after years, with the rise of webapps, this default will decrease.
And we don’t rely on any app-based system, while providing a better UX.

Furthermore, I think that any competitor to android, in its same paradigm, is promised to fail.

Already ? Great ! :slight_smile:
I can’t wait to know the results :wink:

I’m not sure to understand that clearly: we would interact with gecko from a “lower level”, interfacing between gecko and the android base ? Is that correct ?

B2G is already based on Android. Gonk is basically AOSP without the Java Android Runtime layer (a lot like Brillo actually), with Gecko rendering directly onto the lower levels of Android. The legacy device APIs interfaced directly with the Android HAL layer without using the Java Android Runtime layer. This is what allowed us to make web apps competitive with “native apps”.

If these Gonk porting layers can’t survive then “based on Android” probably means being based on the Java Android Runtime. This creates duplication between Gecko and parts of the Android stack which Gonk was designed to remove (e.g. there’s a Gecko compositor running on top of an Android compositor).

It’s certainly possible to build an OS which uses Gecko to render an HTML UI on top of the Java Android Runtime, but I would argue this is no longer B2G, it’s just an alternative skin for Android. Maybe you don’t allow installing other Android apps but the Android Runtime layer is still there. Web apps can never compete with “native apps” on performance using this more bloated stack.

Building commercial devices on this stack probably wouldn’t be possible with most OEMs either due the licensing terms between OEMs and Google, but I’m not sure how much the community cares about that.

If the community wants to build a skin for Android with an HTML UI dedicated to running web apps then that’s fine, but I think that’s a separate project to B2G so I’d suggest calling it something else.

3 Likes

Thanks for the input Ben!
Since this is the only stack Mozilla will support, would it possible to minimize the overhead the additional Android Compositor creates? Maybe we can disable most of it’s functionality? If I understand you correctly, the only thing gecko is lacking of, is the ability to transfer the graphics to the HAL layer. If the android compositor only acts as a gateway, we maybe can get the best out of this unfortunate constellation.

Hi Jovan,

I’m not an expert on the graphics stack, but I don’t think it really works like that. You either use the compositor (via the Java graphics API) or you don’t. Using the Java layer doesn’t make the web unusable, that’s exactly how Firefox for Android works! it just makes it less competitive with native because it’s the web running on top of the native app layer rather than the web being the native app layer. That was kind of the point of the B2G project, booting directly to Gecko without an app runtime in between.

Ben

1 Like