-
Notifications
You must be signed in to change notification settings - Fork 6
2024 WPE Android status update
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/34
-
Jani starts talking about the background and motivation. About the dogfooding, explains also how useful it was also to detect issues on WPE (e.g. device scale factor related issues).
-
3 main building blocks: Cerbero (compilation system, forked from GStreamer), WPEBackend-Android, WPEView.
-
High level design: WPEView consumed by Android application, providing access to WPEWebKit. There are only minor patches to WebKit such as for filesystem access on Android.
-
Android buffer sharing: fences used when WPE finishes rendering the frame, passing the information to Android system, so that result can be composited.
-
Current status: focus on stability, testing support (i.e. WebDriver) still WIP (many tests run, but still many failing). NLNet partially funding the effort too, also increasing visibility (presentation in WebKit Contributors meeting, blog post).
-
Short term goals: Focus on unit tests, web inspector support, upgrading libsoup, bring WPEView API closer to Android's WebView API (not drop in but closer), provide ready to use library (e.g. as Maven dependency).
-
Long term goals: get stable API, improve performance and move to Skia-based WPE WebKit (could require dropping WPEBackend-Android and implement that inside WebKit - relates to the new API currently WIP).
-
Demo time:
- Demo 1: showcases basic navigation and WebGL support on real HW (Google Pixel 7). Most features that would be expected work, including media playback (some issues, though); goal is to have most features expected from a mature browser to work, adapted to Android.
- Demo 2: showcases tests being run using WebDriver support.
- Adrian notes that WebDriver works but LayoutTests do not as it can be controlled remotely easily but cannot run more complex test infrastucture.
- Not a current priority to run LayoutTests.
-
Snapshot: we have GitHub CI Actions generating an APK automatically for any commit in the devel branch (i.e. master).
Jani: asks what APIs would be useful?
Jani: asks what use cases should WPEView handled?
Justin: asks on whether there's any performance comparison against Chromium-based WebView
jani: We haven't done any real comparison yet.
Alicia: how does multimedia work (e.g. framework used)?
jani: It uses gstreamer
Alicia: what elements do they use?
adrian: It does use elements that use Android decoders.
alicia: is it autoplayed by playbin?
adrián: yes
alicia: so we don't have any special machinery on top of WK?
adrián: not that I remember
alicia: cool!
adrián: about gstreamer usage, a note on that we do NOT use a jumbo-like build at the moment (i.e. statically linked), but it's something we'd like to do. Our dependencies aren't ideal, some libraries such as libpng are built multiple times.
alicia: I assume it does not depend on glibc?
adrián: nope
Nikolas: quite impressive how this works, looks better than the demo last year.
Nikolas: it would be nice to find customers for this, but we would need to have compelling arguments (e.g. memory consumption) for potential users.
Adrián: agreed, that ties in with what I was commenting about reducing dependencies, reusing android libraries... that would help with those goals.
Adrián: I'd expect that the difference in memory usage might not be as dramatic as in regular linux systems (e.g. due to extra memory usage from gstreamer, compared to Chromium), but still should be better.
Nikolas: So you don't have custom patches to WebKit?
Adrián: don't remember the number, but we have 1-2 dozen of patches only)
Jani: 9 in total, really small patches anyway
Nikolas: For the future platform api, you won't have to change WebKit, it supports loading modules where you could implement the Android specific implementation.
Adrián: I think support for dynamic loading just landed past week.
Adrián: there are other things we need to work on, such as buffer-sharing strategies (i.e. AHardwareBuffer, a similar system to DMA-Buf in Linux)
Nikolas: It would be a great test for the new buffer-sharing APIs.
Alex: it would be a great next task here to support efficient buffer-sharing solution for WPE Android
Nikolas: I'd be happy to join forces. Looking good!
Jani: Yep, that's a good idea.
Nikolas: is there anything completely missing that hasn't been mentioned?
Jani: of course we have several things missing, and there are issues we haven't resolved yet (e.g. network cache using hard links, which are not available on Android's filesystem - not sure how to fix that yet). When you use a page with cookies, if you close the page the cookies are lost in the network cache.
Adrián: WebKit used to be the default view in Android, maybe we could see how they did caching in the past? Maybe we never supported any platform without hardlinks.
Jani: then of course, as a long term goal it would be nice to implement Web-facing APIs that are not available on desktop (e.g. APIs leveraging sensors such as accelerometers)
Adrian: Geolocation and device orientation are disabled. Not super important but useful for any handheld device. It depends on what kind of use cases we want to focus first.
Przemek: does it work on Android TVs? Have you ever checked that
Jani: we haven't checked that, but should work on any android-based platform.
Adrian: We just don't have an optimized layout for that, but the engine should work.
Mario: We know some are using it in those environments, even if an older experimental version.