...

What you 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 application container 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.

...

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

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

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

...

Following oci compliant base image types are defined with SDK and you can inherit/extend :

• 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

See below their links and hierarchy of inheritance  inheritance visualized in diagram below  

Provided OCI Images are used as a base classes for specialized DAC Application OCI Images.

...

To create new oci, dobby, dac compliant Application Container image, you have to define as developer:

• Application BitBake recipe. This recipe define:
  
  • Where the application sources are located
  • How to build the application
  • directory 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

• The oci complaint ApplicationContainer BitBake recipe. This recipe inherit one of pre-defined DAC container Image classes and defines:
  
  • Which application should be installed inside the OCI Image (see IMAGE_INSTALL of Application Bitbake recipe name)
  • What is an the executable binary to start inside the Container, the entry point of the Application
  • What is 
  • What additional ENV variables should be set for application
• Associated appmetadata.json, contains additional information and requirements for the DAC Application Container (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 visualised in the diagram below

Publish your DAC app to RDK-M DAC cloud

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

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

• step1 is to publish your oci, dobby, dac compliant ApplicationContainer 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. 
• step2 : register your application with appropriate metadata in RDK-M DAC cloud system setup for RDK Video Accelerators. 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-ApplicationContainer 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. 

• Just to be clear and to avoid misunderstandings, with this step you will make your app discoverable to RDK6.1-Video Accelerators, this will not distribute/deploy/make your app visible to Appstore the various RDK operators. It is intended as staging place where community can see and experience your application  step will not install it 
• The RDK-M DAC cloud will pick 

publish steps to separate steps to ma  publish steps in there :

 as this 

There are 2 big publish

To create new OCI Image with application, developer had to define:

• Application BitBake recipe. This recipe define:
  
  • Where the application sources are located
  • What other components and libraries are used during application build process
  • How to build the application
  • How to install the application and its resources
  • What other components and libraries need to be installed together with the application

• Specialized OCI Image BitBake recipe. This recipe inherit one of pre-defined DAC Image recipes and define:
  
  • Which application should be installed inside the OCI Image
  • What is an entry point (executable binary) inside Container
  • What additional ENV variables should be set for application

Publish your DAC app to RDK-M DAC cloud

There are two ways to publish a new application in ASMS:

...

• 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 (who TBD, ad interim Piotr S or Stefan V or BartC ) 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 piotr.serafin@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. Requirement is that the container registry supports OCI container format, that the container itselve 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.

...

# 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"
  },
[...]
}

Obviously, you 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).

...