Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Downloadable Application Containers (DAC) is an RDK initiative and cooperation effort between Comcast, Sky, Liberty Global, RDK-M and Consult Red. The work for this is co-ordinated by RDK DAC Special Interest Group (RDKDACSIG)

The DAC end goal is to provide a solution that allows app developers to write and package also native (c/c++) Applications in a way that makes the application binary exchangeable and can be run across all RDK boxes without (compile time) modifications.

...

draw.io Diagram
bordertrue
diagramNameE2EArchitecture
simpleViewerfalse
width960
linksauto
tbstyletop
diagramDisplayName
lboxtrue
diagramWidth1166
revision2122

3 functional area's are further discussed in sections below

...

  • The application must be made discoverable in some form of appcatalog available to those target devices. System is needed that allows you to register, add applications with appropriate metadata to that AppCatalog but also allows the consuming devices to browse that appcatalog and have all the information needed to securely install particular application and once installed be able to run it. For that the Appstore Metadata µService (ASMS) has been created. It provides restful API (swagger/open API).  See more information in following wiki page on how to use the ASMS API   
  • The Appcontainer in the OCI image format needs to be transformed to so called "bundle" format to be able to load/run it on real host. Such bundle consists out of the final filesystem of the container (is result of possibly more than one file system layers specified in OCI image format spec) and a "run" time "config.json" so it can be run on a host with OCI runtime like crun. One can also say that bundle is Container rootfs + run config.json" 
    See the oci runtime specification for bundle term definition and run time "config.json" parameters.
    The "run" config.json is the Container configuration. It is the responsibility of the distributor/operator, not the application provider to configure this.
    The operator will for example configure/constrain Linux capabilities of the container for security reasons. The "run" config also contains few platform specific bind mounts (STB model, can be firmware specific) from host rootfs to AppContainer rootfs (like bind mount of SoC specific Graphics libraries that implement libGLESv2 & libEGL) as well as bind mounts of few unix domain sockets (socket of waylandserver & rialtoserver instance) required to interface with the defined abstraction layers for Graphics and Audio/Video/DRM. The run "config.json" takes some parameters from oci image config that are needed in run config (such as launch point/path of the application within the container)

...