Page History

...

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)

cd tmp/deploy/images/raspberrypi4/

 
# Note that you need to have associated yocto AppContainer image recipeis definedlocated in meta-layerdeploy anddir use that as <your within yocto imagebuild target>
#dir (as any perother exampleyocto imagetarget recipesimages) in
$cd https:build/tmp/github.comdeploy/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
bitbakeimages/raspberrypi4/
$ls -lsa | grep oci
35612 -rw-rw-r-- 2 sverkoyen sverkoyen 36464640 Apr 10 11:14 dac-image-waylandcobalt-egl-test
bitbake dac-image-wayland-egl-test-input
bitbakeraspberrypi4-20240410084211.rootfs-oci-latest-arm-linux.oci-image.tar
    4 lrwxrwxrwx 2 sverkoyen sverkoyen       86 Apr 10 11:14 dac-image-essos-sample
bitbakecobalt.tar -> dac-image-cobalt-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
bitbakeraspberrypi4-20240410084211.rootfs-oci-latest-arm-linux.oci-image.tar
 9352 -rw-rw-r-- 2 sverkoyen sverkoyen  9574400 Apr 17 15:42 dac-image-waylandglmark2-egl-test dac-image-wayland-egl-test-input dac-image-essos-sampleraspberrypi4-20240417134132.rootfs-oci-latest-arm-linux.oci-image.tar
    4 lrwxrwxrwx 2 sverkoyen sverkoyen       87 Apr 17 15:42 dac-image-essos-eglglmark2.tar -> dac-image-qtglmark2-test dac-image-shell dac-image-flutter-slide-puzzle dac-image-glmark2raspberrypi4-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  

...

Next section explains how you can create your own AppContainer image

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

...

DAC image bbclass to inherit

To ease integration and life of Appdeveloper (remove some integration complexity/expertise) meta-dac-sdk layer defined several DAC image bbclasses App developer can inherit and use as starting point for its own AppContainer image. 

Several types/bbclasses are defined. The application developer must choose the one appropriate for its envisaged use case and must inherit one in its AppContainer recipe

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: Following oci, dobby, dac 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 their links and hierarchy of inheritance visualized in diagram below  The classes themselves have certain hierarchy. Diagram below visualizes that and has links to their source code.  

...

• step1 is to 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. 
• 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-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. 

Just to be clear and to avoid misunderstandings, with

...

step2 you will make your app discoverable to RDK6.1-Video Accelerators, this will not distribute/deploy/make your app visible to Appstore of the various RDK operators. For that you would need to talk to the specific operator but the fact that you uploaded it 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 

...