This page explains how you as AppDeveloper can create, compile your native (c/c++) application using DAC SDK and how to publish it to RDK-M staging DAC-Appstore in the cloud. 

When your application meets the DAC App contract for binary compatibility it will allow you as AppDeveloper 

  • to download, run and test that same native application on all RDK6.1 Video Accelerators without any additional integration steps
  • to exchange your Application binary package (being the AppContainer image) with RDK operators (Liberty Global, Comcast, Sky), giving them the technical capability to try out and run the app on their test boxes without additional integration.

Here is overview of DAC solution and following video made by ConsultRed at TechSummit2024 nicely explains that bigger picture dac_overview_rdk_tech_summit_2024.mp4


1. What SW, HW and credentials you need

  • Video Accelerator with final RDK6.1 image on it. This can be Raspberry Pi 4 (RPI4) on which you can flash RDK6.1 final release image.   Note that RPIv3B/3B+ is deprecated, not supported by RDK-M anymore. Tool to flash RDK6.1 rpi image to SD card, example is provided with https://www.balena.io/etcher/ tool. Contact RDK-M if you want to test it on more carrier grade Video Accelerator (with amlogic, broadcom or realtek SoC) with RDK6.1 image
  • Your application source code with bitbake recipe. Needs to meet the DAC contract for binary compatibility.
  • DAC SDK https://github.com/rdkcentral/meta-dac-sdk to cross compile your application, add dependent libraries in AppContainer and package/output your application as oci compliant dac container image.
  • As App developer company/entity you will need to request RDK-M DAC support team via support@rdkcentral.com  :
    • a login/pswd to register your app and its metadata in RDK-M ASMS instance (ASMS is AppStore Metdata µService and part of DAC cloud setup of RDK-M for Video Accelerators)
    • an associated "Maintainer" identifier (string) to be able to upload/register your app. 
    • credentials for uploading your OCI image to the private RDK OCI container registry. This is not required if you choose to upload it to a public accessible OCI container registry or ask support team to upload it for you.

Above credentials are one time request per App developer entity. Once you have above credentials, you can reuse them for publishing other apps under your entity. At this moment requesting these credentials is still manual process, a point to improve in future 

1.1. put RDK6.1 SW image on your RPI4

As an Appdeveloper you want to test and run your DAC Application on a set of real hardware reference devices. RDK-M created the Video Accelerators for that. 

If your app code complies with DAC app contract for binary compatibility it should be able to run on the various RDK Video Accelerator Devices provided these run firmware images (=monolitic software image) that also live up to that DAC contract for binary compatibility. The RDK6.1 monolithic software release live up to that contract (as of RDK6.1_RC2 Feb 2024), contains UI to browse and install DAC apps from RDK-M DAC cloud/staging store. The RPI4 is the open source community Video Accelerator that RDK-M supports.  RDK-M made available a pre-build of such rdk6.1 lib32-rdk-generic-mediaclient-wpe-image  software image for rpi so that you can just load this image on your rpi4 device and can start testing. (without having to spend any time on building such image from scratch)  This prebuilt is available in via this link https://wiki.rdkcentral.com/download/attachments/80261869/rdk-generic-mediaclient-wpe-tdk-image-raspberrypi4-64-rdk-android-mc-6.1.0.wic.bz2  See RDK6.1 rpi4 release notes wiki Raspberry Pi 4 RDK6.1 Release Notes#Downloadapre-builtimage In next section we explain how you can flash that image on rpi4.

To get your hands on other Video Accelerator HWs and their RDK6.1 SW images, we refer you to RDK-M

1.1.1. Flash the RDK6.1 image to your RPI

