RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
WARNING
Draft page for review and comment prior to publication.
Downloadable Application Containers (DAC) is a pan-RDK initiative to develop a container solution that allows binary applications to be downloaded and run on STBs without modification.
DAC is initially targeting RDK-V set-top boxes but the aim is to extend DAC to suitable RDK-B devices in due course. DAC is a co-operation effort between Comcast, Sky, Liberty Global, Metrological and Consult Red. The work for this is co-ordinated by RDK DAC Special interest Group (RDKDACSIG)
Used heavily in modern cloud software, containers are a standardised way to run the software in a self-contained, isolated and secure environment. Containers contain everything an application needs to run, including code, libraries and other dependencies. This means that there is no need to install specific libraries and dependencies on the host for each application. Unlike more traditional virtual machines, containers are lightweight and fast to create and destroy and don't have the overhead of virtualising an entire operating system. By sharing the OS kernel between containers, running applications inside containers adds very little performance or footprint overhead.
The most popular containerisation solution currently in use is Docker, although there are a number of other solutions such as LXC, Singularity and Podman. LXC containers have been available within RDK for a number of years, using a container generation tool at build time to define and create the container configurations.
Image source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
There are a number of advantages of using containers to run applications in RDK deployments, including:
As part of the DAC initiative, containers are used to reduce the difficulty of developing native applications that can be run on many different RDK-V devices from different operators by creating an isolated environment for each application. This means the app becomes platform agnostic and can be run on devices the develop may not have physical access to.
From the Open Container Initiative (OCI) website (https://opencontainers.org/):
The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes.
Formed in 2015 by Docker and other companies in the container industry and now part of the Linux Foundation, OCI define a number of specifications that allow developers to define containers. These specifications are followed by almost all major containerisation platforms.
OCI define both a runtime specification and an image specification. The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. The OCI image is used for packaging containers in a platform-agnostic way that can be easily distributed. At a high-level, an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
An OCI runtime is a CLI tool that allows for spawning and running containers according to the OCI specification. There are two main OCI runtimes in production use:
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 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.
For more information on Dobby, see the detailed documentation here: Dobby Documentation
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 Packager - Downloading, Installing and Launching DACs. See the Getting Started section below for an example of using these components together.
To support the STB components, backend/cloud infrastructure has been developed. These components allow operators to create application submission portals where developers can submit their applications and their corresponding metadata. These submitted applications can then be converted from an OCI image to an OCI bundle ready for use on an operators specific hardware.
The AppStore Metadata Service (ASMS) component provides APIs for both a developer and an STB to use to upload application metadata and search for previously uploaded applications. More documentation on ASMS can be found here: App Store Metadata Service (ASMS) Documentation
The BundleGen tool is a command-line tool that runs in the cloud to prepare containers for use on specific platforms. It uses template files created by an operator to ensure that the container is configured appropriately for the specific hardware requirements of an operators STB. This includes but is not limited to graphics libraries, sockets, IPC and network configuration. More detailed documentation for BundleGen can be found here: BundleGen Documentation
To develop DAC applications, an SDK has been developed that allows developers to write Bitbake recipes that compile their code and produce an OCI image. This OCI image can then be uploaded to an OCI registry where it can be converted and downloaded to a STB ready to be run by Dobby. The SDK is based on Yocto 3.1 Dunfell and does not require any RDK specific layers - instead it uses the standard Poky distribution and can run on a developer's workstation, independent of any other build systems. This decreases the amount of time it takes for a developer to build and test their application, reducing development time.
Apps build using the DAC SDK are also designed to be cross-platform, since the OCI image will contain all the necessary dependencies. Providing the platform supports the necessary DAC libraries such as Wayland, the application will run on that platform with no manual modifications.
As part of the SDK, a number of example application recipes are included such as a Wayland EGL and Qt application.
The SDK is currently in Alpha and is subject to change as development continues.
A reference image for the Raspberry Pi 3B is available for app developers that containers all the tooling necessary to install and run DAC applications. The image contains the Lightning-based RefApp, RDKServices, AAMP as well as the DAC STB components such as RDKShell, Packager, Dobby and crun.
The image uses the meta-cmf-video-reference-next layer (https://code.rdkcentral.com/r/plugins/gitiles/components/generic/rdk-oe/meta-cmf-video-reference-next), which is contains all the necessary recipes for building DAC on the Raspberry Pi.
The build script is still under construction and can be shared later. This image is based on the reference image build which is documented here: RDK reference image
A pre-built binary for the Raspberry Pi 3B from 2020-10-13 is available to download and flash from here: https://drive.google.com/file/d/1zKLtNw0jG7VMqS4xlpSJW8GihqS4i5ib/view?usp=sharing. This can then be flashed onto the SD card using Etcher (https://www.balena.io/etcher/). Make sure to resize the second partition afterwards to at least 2GB. Or else there is not enough space to download the DAC apps on the rootfs. This can be done with fdisk or gparted.
By default the image will start up with refapp2. The TS media files have been removed so you will not see emulated QAM. Also note there is currently a problem where the videoplayer layer is ON TOP of the web GUI layer. While you can start video playback of a movie, the web GUI will become hidden. It will still receive keys though. You can stop refapp2 by browsing to http://$BOXIP:9998 on your workstation and de-activate the webkitbrowser plugin there.
Once the reference image has been flashed to the Raspberry Pi, follow the below instructions to install and run a sample DAC application onto the RPi. Two sample DAC applications are available here: https://github.com/stagingrdkm/lntpub/tree/master/bundle/rpi. These applications are in the OCI bundle format and have already been prepared for the Raspberry Pi.
For instructions on how to create your own application, see below. These instructions will use the Wayland EGL test application. You may need to install wscat first on your workstation to follow these instructions. $BOX refers to the IP of the raspberry pi.
1. Download the rpi-wayland-egl-test.tar.gz file from GitHub to your workstation
2. Create a simple web server on your workstation that is accessible from the Raspberry Pi, and use it to serve the downloaded tar.gz file. https://www.npmjs.com/package/http-server is a good, simple HTTP server that could be used for this purpose
3. Install the application on the Pi using Packager. Replace the IP address with the IP of your web server:
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"Packager.1.install", "params":{ "pkgId": "mypkgid", "type": "DAC", "url": "http://192.168.1.147:8080/7218c-wayland-egl-test.tar.gz" } }'
4. Launch the application with RDKShell:
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"org.rdk.RDKShell.1.launchApplication", "params":{ "client": "test", "mimeType": "application/dac.native", "uri": "mypkgid" } }'
5. You should see a flashing green square in the corner of the display. This is the sample application.
6. Suspend and resume the application by running the following:
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"org.rdk.RDKShell.1.suspendApplication", "params":{ "client": "test" } }' wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"org.rdk.RDKShell.1.resumeApplication", "params":{ "client": "test" } }'
7. Kill the application:
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"org.rdk.RDKShell.1.kill", "params":{ "client": "test" } }'
8. Get a list of installed applications and uninstall the sample app:
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"Packager.1.getInstalled" }' wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"Packager.1.remove", "params":{ "pkgId": "mypkgid" } }'
The full list of RDKShell and Packager APIs can be found in the full documentation.
The reference image also contains a sample web app that performs the above steps. To start the test page, you can run the following command on your development PC
wscat -c ws://$BOX/jsonrpc -s notification -x '{"jsonrpc":"2.0","id":1,"method":"org.rdk.RDKShell.1.launch", "params":{ "callsign": "WebApp", "uri": "http://127.0.0.1:50050/test/index.html", "type": "WebKitBrowser"} }'
Use "TAB" to navigate the buttons and enter to click. By default it will download DAC bundles for RPI. Bundles are currently downloaded from here: https://github.com/stagingrdkm/lntpub/tree/master/bundle This test app is based on the browser example which comes with ThunderJS. The sources of the test app can be found here: https://github.com/stagingrdkm/lgpub/tree/master/dac/rdkshelldactester
Note when a DAC app is started via the test page, the underlying test page will also still receive the keys
The above example used a pre-created OCI bundle. Using the SDK it is possible to build your own applications that can be run in a container. Below are some simple instructions to build a sample app using the SDK. Refer to the SDK and BundleGen documentation for more detailed information.
TODO:: This needs completing when the full SDK and ASMS info is available. Provide steps on how to compile a simple test app, package as OCI image, and convert with BundleGen to bundle that can be run by Dobby
NOTES: