I would like to write a summary of the work we have been doing in wpe-android<\/strong> in the last year, where this port of WPE comes from and where it is now. The details deserve their own posts and I plan to write more about specifics. Now that WPEPlatform<\/strong> is going to be released as stable in the next few days seems a good example of how to use it, we have been actively using to test the API in the last months.<\/p>\n<\/div>\n\n\n\n wpe-android<\/strong> started in 2017 as an experiment of running WPE WebKit on Android. The engine communicated with the system through libwpe, the abstraction library WPE used before WPEPlatform<\/strong>. It used an Android backend living in its own separate library, libWPEBackend-android, and the Java side exposed the API with the Since then we have been implementing WPEPlatform<\/strong>, a new platform abstraction that has been added inside WebKit. It gave us the chance to fix both problems at the same time. During this spring we implemented a proper Android backend on top of it, so now the display system of Android looks like a regular WPE platform to the engine. We ported the tools used to the new API, the MiniBrowser, the media player sample, the instrumented tests and WebDriver. We were able to delete the legacy stack.<\/p>\n\n\n\n After that, the only thing keeping libwpe in the build was process management: Android cannot simply With that in place, we were able to remove libwpe entirely, and WPE WebKit now talks to Android the same way it talks to any other platform. In parallel, we kept improving other parts of the platform, implementing new API features and fixing bugs along the way. One notable example is a scroll jank issue on the Mali driver, which was resolved largely thanks to the Skia DDL architecture upstream (a story that deserves its own write-up).<\/p>\n\n\n\n There is still plenty work to do, for our small team this project is still a very valuable experiment and we would like to keep exploring the options.<\/p>\n\n\n\n The code is here if you want to give it a try or help:<\/p>\n\n\n\nWPEView<\/code>, WPEContext<\/code> and the other proxy classes. It was a useful experiment. It was enough to show the engine running in a phone. The problem is a good part of the Android specific code, in particular the rendering path sending buffers to a SurfaceControl<\/code>, was placed in the application side instead of in the platform layer of the engine. Also Android developers had to learn an API that did not look like anything they already had in the platform, it was close to the Linux WPE API.<\/p>\n\n\n\nWPEDisplayAndroid<\/code> registers as a display extension point and sets up an AHardwareBuffer<\/code> configuration, WPEToplevelAndroid<\/code> follows the ANativeWindow<\/code> lifecycle from the SurfaceHolder callbacks, WPEViewAndroid<\/code> submits the frames with SurfaceTransaction<\/code> and explicit sync fences, and WPEScreenSyncObserverAndroid<\/code> uses AChoreographer<\/code> so the engine renders aligned with vsync. On top of that we added a thin JNI bridge that mirrors the WebKit and WPEPlatform<\/strong> objects in Java, and a new convenience API that looks like android.webkit.WebView<\/code>, with WebView<\/code>, WebContext<\/code>, WebSettings<\/code>, CookieManager<\/code>, WebViewClient<\/code> and WebChromeClient<\/code>. This way people can reuse the Android documentation and the knowledge they already have instead of learning something new.<\/p>\n\n\n\nfork()<\/code> and exec()<\/code>, since auxiliary processes are Android services that need to be launched explicitly. To solve this, we implemented a WPEProcessManager<\/code> API for WPEPlatform<\/strong> inside WebKit, which landed upstream and is now used by the port.<\/p>\n\n\n\n
![\"\"](\"https:\/\/blogs.igalia.com\/alex\/files\/2026\/09\/wpe-screenshot-461x1024.png\"){kind=spacer}
<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"