Download and install https://www.balena.io/etcher/ tool

  • Find and download the .wic.bz2 file from your build: find tmp/deploy/ -name *.wic.bz2
  • Flash it to the Raspberry Pi's SD card using Etcher. In principle, it can handle a wic.bz2 directly but sometimes this doesn't work great. Unzipping it first can help: bzip2 -df xxx.wic.bz2

  • Currently the image foresees 256-512 MB of available space to store DAC apps. That is enough for installing several DAC apps. You can foresee more space, by resizing the main partition of firmware image on the SD card to higher size (eg 2GB) using Gparted

  • Insert the SD card back in the RaspberryPi and power up the Pi. Connect the Raspberry Pi to your network with an ethernet cable, and to your TV with a HDMI cable.
  • Make sure you can SSH into the Pi as this is important for later. The default user is root with no password
  • You should see the RDK Video Accelerator Resident UI application on your TV at bootup (after following some initial setup questions). In section 4.1 we explain how to use the Video Accelerator Resident UI to install existing DAC apps. But first we explain how you can build and publish dac apps 

2. use DAC SDK and build your first native DAC app

As part of the DAC project, an SDK has been created to make it easier to develop and build oci and DAC compliant containerized applications. The SDK is public, fully open source and uses standard Yocto 3.1 Dunfel Poky environment.

It is available on https://github.com/rdkcentral/meta-dac-sdk

The DAC SDK consists of 

  • manifest that will download Yocto Poky environment with all required meta-layers, see manifest content in https://github.com/rdkcentral/meta-dac-sdk/blob/master/manifests/dac-dunfell-manifest.xml
  • meta-dac-sdk meta-layer specifically developed to make building of DAC application easy for Appdeveloper.
    • It defined some parent classes (dac-image-wayland, dac-image-essos, dac-image-base ) App developer can start from (inherit) to define its DAC AppContainer image as described in 
    • It links the application to DAC GFX abstraction interfaces (gles2, essos, wayland-egl) correctly and configures DAC-RDK abstraction components (eg rialto-client) appropriately.
    • It removes some integration complexity/specific expertise-need from Appdeveloper because:
      • SDK links the application to DAC abstraction interfaces (gles2, essos, wayland-egl, rialto) correctly and configures these appropriately.
      • A c/c++ application typically depends on other standard libraries, The SDK automatically adds the correct application dependency tree into the AppContainer Image
      • At the end of building process an oci compliant AppContainer image is generated. 
    • It comes with various DAC compliant AppContainer examples. see the recipes of example AppContainer images at https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images Each one is a yocto image target that you can then ask Yocto to build.  We provided some examples for various Graphics frameworks (Flutter, QT, SDL, directly on wayland, directly on essos). Those also have full opensource reference or hello-world application code provided so App developer can understand how App can use/configure Gfx framework so it will work seamlessly with DAC abstraction interfaces.
  • build instructions as per https://github.com/rdkcentral/meta-dac-sdk/blob/master/README.md 

2.1. setup of DAC SDK

build instructions as per https://github.com/rdkcentral/meta-dac-sdk/blob/master/README.md They are copies here but it is best to read the instructions there to be sure they are up to date.

This is the one time "setup" part of the SDK. 

# make sure that your Linux host has required packages needed for Yocto. 
# These are defined in https://docs.yoctoproject.org/3.1.33/ref-manual/ref-system-requirements.html#required-packages-for-the-build-host
# Create build directory
mkdir build; cd build

# Install 'repo' tool from: https://android.googlesource.com/tools/repo
# following repo commands will download Yocto poky environment and other required meta-layers see manifest of https://github.com/rdkcentral/meta-dac-sdk/blob/master/manifests/dac-dunfell-manifest.xml
repo init -u https://github.com/rdkcentral/meta-dac-sdk/ -m manifests/dac-dunfell-manifest.xml
repo sync --no-clone-bundle -v -j$(getconf _NPROCESSORS_ONLN)

. ./oe-init-build-env
cp ../.repo/manifests/manifests/bblayers.conf conf/
# to build for ARM 32bit
echo 'MACHINE = "raspberrypi4"' >> conf/local.conf

If everything worked, the SDK is now set up and ready for use. You only need to run above steps the first time you set up the SDK. For subsequent uses, you only need to run the following command to configure the build environment:

cd build
. ./oe-init-build-env

Now you can proceed with building your AppContainer image

2.2. build your AppContainer image in SDK

You ask Yocto to build specific DAC AppContainer image by invoking "bitbake <Recipename_AppContainer> "

