Guest post by Julie Kim, Software Engineer, Igalia
Since last year, Igalia has worked on Chromium and Web Application Manager(WAM) on AGL. Before starting to explain Chromium and WAM on AGL, I’d suggest reviewing Multi-process Architecture and Chromium Wayland, to help you understand the current design of Chromium on AGL. You can also review a talk I gave earlier this year on ‘HTML5 Apps on AGL Platform with the Web Application Manager’ at Automotive Linux Summit in Tokyo.
Igalia started working on Chromium and WebAppManager with AGL because we believe Web Applications should be first-class citizens in AGL. WebApps bring flexibility and power for a large number of developers. Once AGL has Web Application Manager, people can easily deploy their applications even without deep knowledge of the AGL platform, and connect their apps to various services through the network.
Our goal was to support Chromium with upstream Wayland port and Web Application Manager. Although we faced a lot of challenges, such as porting them to AGL framework, handling SMACK on Chromium multi-process architecture, supporting wayland ivi protocol on Chromium and so on, we completed our goal and showed a demo at CES 2019 in the AGL booth.
We’ve done the tasks below.
- Creating meta-html5-framework to support the recipes and layers for Chromium and WAM
- Support Wayland IVI protocol
- QT-less Web Application Manager
- Integration Chromium and WAM with AGL Framework
- Integration Chromium and WAM with AGL Security mode
One of my colleagues, Jacobo Aragunde, who has worked on AGL since last year, wrote a great blog post about our work, which I’ve appended here.
If you have ‘meta-html5-framework’ and a sample web application such as ‘agl-html5-hvac’, you can try Web Applications on your environment. When you run the aglsetup.sh script, includes ‘agl-html5-framework’ like
| $ source meta-agl/scripts/aglsetup.sh -m $MACHINE -b build agl-devel agl-demo agl-netboot agl-appfw-smack agl-localdev agl-html5-framework |
and build using bibake like
| bitbake agl-demo-platform |
You can refer to Building the AGL Image about how to build the AGL image.
Introducing the Chromium-based web runtime for the AGL platform
By Jacobo Aragunde, Software Engineer, Igalia
Igalia has been working with AGL (Automotive Grade Linux) to provide a web application runtime to their platform, based on Chromium. We delivered the first phase of this project back in January, and it’s been available since the Flounder 6.0.5 and Guppy 7.0.0 releases. This is a summary of how it came to be, and the next steps into the future.
Web Applications as First-Class Citizens
The idea of web applications as first-class citizens is not new in AGL. The early versions of the stack, based on Tizen 3.0, already implemented this idea, via the Crosswalk runtime. It provided extended JS APIs for developers to access to system services inside a web application runtime.
The abandon of the Tizen 3.0 effort by its main developers meant the chance for AGL to start fresh, redefining its architecture to become what it is today, but the idea of web applications was still there. The current AGL architecture still supports web apps, and the system APIs are available through WebSockets so both native and web applications can use them. But, until now, there wasn’t a piece of software to run them other than a general-purpose browser.
Leveraging Existing Projects
One of the strengths of open source is speeding up the time-to-market by allowing code reuse. We looked into the WebOS OSE platform, developed by LGe with contributions from Igalia. It provides the Web Application Manager (WAM) component, capable of booting up a Chromium-based runtime with a low footprint and managing application life cycle. Reusing it, we were able to deliver a web application runtime more quickly.
Our contribution back to the webOS OSE project is the use of the new Wayland backend, independently developed by Igalia and available upstream in new Chromium versions. It was backported to the Chromium version used by WebOS OSE, and hopefully it will be part of future releases of the platform based on newer versions of Chromium.
Development Process
Wayland
The version of Chromium provided by the WebOS OSE platform makes use of an updated version of the Intel Ozone-Wayland backend. This project has been abandoned for a while, and never upstreamed due to deep architecture differences. In the last couple of years, Igalia has implemented a new backend independently, using the lessons learned from integrating and maintaining Ozone-Wayland in previous projects, and following the current (and future) architecture of the video pipeline.
As we mentioned before, we backported the new implementation of the Wayland backend to WebOS OSE, and added IVI-shell integration patches on top of it.
AGL life cycle
The WAM launcher process was modified to integrate with AGL life cycle callbacks and events. In particular, it registers event callbacks for HomeScreen, WindowManager and notification for ILMControl, activates WebApp window, when it gets Event_TapShortcut, and manages WebApp states for Event_Active/Event_Inactive. LGe, also a member of AGL, provided the initial work based on the Eel release, which we ported over to Flounder and kept evolving and maintaining.
AGL security model
In the AGL security model, access to system services is controlled with SMACK labels. A process with a certain label can only access a subset of the system API. The installation manifest for AGL applications and services is in charge of the relation between labels and services.
Access to system APIs in AGL happens through WebSockets so, from the point of view of the browser, it’s just a network request. Since WAM reuses the Chromium process model, the network interaction happening in any running webapp would actually be performed by the browser process. The problem is that there is only one browser process in the system, it’s running in the background and its labels don’t relate with the ones from the running applications. As a solution, we configure web applications to channel their networking through a proxy, and the WAM launcher creates a proxy process with the proper SMACK label for every webapp.
The current implementation is based on the Tinyproxy project, but we are pending to review this model and find a more efficient solution.
Next Steps
We are clearing any Qt dependencies from WAM, replacing them with standard C++ or the boost library. This work is interesting for AGL to be able to create a web-only version of the platform, and also for WebOS OSE to make the platform lighter, so we will be contributing it back. In this regard, the final goal is that AGL doesn’t require any patches on top of WebOS OSE to be able to use WAM.
Also, in the line of creating a web-only AGL, we will provide new demo apps so the Qt dependency wouldn’t be needed anywhere in the platform.
And, after the AGL face-to-face meeting that Igalia hosted in Coruña, we will be integrating more subsystems available in the platform, and reworking the integration with the security framework to be more robust and efficient. You can follow our progress in the AGL Jira with the label WebAppMgr.
Try it Now!
The web application runtime has been available in all major AGL releases
since Flounder 6.0.5, including the current stable release, Halibut
8.0.2. It can be tested adding the agl-html5-framework feature to the
AGL build setup script. We have been working on several demos, including
HTML equivalents to the current HMI apps; they are available for testing
in AGL-web-applications at Github, and will be part of official
AGL images soon!
If you will be at CES 2020, make sure to stop by the AGL booth in the Westgate Hotel, booth 1815, to see the Igalia demo in action!
