Aloha Core. I Love and Hate You

Introduction

One of the most crucial components of any web browser is its engine. This component is responsible for loading and rendering web pages, essentially defining what makes a browser a browser. Every browser has an engine in some form: Blink in Chrome, WebKit in Safari, and Gecko in Firefox. Browsers like Arc, Brave, Opera, and many others are built on Chromium and, as a result, also use the Blink engine. Aloha Browser has an engine as well.

This post will focus solely on the Aloha Browser for Android.

Origins

The Aloha team has always been small, so creating our own engine was never considered. In its early days, Aloha Browser for Android used the system WebView to display web pages. This was back in the distant past when Android WebView wasn’t updated with every Chrome release but existed as a relatively standalone component. However, it soon became clear that while this component was good enough for building a decent browser, it was limited and incapable of much more. Its API was far too restrictive.

Thus, the decision was made to migrate to the CrossWalk library, which Intel supported then. It provided an interface similar to the system WebView but was more flexible. Unfortunately, Intel eventually ceased development and support for the project, leaving Aloha to figure out what to do next. 

Alternatives

At this crossroads, we began exploring our options. Chromium itself was never designed to be used as a library; it’s always built into an APK. Thus, it wasn’t possible to “simply switch” to Chromium. However, we could fork it and follow many browsers' paths. By then, though, a significant amount of Java and Kotlin code had been written to implement various business logic, and we were reluctant to discard it. CEF, a project that transforms Chromium into a library, didn’t (and still doesn’t, at least officially) work on Android. Similarly, Qt WebEngine wasn’t an appealing option, and integrating Qt into a Kotlin project wasn’t ideal either. At the time, GeckoView was also in its infancy.

Aside

A couple of years later, we revisited GeckoView due to certain challenges with Chromium. First and foremost, GeckoView had an excellent community. They were genuinely excited that we were considering their engine for our browser and did their best to assist us. GeckoView was designed from the outset with reusability in mind, making it a pleasure to work with - when it wasn’t buggy. Yes, there were many bugs back then; the project was still in its early stages. Websites weren’t exactly thrilled to be rendered by Gecko: Google would appear as a blocky mess, video previews on nearly all video-hosting platforms wouldn’t play, and on some sites, videos wouldn’t play at all. Incidentally, one bug we reported back then wasn’t fixed until two years later. In short, while this approach might have made life easier for our developers, it would have significantly complicated things for our users. So, we decided to reinvent the wheel.

Bromium: The Beginning

We decided that using Chromium was orders of magnitude simpler than building our own engine. So, let’s turn an APK into an AAR; after all, it’s just a matter of two letters. Reality, however, was harsh. Making Chromium function as a library required extensive changes, code additions in both C++ and Java, and a lot of tweaking. Chromium simply wasn’t built for this purpose. The main issue wasn’t just the need to modify something—that’s par for the course. The real challenge was that significant changes would make it exceedingly difficult to keep up with Chromium updates, and frequent updates were necessary. We then decided to try building an AAR from WebView. This seemed simpler, if only because WebView, while also built into an APK, functions as a component rather than a standalone application. Naturally, we first wanted to do everything properly: write build scripts that would faithfully generate an AAR from WebView’s source code. This turned out to be a highly labor-intensive process, especially since a single employee handled it. Moreover, there was justified suspicion that the WebView developers might refactor their build principles at some point, forcing us to redo everything. Spoiler alert: this is exactly what happened - WebView build scripts underwent radical changes with alarming regularity.

Instead, we attempted to repackage the APK into an AAR as a starting point. Both are ZIP archives, so this operation is physically straightforward and requires minimal code changes. The result was something functional, albeit with a peculiar API. As it turned out, WebView’s polished API is part of Android, not WebView itself. This part interacts with Chromium’s code through a rather clunky API. On the bright side, this low-level API offers significant flexibility when working with the rendering engine. What initially seemed like a temporary solution until we found something better has faithfully served us for six years. It has survived updates from Chromium 57 to (at least at the time of writing) 130, changed maintainers three times, and shows no signs of retiring.

Some time ago, we decided to open-source AlohaCore and published it on GitHub.

To be continued.