Before making your own AppContainer image, you can try out the SDK by building one of existing example AppContainer images coming with the SDK and usually already available on RDK-M DAC cloud

# Now you can build the "DAC AppContainer image" of your choice. 
# Note that you need to have associated yocto image recipe defined in meta-layer and use that as <your yocto image target>
# as per example image recipes in https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images
# use bitbake <your yocto image target> to build the associated dac AppContainer.
# below commands build dac AppContainer examples coming with SDK
bitbake dac-image-wayland-egl-test
bitbake dac-image-wayland-egl-test-input
bitbake dac-image-essos-sample
bitbake dac-image-essos-egl
bitbake dac-image-qt-test
bitbake dac-image-shell
bitbake dac-image-flutter-slide-puzzle
bitbake dac-image-chocolate-doom
bitbake dac-image-cobalt
bitbake dac-image-glmark2

# Or build them all at once
bitbake dac-image-wayland-egl-test dac-image-wayland-egl-test-input dac-image-essos-sample dac-image-essos-egl dac-image-qt-test dac-image-shell dac-image-flutter-slide-puzzle dac-image-glmark2

Once the build has succeed you can find your AppContainer image in yocto deploy directory. You will find several files there. The files with symbolic links to files with "oci-image.tar" suffix in the name are the real oci, dobby, dac compliant AppContainer images. Those are the ones you will then need to use in next step (upload to Container registry in cloud)

# AppContainer image is located in deploy dir within yocto build dir (as any other yocto target images) 
$cd build/tmp/deploy/images/raspberrypi4/
$ls -lsa | grep oci
35612 -rw-rw-r-- 2 sverkoyen sverkoyen 36464640 Apr 10 11:14 dac-image-cobalt-raspberrypi4-20240410084211.rootfs-oci-latest-arm-linux.oci-image.tar
    4 lrwxrwxrwx 2 sverkoyen sverkoyen       86 Apr 10 11:14 dac-image-cobalt.tar -> dac-image-cobalt-raspberrypi4-20240410084211.rootfs-oci-latest-arm-linux.oci-image.tar
 9352 -rw-rw-r-- 2 sverkoyen sverkoyen  9574400 Apr 17 15:42 dac-image-glmark2-raspberrypi4-20240417134132.rootfs-oci-latest-arm-linux.oci-image.tar
    4 lrwxrwxrwx 2 sverkoyen sverkoyen       87 Apr 17 15:42 dac-image-glmark2.tar -> dac-image-glmark2-raspberrypi4-20240417134132.rootfs-oci-latest-arm-linux.oci-image.tar
# so in this example "dac-image-cobalt.tar" and "dac-image-glmark2.tar" are the oci, dobby, dac compliant AppContainer images

Below video is a demonstration on how you use the SDK to build Youtube-cobalt as DAC application  

same video is also available on Youtube 'https://www.youtube.com/watch?v=Ie7fQy5HTlc   

Next section explains how you can create your own AppContainer image

2.2.1. AppContainer image recipes, hierarchy, application recipe and appmetadata json 

To create and build your own oci, dobby, dac complaint AppContainer image as Appdeveloper, you need to create the following necessary yocto recipes and files :

  • Application BitBake recipe. applicationname.bb This recipe defines:
    • Where the application sources are located
    • How to build the application
    • directory (relative within container) where/how to install binaries of the application and its resources
    • What other components and libraries it is dependent on and need to be installed together with the application
    • Note this Application Bitbake recipe is different/ is NOT the AppContainer BitBake recipe described next
  • The oci complaint AppContainer BitBake image recipe.  dac-image-applicationname.bb This recipe defines : 
    • what pre-defined DAC container Image bbclasses it inherits, next section explains these  (you must inherit one of them), see  explained in next section and defines:
    • Which application should be installed inside the OCI Image (see IMAGE_INSTALL of Application Bitbake recipe name)
    • What is the executable binary to start inside the Container, the entry point of the Application
    • What is the associated appmetadata.json file associated with this ApplciationContainer Image
    • What additional ENV variables should be set for application
  • Associated appmetadata.json file, contains additional information and requirements for the DAC AppContainer (eg if App requires persistent storage). Currently quite loosely defined, can be improved. examples in dir https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images/metadatas

