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
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
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 
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 !
I can’t wait to know the results
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
Hope there is a simple solution for Gecko to access android graphics stack without ART
There is, it’s called the Gonk widget layer. It’s one of the pieces being removed from Gecko.
The only way to keep this working is to maintain a fork of Gecko, an entire browser engine specifically for the B2G project.
The options are basically:
- Maintain a new browser engine forked from Gecko which still has the Gonk widget layer (a huge task)
- Build an HTML skin for Android running on Gecko with the Android widget layer (Inferior performance to Gonk)
- Use a completely different stack (e.g. vanilla Linux with GTK which is going to be extremely hard to get working on Android hardware, or a port of a different browser engine which is probably just as much work as maintaining the Gonk port of Gecko).
As you can see, the options are not great. This is why we fought so hard to try to keep the Gonk widget layer.
2 Likes
Yeah, I remember you saying it’s not possible to maintain the gonk widget
layer separately…