RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
...
That is what the reference DAC cloud system is doing. Once bundle for particular app_id/platform/compatible version is created, it will be available in cache of ASCS (Appstore Caching service) (which can serve as the origin for further caching on a CDN). If you request bundle for particular app_id/platform/compatibleversion towards ASCS and if it is not available in its cache it will automatically trigger real time creation of associated bundle in a flow managed by ASBS (appstore bundle service). ASBS will fetch appropriate metadata from ASMS and give instructions with right input parameters to respectively bundle-generator-service and bundle-cryptor-service via RabbitMQ to generate and secure the bundle and cache on ASCS.
DAC provides all the necessary tooling to run containerised applications using OCI containers on an RDK-V STB. The main component of this is Dobby, an embedded-focused OCI container manager. Dobby is used to start, stop and monitor containers running on a STB, using the crun runtime underneath to interface with the kernel and start the containers. Dobby is The core components in any RDK software image to run the Appscontainer on CPE are "Dobby" and "crun". Dobby is OCI Container manager aka container engine comparable to known desktop container engines dockerd and podman but then focused on embedded device, written in C++ and designed to have minimal footprint and performance impact. The OCIContainer Thunder plugin allows for interfacing with Dobby using a JSON-RPC interface, and Dobby can also be used to run other Thunder plugins in containers using the ProcessContainer backend.
Crun is an opensource container runtime alternative to "runc" equivalent but written in C, has smaller footprint but is also well supported by the industry (is for example default container runtime used by podman)
Dobby exposes API and is used to start, stop and monitor containers running on a STB, using the crun runtime underneath to interface with the kernel and start the containers.
When requested to start a new container, crun will process the associated container configuration (run config.json) and apply the associated container policies/settings.
The OCIContainer Thunder plugin allows for interfacing with Dobby using a JSON-RPC interface, and Dobby can also be used to run other Thunder plugins in containers using the Dobby ProcessContainer backend.
Before being able to run the Appcontainer successfully on RDK CPE, other pieces are needed as well.
Some pieces may be operator specific such as obviously the UI to discover, store, run the apps but also not all operators will be using RDKshell as Appmanager and some will use alternative to LISA for installation of apps. Also some may have system to distribute, store the apps onto the device without UI/user involved.
Operator device software must meet contract for binary compatibilty. That means following firebolt native abtraction interfaces need to be in place: Rialto for audio, video & DRM and libGLESv2.so.2, libEGL.so.1, libwayland-egl.so.1 and libessos.so for Graphics. JSON-RPC Server (such as ripple) that supports current and upcoming Firebolt api version (currently version 1.0 but we are working on and aim at 2.0) must be in place and pass certification.
In the RDK-M reference environment which are the RDK Video Accelerators with the RDK6.1 software, the Video Accelerator Resident App is used as UI to browse and install apps from the Appcatalog offered by ASMS in the DAC cloud instance setup for VA's.
That UI code interfaces with LISA to get list of all installed apps at boot and obviously to install or uninstall specific app.
For installation of an specific App, UI will request appropriate bundle_url for this particular app_id/app_version/HWplatform/compatibleFWversion combination to the DAC cloud and pass this bundle_url to LISA with request for install. LISA will do download of that bundle_url (https pointing to bundle tarball on ASCS in DAC cloud). ASCS or CDN in front will return that tarbal with HTTP 200 OK when it is available in cache. In case that bundle is not available in the cache yet (is the case when the bundle for that combination was not already pre generated or requested by 1 other stb), the ASCS will trigger ASBS in DAC cloud to automatically create the bundle for that combination on the fly (near Just in Time, eg 1-5 seconds) and populate in the ASCS for download by LISA. In such "not in cache" case ASBS will return 202 iso 200 to LISA to indicate the delay and few seconds of patience. LISA has built in, tunable by config, retry mechanism in case of such 202.
When successfully downloading the tarball LISA will unpack it in the appropriate directory locations it created for it, also create separate persistent storage location for that app and add the app_id / version to its local database.
For more information on LISA we refer to https://wiki.rdkcentral.com/display/ASP/LISA
When the user wants to run one of the installed apps, the UI interfaces with RDKshell as the Appmanager, requesting it to start this app of type dac.native with as input the path to the unpacked bundle created by LISA.
RDKshell will create westeros wayland server instance/display socket for the app, based on metadata create RialtoServer instance for the app or not and further delegate startContainer(bundle_path, westerosSocket) to OCIContainer thunder plugin which will in case of signed/encrypted container trigger the OMI component to verify signature and decrypt config.jwt in the crypted bundle and decrypt, verify and mount the rootfs of the Appcontainer rootfs using dm-verity & dm-crypt so it is ready to be consumed. Then the startContainer request is further delegated to Dobby which uses crun to execute it.
They will setup the container according to the associated run config.json. Associated bind mount from STB host rootfs to Appcontainer rootfs of appropriate wayland and rialto server socket will occur, as well as bind mounts of SoC specific Gfx library tree which provide libGLESv2.so.2 and libEGL.so.
When the dac.native app is a firebolt App, the specific Firebolt connection url for to use, will be passed (through chain of RDKshell, OCI Container, dobby/crun) and become available to the App as environment variable inside the AppContainer.
-----
For more information on Dobby, see the detailed documentation here: Dobby
As part of DAC, the RDKShell plugin has been extended to allow starting DAC apps using Dobby, creating a display and attaching it to the containerised app as necessary. RDKShell also integrates with the Packager plugin to provide a full-featured solution for downloading, installing and lifecycle management of DAC apps. For more documentation on the RDKShell and Packager integration see RDKShell and LISA/Packager. See the Getting Started section below for an example of using these components together.
...