This is visualized in the diagram below

2.2.2. DAC image bbclass to inherit

To ease integration and life of Appdeveloper meta-dac-sdk layer defined several types of dac-image bbclasses 

These bbclasses automatically arrange that the necessary dependent libraries are installed in the AppContainer image and that AppContainer image is formatted according to Open Container OCI Image Format Specification.

As App developer you must inherit the appropriate dac-image bbclass in its own AppContainer image recipe. 

Following dac-image bbclasses types are defined, choose the one appropriate for your use case: 

  • dac-image-base - for DAC application that run as system service without graphics output or user input. It inherits image-oci.bbclass from yocto meta-virtualization layer
  • dac-image-wayland - for DAC application that are using OpenGL ES2 as Graphics rendering API and Wayland-egl protocol to setup EGL graphics surface and for key-input
  • dac-image-qt - for DAC application that are using QT5  framework

  • dac-image-essos - for DAC application that are using OpenGLES2 as Graphics rendering API and Firebolt ® Essos to setup EGL graphics surface and for key-input

The classes themselves have certain hierarchy. Diagram below visualizes that and has links to their source code.  

3. Publish your DAC app to RDK-M DAC cloud

Once you have built your oci, dobby, dac compliant AppContainer image with DAC SDK, you can publish it to RDK-M DAC cloud.

There are 2 separate publish steps to take for 1 application :

First Step:

Publish your oci, dobby, dac compliant AppContainer image to an oci container registry in the cloud. This is a standard cloud component that allows to upload container images (docker push), store them there persistently and download them (docker pull). This oci-registry is the binary exchange point to share your application binary with RDK-M and various RDK operators. 

Second Step:

Register your application with appropriate metadata in RDK-M DAC cloud system setup for RDK Video Accelerators either via AppStore Admin Portal or directly via ASMS REST APIs. There is microservice called ASMS (AppStore Metadata Service) that offers API that allows Application Maintainers to register their app with appropriate metadata. Once registered this will add you app to the DAC App catalog for RDK-M Video Accelerators (VA) and you will be able to discover your App in the Resident UI of all RDK6.1 Video Accelerators and as user/tester of VA you can then choose to install it on any RDK6.1 VA and once installed you can run it. In the background the RDK-M instance of the DAC cloud system will automatically fetch your oci-AppContainer image, create bundle of it for the specific Video Accelerator Hardware (SoC/OEM), encrypt (optionally) and make it available for Video Accelerator to download and store securely. 

In next sections we provide detailed howto for each step.

