This article is written in English.
Originally posted on Medium
One of the best things about porting a web engine to a new platform is how much you end up learning about that platform. You have to understand the application life cycle, how scheduling and event handling work, how sandboxing and application privileges are implemented, how the graphics and media stacks behave and a lot more… basically all the plumbing that usually stays hidden. It is full of surprises and sometimes pain, but most of the time it is actually fun.
This blog is a quick introduction to something I’ve been working on recently: WebKitView for OpenHarmony. The idea is to bring a WebKit based WebView to OpenHarmony. OpenHarmony already has a WebView framework, but it’s built around the Chromium engine and isn’t something you can just build from the public SDK. There is also a Servo port for OpenHarmony. My goal with this project is to get WebKit running on OpenHarmony using only the public SDK and make it run on the available development boards.
What does it take to port WebKit to a new platform?
WebKit has a few existing ports. The main one is the Apple port and another important one is WPE WebKit, which targets various Linux-based devices. Instead of creating a new WebKit port for OpenHarmony, I decided to use the WPE port because it’s designed so that platform integration can be done mostly outside the WebKit source tree. That said, in reality, you still end up patching WebKit here and there when adding support for a completely new platform like OpenHarmony.
WebKit isn’t a self-contained monolith. It depends on a huge chain of libraries. So before even thinking about platform integration, you first have to compile all those dependencies for the target platform. And that part is not very glamorous. Especially with OpenHarmony, because not many open-source projects support it out of the box.
Building WebKit dependencies
I reused experience from my earlier work on WPE Android. I forked the wpe-android-cerbero project, which uses Cerbero to build WebKit and all its dependencies. Cerbero is a build system aggregator. It fetches sources, applies patches, builds libraries and creates packages for various platforms and architectures. It supports both native and cross-compilation.
Cerbero uses .recipe files. Each recipe describes where to fetch source code, which build system to use (Autotools, CMake, Meson), what patches and compiler options are needed and which other recipes it depends on. This gave me a starting point, but of course nothing compiled for OpenHarmony out of the box.
The good thing is that many WebKit dependencies already use standard build tools. I patched Autotools, Meson and some custom build scripts to add OpenHarmony support. Things like correct toolchain path, sysroot, compiler flags and linker settings had to be adjusted. OpenHarmony also does not accept versioned .so files, so I patched the build tools to output unversioned shared libraries.
In short, some heavy groundwork was needed:
- Added OpenHarmony SDK and toolchain support to Cerbero
- Patched Autotools to recognize OpenHarmony as a platform
- Patched Meson for OpenHarmony
- Fixed custom build scripts for projects without proper build systems
- Fixed a bunch of compile errors caused by the older Clang 15 in the OpenHarmony SDK
Some libraries only needed build system tweaks. Others required actual source code changes. After a lot of patching, I could finally start compiling WebKit.
Building WebKit
OpenHarmony shares some conceptual roots with Android, and the WPE WebKit already has Android support. Many things behave similarly. In some cases function names or module names are different, but the logic is close. WebKit itself did not know anything about OpenHarmony, so I added a new OS variant to WebKit for it.
WPE WebKit only supports multi-process mode, meaning each web page runs in its own process. Some web engines render by sending drawing commands back to the application process, but WPE WebKit actually renders inside the web process, using either a software rasterizer or OpenGL.
A future goal for WebKitView on OpenHarmony is to support GPU accelerated rendering. That means sharing GPU buffers between processes. Linux often uses DMABUF. Android uses AHardwareBuffer. OpenHarmony has something similar called OH_NativeBuffer.
WebKit shares buffers using file descriptors sent over domain sockets. The problem is that the public OpenHarmony SDK does not provide the APIs needed for this. So I implemented a missing piece directly inside the OpenHarmony graphics stack. I named it:
This component allows sending OH_NativeBuffer handles between processes using sockets. It is one of the key requirements for future GPU rendering support.
Besides that, I made smaller changes across WebKit to get it compiling and to draw a simple web page. The older Clang 15 in the SDK made things harder in some places. All patches are applied in the wpewebkit.recipe on top of WPE WebKit 2.50.0.
Platform Integration
WPE WebKit has a component called WPEPlatform, which is designed for integrating WebKit with different platforms. As long as the platform supports buffer sharing in a way WebKit understands, most of the integration can be done outside of WebKit.
On OpenHarmony, applications run inside the ArkTS runtime. ArkTS supports ArkTS, TypeScript and JavaScript code. To make WebKit work, I implemented two main parts:
- An OpenHarmony-specific platform module for WPE WebKit
- A glue layer that connects WebKit’s native side with the ArkTS application side
For now I run WebKit on its own UI thread instead of integrating it into the ArkTS event loop.
Demo
Here’s WebKitView in action on OpenHarmony 6.0, running on the HiHope HH-SCDAYU200 development board (available on Bilibili):
Current status
✔ WebKit compiles on OpenHarmony
✔ Basic web pages render correctly
✔ OH_NativeBuffer sharing mechanism exists
✔ Integration with an ArkTS app works
Not yet supported:
✖ GPU accelerated rendering
✖ WebGL
✖ Media playback
✖ Deeper platform features like Bluetooth and Location services
It is still early, but it runs.
If you’d like to try it, the project’s README has setup instructions.
The project is available on GitHub as webkitview-openharmony.
