Page History

...

The RDK Video Accelerators running their RDK6.1 software image are the reference environment for RDK. They use the components as shown in the reference architecture diagram (VideoAccelerator UI, RDKshell with RialtoServermanager support, LISA, OCIcontainer rdkservice, OMI, ripple, westeros, dobby, crun. The Video Accelerator Resident App includes basic UI for working with DACapps. That UI allows you to browse and install DAC apps from the Appcatalog offered by ASMS in the DAC cloud instance setup for VA's. For demo video and more information on how to use that UI see video1 and video2.

That VA UI code uses LISA API to get list of all installed apps at boot and obviously API to install or uninstall specific app.
For installation of an a specific App, UI will request appropriate to ASMS the bundle_url for this particular app_id/app_version/HWplatform/compatibleFWversion combination to the DAC cloud and pass this bundle_url to LISA along with install request for install. LISA will do download of that bundle_url (https pointing to bundle tarball on That URL will be https url pointing towards ASCS in DAC cloud with path towards actual (signed/encrypted) bundle tarball there. LISA will do the HTTPS request for that bundle tarbal. Usually that bundle tarbal will be there in cache of ASCS or CDN in front will return that tarbal and be returned with HTTP 200 OK when it is available in cache. In case that bundle is not available in the cache yet (is the case when the bundle for that combination was not already pre generated or requested by 1 other stb), the ASCS will trigger ASBS in DAC cloud to automatically create the bundle for that combination on the fly (near Just in Time, eg 1-5 seconds) and populate in the ASCS for download by LISA. In such "not in cache" case ASBS will return 202 iso 200 to LISA to indicate the delay and few seconds of patience. LISA has built in, tunable by config, retry mechanism in case of such 202.
When successfully downloading the tarball LISA will unpack it in the appropriate directory locations it created for it, also create separate persistent storage location for that app and add the app_id / version to its local database.
For more information on LISA we refer to https://wiki.rdkcentral.com/display/ASP/LISA
When the user wants to run one of the installed apps, the UI interfaces with RDKshell as the Appmanager, requesting it to start this app of type dac.native with as input the path to the unpacked bundle created by LISA.
RDKshell will create westeros wayland server instance/display socket for the app, based on metadata create RialtoServer instance for the app or not and further delegate startContainer(bundle_path, westerosSocket) to OCIContainer thunder plugin which will in case of signed/encrypted container trigger the OMI component to verify signature and decrypt config.jwt in the crypted bundle and decrypt, verify and mount the rootfs of the Appcontainer rootfs using dm-verity & dm-crypt so it is ready to be consumed. Then the startContainer request is further delegated to Dobby which uses crun to execute it.
They will setup the container according to the associated run config.json. Associated bind mount from STB host rootfs to Appcontainer rootfs of appropriate wayland and rialto server socket will occur, as well as bind mounts of SoC specific Gfx library tree which provide libGLESv2.so.2 and libEGL.so. 
When the dac.native app is a firebolt App, the specific Firebolt connection url for to use, will be passed (through chain of RDKshell, OCI Container, dobby/crun) and become available to the App as environment variable inside the AppContainer.

...