With step2 you will make your DAC native applciation discoverable to Video Accelerators with RDK-M RDK6.1 image but just to be clear and avoid misunderstandings, this will NOT distribute, deploy or make your app available to Appstore of the various RDK operators (Liberty Global, Comcast, Sky). For that you would need to start a discussion with each operator. But this DAC architecture gives you the big benefit that you can now share your Application binary as AppContainer in step1 and when it meets the DAC App  contract for binary compatibility it will be binary compatible and technically much easier/quick for the operator to run and test your app on their boxes for first time, get familiar with it. No significant technical integration work should be needed just to get the app running on the operator box. With the DAC cloud for the RDK-M Video Accelerator you as App developer get staging platform where you and others from RDK community can run, test your same application binary across the various supported RDK SoC reference devices (the VA's) and share it with RDK community.

3.1. How to publish the application oci container image to RDK-M oci container registry

You can either publish your oci container image to

  • the private RDK OCI container registry setup and maintained by RDK-M DAC cloud team, being "public.ecr.aws/a0v6o9z7".  You can request RDK-M DAC cloud support team (dac-info@consult.red) to upload your oci image there with version tag you specified or you can do it yourselves following the practical Instructions & tools described below. You will need credentials/account for accessing this registry, which you can request via email to dac-info@consult.red or bcatrysse@libertylgobal.com. (When there is time/money this credential creation process should be improved and autosetup as part of registering as New Application maintainer in RDK DAC cloud system or Firebolt Connect system.  
  • any of public accessible OCI container registries on the internet. The requirement is that the container registry supports OCI container format, that the container itself is uploaded & stored in the OCIcontainer image format (so not in docker format) and is public fetchable/accessible (read only, without any user/login) from RDK DAC cloud system. Note that in this approach your application binary is publicly accessible, not all application providers will agree with that and those will need to use the private RDK oci container registry approach explained above.

Depending on the oci registry product, there are various login/access credential procedures.

We provide the instructions for Amazon Elastic Container Registry. The private container registry setup RDK-M DAC team is also such type.

3.1.1. instructions for amazon Elastic Container Registry

You need to have the following util programs installed:  aws cli tools and skopeo.

//Obviously you need to fill in your credentials below iso xxxxx and yyyyy. If you want to use the private OCI container registry from RDK-M, request piotr.serafin@consult.red for credentials
[s3dacrdk]
aws_access_key_id = xxxxx
aws_secret_access_key = yyyyyy

Assuming your host is linux, configure your aws profile ~/.aws/credentials file as per below 

Login, create new container repository and publish the OCI image in there:

# login into private RDK-M OCI container registry
aws --profile s3dacrdk ecr-public get-login-password --region us-east-1 | skopeo login --username AWS --password-stdin public.ecr.aws/a0v6o9z7

# create repo for your application, in which you can publish different versions, example below creates "cobalt" one for Youtube/cobalt application
aws --profile s3dacrdk --region us-east-1 ecr-public create-repository --repository-name cobalt

# list repos
aws --profile s3dacrdk --region us-east-1 ecr-public describe-repositories

# The actual command that uploads/publishes your local version of a oci image associated with your application to the RDK-M oci-registry 
# within repo named "cobalt" with the version tag "latest" standing for latest version
skopeo copy oci-archive:dac-image-cobalt.tar docker://public.ecr.aws/a0v6o9z7/cobalt:latest

# with following command you can download your oci image from RDK-M registry to your local host
skopeo copy docker://public.ecr.aws/a0v6o9z7/cobalt:latest oci:cobalttest

# command to double check if uploaded container is oci image type
skopeo inspect --raw docker://public.ecr.aws/a0v6o9z7/cobalt:latest
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 548,
    "digest": "sha256:0bc2f756fc781b015769230b207c6b227b788023a5c3d599504407cc1619110e"
  },
[...]
}

You have to remember the OCI image URL of your application, which in this example is docker://public.ecr.aws/a0v6o9z7/cobalt:latest. Because you will have to specify it when publishing the DAC app to the ASMS (AppStore Metdata service).

3.2. Publish your DAC app to ASMS

Keep in mind that  DAC Backend is licensed under DAC Warehouse Service End-User Evaluation License Agreement. and by accessing or using the service, user accepts on Terms of Use.

ASMS (AppStore Metadata Service) offers API that allows Application Maintainers to register their app with appropriate metadata. There are various ways to publish a new application to ASMS in DAC Cloud:

  1. use the official AppStore Admin Portal (please contact dac-info@consult.red for credentials)
  2. use the official ASMS REST API to publish the app, is openAPI / swagger API format which we describe in next section (please contact dac-info@consult.red for credentials)
  3. using the dactest.py python test tool that in its turn uses the ASMS api

3.2.1. URLs


All above require credentials please contact dac-info@consult.red for assistance.

Please use following template if possible:

Subject: Request for Credentials - DAC AppStore Services Access

Dear DAC AppStore Support Team,

I am writing to request credentials for accessing the following DAC AppStore Services:

  1. AppStore Metadata Service REST API
    URL: https://asms.rdkm.consult-red.net
    Swagger UI: https://asms.rdkm.consult-red.net/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config

  2. AppStore Admin Portal
    URL: https://ui.rdkm.consult-red.net/login

Please find my details below for authentication purposes:

  • Full Name: [Your Full Name]
  • Company: [Your Company Name]
  • Email Address: [Your Email Address]

I would appreciate it if you could provide the necessary credentials at your earliest convenience. If any further information is required, please do not hesitate to contact me.

