 Hi, so welcome to this session on Automotive Linux Summit, this time happening virtually. So first thing I hope everybody is fine. Take care on this very complex situation and hopefully next time everybody will be meeting in person again in Tokyo. So this session I'm going to talk about is the status of the HTML5 demo platform on AGL, the structure and integration of web applications into the platform. So the first thing, this is a small agenda of what I'm going to cover in this talk. So I'm introducing a bit about who we are and I'm explaining the overall goals of the web runtime of the AGL platform. Some details on how Chromium and the web application manager architecture is used to provide HTML support in the software platform. And then I'm getting into the details of the pure HTML5 demo image, how it's home screen is designed and how web apps are running to it and how new applications can be created and integrated into the system and have it on the internals. And then I'm going to show a few examples of the way web UI running on the reference hardware. And then I'm following up with some status update, plans for the future and some open sessions for requesting the answers. So yeah, many people already know about us, I belong to, well my name is Lorenza Tilve and I work for Igalia. We are an open source consultancy, our headquarters is in Galicia in Spain, but we are currently over 90 employees all over the world. And our main area of expertise is mostly specializing in browsers and web engines. So we have owners and reviewers of different parts of Chromium, WebKit and WPE and Firefox. So recently on specific events on both communities we have been actually showing that have been basically the second biggest contributor to both Chromium and WebKit after Google and Apple respectively. So yeah, we have been working on web engines for a long time and that's the reason we are the responsible of the integration of a web application manager in Chromium based on Igalia. And about that we also have teams working on compilers, JavaScript engine and graphics and multimedia accessibility and another few parts of the web engines. You're actually distributed worldwide and there's people from Igalia everywhere, it's just happening to most of us nowadays and especially in this pandemic situation. So why Chromium and WAM into Igalia platform? So basically the idea was to have web engine support in the Automotive Grid Linux ecosystem. Basically the reason to use Chromium was actually well tested web framework that it's already have a separation of processes that actually splits between browser, renderer, GPU process to isolate execution to have security interactions with different layers. And now more recently with other parts of the architecture that also allows to separate parts as input output or any other types of interaction. It's very used worldwide, it has the latest updates of the specs. It's powerful and can be used in better devices, providing good performance and lately also includes we will be talking about that wayland implementation that use better GPU power in the platform. And we are also using in this scenario the web application manager or WAM that is designed to launch web applications as standalone items, integrating the security model to have like specific permissions for using different APIs that web apps will be using to have integration with the application lifecycle, depending on the visibility and the state of running of the different web apps. And it also simplifies other extra components of the browser. The idea of putting these two pieces together was to actually fulfill some goals that were important for Igalia that was OK. Besides the already in place Qt-based ecosystem, it was important to have support for HTML applications which could we be bringing flexibility and power for more developers and many of the different collaboration profiles and have web applications becoming actual any type of first-class citizens in Igalia. This is that in the same type that other applications run natively on the system, web apps could be behaving in the same type of security performance and isolation as any other. And it was also important because it could be using any of the available standard APIs which already provide out-of-the-box functionality for many web technologies that are already in place, that provide connectivity, that provide multimedia playback, that provide many other things that are landing in vehicles of any type nowadays in any platform that wants to be production ready and wants to have all the capabilities that web standards provide. It was also important to have the freedom to use any framework from 10 libraries to ensure portability so the demo web apps have been using plain JavaScript and HTML, no any specific framework, but anyone using Node inact, React, other toolkits, Flutter, anything could be shipped into a web app and bring to assess an application into a Igalia demo platform. And then, due to those reasons, it's easy to develop, to debug, and to customize to have interoperability with other services using web sockets, as will be explained. So the specific details of the solution is based on Chromium and with the web application manager, as mentioned, that was actually, it has been created by LG, an upstreamed, was developed for WebOSOC platform, and it's a ledger on top of Chromium that was adapted to have connections with one and already provide support to many cloud native technologies. We have been also working on adapting the existing, the implementation that Igalia was developing to have for some way and supporting Chromium, that actually has recently made it to upstream desktop Chromium. So the Delta could be smaller just by adapting the existing implementation, and that actually allows to use the GPU capabilities in embedded systems as the hardware platforms that are supported by Igalia. So like more specific details on the architecture can be identified on some technical posts that I'm linking there on how, which are the details on the connections. We will be working on a few more additive versions of them, because a few things change in the connection between Chromium 1 and Igalia with a new compositor. But basically a few documentation posts are already in place there. So what's the current status? So basically there's now a way to compile HTML5 support using like the existing repositories of HTML, of AGL I mean. It's already integrated into the demo platform. There are already some web apps that replicate the behavior of the existing Qt versions. Using the same actually connections with the application framework, but they are called using WebSocket APIs instead. And also it includes a home screen, which then allows to have like an entire UI that is HTML. So both the layout, both the demo applications and all the connectivity between all of them, it's web technologies. So how this is actually done? So the gallery repositories for the sample applications are already into the gallery infrastructure. So those are the examples for the dashboard, the HVAC, the home screen, the launcher that actually brings up like the list of existing applications and allows to run them. And other examples as a very simple media player, mixer and settings application. And also the JavaScript library that is used by all of them with what will be all supported to the gallery repository. So it actually can be used as documentation for any other application that wants to use these already existing callbacks and library API calls. So in general for AGL, there's already documentation in place for anyone willing to build the distribution from the scratch and start using web apps or testing them or knowing how I'm actually a web developer or I have my own applications that are HTML, how can I have them running into AGL. So this is part of the goal of this presentation. So there's already some reference and community BSPs that can be used to build the AGL. So aside from the reference hardware, there are also the R-Cards, R2Kids or any Intel hardware platform. It can be used as NAC, as MinoBoard or Raspberry Pi, 4 actually or 3 and emulation with Kimu. So the way to build HTML, it's actually checking out the repository with the code. It can be done with the latest versions that are where HCI is fish, 903 was the latest one. Or the new Jumping Jellyfish that has been actually made it. It's also with the newest functionalities and integrations there. So any of them could be used. There's still some ongoing work on both to fix and to complete some functionalities. The examples I am showing here are using Icefish. So this is basically the way that anyone can use to download the Icefish repository. So basically in it, that actually check out that, that syncs to download the dependencies and then basically just configure it by the build and compile everything with Yocto. So it's important to use HTML to specify the AGL profile graphical HTML and in order to have the old UI showing the HTML components by default, the target that should be used with BitBake is that one, is BitBake AGL demo platform HTML5. What's actually this instruction do? So this is besides the rest of the components of the old framework. It includes recipes to build as the two parts that were mentioned that is Wam and Chromium. They were forked from the existing LG repositories that actually contain all the changes that were needed to adapt them to run on top of AGL for both repositories and details can be checked out on those repositories on the status about them and it will be renewed for a newer version of Chromium as commented on the ongoing work. So basically actually those build instructions check out the code and build it when that is compiled it's just possible to flash the image to a physical SD card or into a virtual one to run with Kimu and then just boot for the very first time. That will be showing several components so the main one will be like the HTML5 home screen web application that is basically like the layout with a container in the right view that is going to be filled up by the launcher with existing applications that are installed and by some shortcuts that can be configured directly on the HTML launcher application in this case to show like the home, the entire Chromium browser, the HVAC or the multimedia application and some status about connectivity and the status of the date and so on. So this is basically like the layout kind of application and then inside the launcher would be showing in the right part of the web of the home screen application just with the list of applications that can be triggered from there and that can be actually clicked on and we'll be calling the application framework to launch the application using this view and switch them with the rest of the icons of the launcher of the home screen application. So which are the details that are needed to know on how the web applications run on AGL. So as the same for the native Qt applications they are basically containing a few meta-information files that define which will be the application on. So we will be showing a couple of examples but basically it consists of a config.xml file that has like the unknown ID, the name and description and as well as license and a set of permissions that the application is going to require. This is actually what is going to be used with the security system to ensure that for instance a game application is not going to be able to access the API that HVAC applications for instance is going to be consuming to know the stages of the fans of the car and things like that. Then the source with any of the application resources that are going to be bundled it either local or remote for some cases is going to consume remote services but basically for any web app that is going to be bundled locally just all the code of the HTML application that can be as we were mentioning a compile and build with any toolkit or a web assembly or whatever. So this content or mentioned I just plain HTML so these contents are actually packed into a .wget file and can be installed and put available into the image like with command line or in the image with the changes on the recipe very easily. So as I was commenting any toolkit can be used or just pure or not or in-act angular or react or flutter anything else can be used to put web apps into a GL with the web application manager and the web runtime in place. So a couple examples that are available there and can be used as an example are the ones for the HTML5 home screen that has the config and XML and JSON that define like basically the structure and the elements that are going to be shown and just getting them from the repositories in this case the examples are compiled with npm install and run build and this is actually doing is creating like the widget file as was commented that can be directly copied into the image and installed with AFM utility install application widget. As the same as other applications that will be installed in slash user locally AFM applications so that's actually quite convenient because they can be like modified live either with ones they are want to be tested in the device because the rest of the development of all the UI can be done in the desktop or anything else because it's just with a browser can be tested and this can be modified remotely with the weather bugger or just physically in this direction. So a couple of very simple config xml files so it's actually a standard spec that defines it's declared by w3c that defines the structure for widget components so this is basically what I was commenting this example is something that is just basically picking a remote web service to connect to a remote independent streaming music system that's called Yamendo so what this would require is just basically defining the name of the application an icon that is going to be available in the platform like the index for the web app and then a set of permissions that is going to be required in this case it's going to be access to display and audio to be able to actually show on the screen and play multimedia content yes to also to render to render documentation to render web content I mean and those are the just basically the three permissions that is going to be to be using and then in this case the index is something very simple that is just a wrapper of the location that is going to be serving this content any other application that will be run locally would be like basically the same any game or anything that can be deployed locally and just without connectivity like the service will be running this is like a very simple example and we will be showing a couple of more complex ones something also interesting for investigating and debugging and tracking an issue is that actually it's possible to connect with a chromium browser in the desktop machine just with connectivity to the device and it's possible just to open the inspector remotely to interact with the web app and to modify any styling or use the javascript console to track any issue or anything that could be working not okay or tracking an issue it's it's very helpful in the development of web applications and testing them on the device and something interesting is that how actually the connectivity between I mean aside from the simplicity of creating the UIs using web technologies with any framework like it's very important to know how the connectivity with the internal layers of AGL is going to be done with application framework in this case and this is going through WebSockets based on the existing AFB that was done by IoT that's actually a way to wrap the calls to the application framework on which we define on top of application a javascript application binder library to centralize all the calls that are done to this application framework and how that's actually works so it basically imports the subscription and call APIs and then it actually wraps javascript methods and are exported as callbacks for apicals in this case those are examples for the development of a mixer that is actually connecting to the apical audio mixer the list controls and it's actually showing like the list of available controls and for them it's possible to send apicals to modify the volume and also to have subscriptions for a volume change or change under controls like that and then just the javascript applications can subscribe to those events that were provided by AGLJS API and it would just be as simple as that so then that would be actually behaving as a vacate to connect the UI that is done with any framework to the application framework using this binder and then this actually would be be connecting like the existing systems with actually the AGL internals that would be provided by the sensors or whatever would be getting the needed information from so this is like in the demo there's still some ongoing work to address some missing bits of this connection but everything is ongoing to have like a complete sector of functionalities for all of them so this is what the internal implementation of the WebSocket call at AFF AFB is that is basically wrapping the connection to the specific pushing like basically the message to with the right token to the context that requires the connection with the different services but yeah all the code is there the repositories and can be just checked and evolve it as for the rest of components feedback is welcome or issues are available in the different communication channels so yes ongoing work there so with all this in place we were setting a small virtual booth to show a few of these functionalities and I'm going to play a small video that is actually showing them for work we have done for automotive great learning our work provides the capability of running independent web applications in the demo platform with different levels of permission while maximizing the performance and the difficulties for the partner device this is a pure html5 UI of the AGL demo platform running on a domestic based vehicle this shows the home screen the application logic and some sample web apps that demonstrate several features of the commune-based web runtime in the vehicle UI we involved the web or the web application manager by LG to adapt it for ADL integrating it with the ADL security model application framework and the older and waving commune implementation that are down there developed the web application manager allows for iconation of different web apps so that they have their own level of permission and access to web software exploding javascript API with different services in the car for instance the HVAP application communicates with the fan system of the vehicle but other web apps without the same permission for example again will never have access to those services here we can see how the performance of a web dl screen runs smoothly this is a result of our implementation of Ozone Wayland in the commune web screen which optimizes the usage of the partner device yeah this this was a small application it that it's a pity that we are not like in person to be to have anyone being able to to test it and and to to run it live but yeah hopefully next time so basically we are still doing some ongoing work and we have some future plans so basically we have kept working on on some open tasks so basically the latest Yalifis version ships a new brand new ADL compositor that we have been integrating with the with the web runtime and one that we we want to have like a better integration with it and address some some moving parts that are there we need to finish also the update of Chromium and Web to newer versions to have like the the latest capabilities that Chromium provides and yeah as mentioned also backfixing and completion of completion of the web apps functionalities and and some constant performance and stability improvements so there's there are a few a few open issues that we are working on which which most of them can attract and can be followed at JIRA at the open automotive linux JIRA with the web app manager label and and we are always available for any communication on the different channels as Rc or or the dev calls that happen quickly and and yeah on the face-to-face meetings that unfortunately are not so face-to-face lately but we'll be we'll be getting back to normal as some point we hope so that was all so thanks to everyone and hope to see you in person next time and yep now now it's time for any any doubt and question thank you