Thank you for your assistance.

3.2.2.  Register App using AppStore Admin portal

3.2.2.1. AppStore Admin Portal Overview

The AppStore Admin Portal is a user-friendly, intuitive management interface designed by Consult Red for efficient control and administration of your applications and platform configurations. This portal empowers administrators with robust tools to streamline various processes, ensuring smooth operations and optimal performance.

Key features of the AppStore Admin Portal include:

  1. Application Management (DAC Applications):

    • Onboarding: Seamlessly onboard new DAC applications into the platform.
    • Updates: Efficiently manage and deploy updates to existing DAC applications.
    • Offboarding: Safely remove applications that are no longer needed.

  2. Platform Configuration Management:

    • Onboarding: Easily integrate new platform configurations for enhanced flexibility and control.
    • Updates: Apply updates to existing platform configurations to maintain compatibility and performance.
    • Offboarding: Decommission outdated or unnecessary configurations in a secure and organized manner.

  3. Platform Bundles:

    • List Bundles: View a comprehensive list of available platform bundles.
    • Pre-generate Bundles: Pre-generate platform bundles for faster deployment and management.

The AppStore Admin Portal is designed to simplify complex administrative tasks, enabling users to efficiently manage and optimize their platform and application landscape.


Access to the Admin Portal requires credentials (contact dac-info@consult.red) and acceptance of Terms of Use during first login.

3.2.2.2. register app using AppStore Admin Portal

using WebUI of admin portal, click on specific maintainer (eg "RDK" maintainer)

then click on green "Add" button in upper right corner to add an app. You will get following UI to enter in your application metadata

 


3.2.3. Register App using ASMS REST API

Keep in mind that  DAC Backend is licensed under DAC Warehouse Service End-User Evaluation License Agreement. and by accessing or using the service, user accepts on Terms of Use.

You can access the swagger UI with the API documentation here:

see screenshot

As you can see in screenshot the ASMS API is divided in "STB" en "Maintainer" part. 

The "Maintainer" part is there for creating, getting, deleting apps belonging to specific App Developer entity/company, hereafter called maintainer, as well as for creating/listing Maintainers.

At this moment we don't have many different App Developer entities using this yet since and most apps created so far as registered under the Maintainer with "rdk" as maintainerCode (also dactest.py uses that)

as per API, to see the apps created by "rdk" maintainer GET /maintainers/rdk/apps which is  https://asms.rdkm.consult-red.net/maintainers/rdk/apps

To insert/create new DAC application into ASMS, you need to use POST /maintainers/{maintainerCode}/apps call with specific body

You can use swagger UI with example body for doing this, see https://asms.rdkm.consult-red.net/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/Maintainer/createMaintainerApplication

and screenshot below

example POST body with only the minimum required parameters

As ociImageUrl, use full path to container registry with "docker://" transport and ending with version tag, as in example screenshot below

{
  "header": {
    "icon": "https://posterserver.com/s/apps/com.company.app.awesome/1.2.3/image/1920x1080/icon.png",
    "name": "Awesome Application",
    "description": "This is Awesome App",
    "type": "application/dac.native",
    "category": "application",
    "id": "com.company.app.awesome",
    "version": "1.2.3",
    "visible": true,
    "ociImageUrl": "docker://public.ecr.aws/a0v6o9z7/company/awesome:latest" 
  },
  "requirements": {
    "platform": {
      "architecture": "arm",
      "os": "linux"
    },
  }

another example POST body that includes optional metadata parameters,  Additionally you can check how dactest.py is doing it.

{
  "header": {
    "icon": "https://280222515084-default-apps-resources.s3.eu-central-1.amazonaws.com/images/apps/com.rdk.app.chocolate-doom.png",
    "name": "Chocolate Doom",
    "description": "Chocolate Doom aims to accurately reproduce the original DOS version of Doom and other games based on the Doom engine in a form that can be run on modern computers.",
    "type": "application/dac.native",
    "size": 10000000,
    "category": "application",
    "localization": [
      {
        "languageCode": "nld",
        "name": "Geweldige applicatie",
        "description": "Dit is een geweldige applicatie"
      }
    ],
    "id": "com.rdk.app.chocolate-doom",
    "version": "1.0.0",
    "visible": true,
    "encryption": false,
    "preferred": false,
    "ociImageUrl": "docker://public.ecr.aws/a0v6o9z7/chocolate-doom:latest"
  },
  "requirements": {
    "dependencies": [
      {
        "id": "com.libertyglobal.service.voice",
        "version": "1.0.0"
      }
    ],
    "platform": {
      "architecture": "arm",
      "variant": "v7",
      "os": "linux"
    },
    "hardware": {
      "ram": "512M",
      "dmips": "2000",
      "persistent": "60M",
      "cache": "200M"
    },
    "features": [
      {
        "name": "rdk.api.awc",
        "version": "2",
        "required": false
      }
    ]
  },
  "maintainer": {
    "code": "rdk",
    "name": "RDK",
    "address": "RDK Management, LLC",
    "homepage": "https://rdkcentral.com",
    "email": "support@rdkcentral.com"
  },
  "versions": [
    {
      "version": "1.0.0",
      "visible": true,
      "preferred": false,
      "encryption": false
    }
  ]
}

3.2.4. Publish the DAC app using dactest.py tool

Keep in mind that  DAC Backend is licensed under DAC Warehouse Service End-User Evaluation License Agreement. and by accessing or using the service, user accepts on Terms of Use.

Among other things, dactest.py can be used list ASMS apps, add entries and remove entries. 

To add an entry to ASMS, i.e. to publish a DAC app you can follow these steps:

  1. on your development PC/laptop: install dactest.py dependencies. You need python3 and then pip3 install requests colorama websocket-client
  2. use ./dactest.py 192.168.0.117 (replace IP address with your RPI IP)
  3. it will use the RDK ASMS to list apps available from the cloud. Use "A" to start the procedure to add an app to ASMS
  4. you will need to provide an id, name, version, the OCI image URL (see previous step) and a link to an icon to use. When prompted for "encryption" input "false". Unless you really want to test encrypted DAC apps. But for this feature there is a separate wiki page to read. Extra steps are needed for encryption. You can skip that for now and don't use encryption.


3.2.5. List all apps with ASMS API

Swagger API for it see http://rdkm-asms-external-1156877020.eu-central-1.elb.amazonaws.com:8080/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/STB/listApplications

concrete call on running instance :

see screenshot

3.2.6.  Get DAC bundle URL for specific App via ASMS api

The STB needs to know the location where to download the DAC bundle created by DAC cloud system for a specific app & appversion and for its platform. This section describes the API call to do this.

Remember as per architecture description, the RDK-M instance of the DAC cloud system is responsible for creating appropriate DAC bundle out of oci-image for a specific app & version and make it available for Video Accelerator to download and store securely on certain location URL. That bundle is also specific for certain Video Accelerator Hardware (SoC/OEM) platform, can be encrypted or not (is optional) and is specific for range of firmware versions on that platform, represented by a ID which we call "dacBundleFirmwareCompatibilityKey". See more information on latter here.

So for ASMS to provide right location of a bundle, it needs to get from the requester (STB) the following:

  • the applicationID and app_version : for which application are you requesting a bundle?  And for which version of that application. example for version "1.0.0" of appId "com.rdk.app.flutter-slide-puzzle" is represented by string "com.rdk.app.flutter-slide-puzzle:1.0.0"   If you don't provide version, then default "latest" version is assumed
  • the platformName of the STB as defined in ASMS:  because bundles are specific to specific modeltype. Each CPE modeltype registered in DAC cloud system has a template for autogenerating the appropriate oci run config. The RDK-VA modeltype specific templates are available in https://github.com/stagingrdkm/lgpub/tree/master/dac/templates/oe_3.1 You can find platformName of STB in filename of files listed here example is "7218c". That platformName is also retrievable via LISA (defined in lisa config see  https://code.rdkcentral.com/r/plugins/gitiles/components/generic/rdk-oe/meta-cmf-video/+/refs/heads/rdk-next/recipes-extended/rdkservices/rdkservice-lisa-dac-config.inc  more info see LISA#lisa.dac.confg )
  • dacBundleFirmwareCompatibilityKey:  this is unique ID that represents a set of firmware versions of specific platform for which the same App bundle is binary compatible with, meaning, for which same binary is guaranteed to keep on working (i. example for 7218c platform this is the "1.0.0-41abf2fba994b2d04baedeca6d5adf097ece9f79" part of of  "7218c_1.0.0-41abf2fba994b2d04baedeca6d5adf097ece9f79-dbg_dac_configs.tgz" file you see here . You can also retrieve current applicable "dacBundleFirmwareCompatibilityKey" of the STB from LISA when configured correctly in here 

so all together above example becomes request with following input parameters 

  • applicationID: com.rdk.app.flutter-slide-puzzle:1.0.0
  • Platform name:  7218c
  • Firmware version, it's not really the firmware version it is the "dacBundleFirmwareCompatibilityKey" you need enter: 1.0.0-41abf2fba994b2d04baedeca6d5adf097ece9f79-dbg 

So when enter those in tryout in swagger API

http://rdkm-asms-external-1156877020.eu-central-1.elb.amazonaws.com:8080/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/STB/getApplicationDetails

you get following output/screenshot of with above example values


You can also retrieve directly using following pattern

http://rdkm-asms-external-1156877020.eu-central-1.elb.amazonaws.com:8080/apps/com.rdk.app.flutter-slide-puzzle%3A1.0.0?platformName=7218c&firmwareVer=1.0.0-41abf2fba994b2d04baedeca6d5adf097ece9f79-dbg

The resulting output of above request is all metadata details for that specific app_id and under "url" field is the location of the appropriate bundle. see red circle in screenshot below

4. Install and run your DAC app on the Video Accelerator

We explain here 2 ways to download your DAC application from Staging RDK-M DAC Appstore and install it on the video Accelerator :

  1. via the Resident UI on RDK-Video Accelerator (is the regular, user-friendly way)  
  2. using the dactest.py test tool  

4.1. install and run DAC app using RDK-VA Resident UI

In the resident UI go to the icon with the 9 small squares (left bottom) to navigate to the DAC menu. There you will see three submenu items:

  1. My Apps: initially empty. From here you can start installed DAC apps. Use the "Home" key to exit a DAC app.
  2. App Catalog: these are the DAC apps from ASMS available for installation. If you published your app to ASMS you should see it here.
  3. Manage Apps: here you can uninstall DAC apps from your RPI

4.2. Using dactest.py tool

dactest.py can be used list, install, uninstall, start and stop DAC apps. It also connects to RDK ASMS to list available DAC apps in the cloud. The DAC apps downloaded from the cloud are generated to bundles inside that cloud and cached there. Sometimes the download can take a while if the bundle still needs to be generated for a specific platform and/or version.

So how to use dactest.py to install an app from ASMS:

  1. on your development PC/laptop: install dactest.py dependencies. You need python3 and then pip3 install requests colorama websocket-client
  2. by default the script is configured properly for RPI3. But for RPI4 you have to edit the script and set DEFAULT_ASMS_PLATFORM_RDK="rpi4" and DEFAULT_ASMS_FIRMWARE_RDK="1.0.0-e71889dc02521bfdc2f9f38f750b34224184c375-dbg". New: since recently dactest.py will fetch this configuration from LISA itself and use it. No need to edit these anymore.
  3. use ./dactest.py 192.168.0.117 (replace with your RPI IP)
  4. it will use the RDK ASMS to list apps available from the cloud. Use "Ix" where x is the number/index of the app you want to install. Later you can use "Ux" to remove it again.
  5. after successful installation you can start the app using "Sx" and stop it using "Tx". 

If you're interested to see what HTTP commands are sent to ASMS and what websocket commands are sent to LISA and RDKShell to support this demo then check the contents of dactest.py.

  • No labels

DISCLAIMER: Please note that the use of the RDK Wiki is subject to its Privacy Policy & Terms of Use. In addition, this Wiki may be accessed by all RDK licensees and their contractors.