Page History
Key Updates from RDK7 to RDK8
| Markdown |
|---|
RDK8 introduces several significant architectural improvements: - **Application Layer Restructuring**: Traditional application layer removed; applications delivered as BOLT/RALF packages with runtime download and installation capability - **RDKShell to RDK App Manager**: Enhanced container lifecycle management with better resource control, isolation, and OCI-compliant containerization using Dobby - **LISA to PackageManager**: Modern package management with multi-layer container images and on-device bundle generation (DAC 2.0) - **App Gateway**: Lifecycle management 2.0 with enhanced application orchestration and centralized lifecycle control - **Window Manager**: Standardized input event handling and key routing management - **Reference UI**: Modern user interface delivered as RALF package with update capability through SceneSet - **Media Framework**: Rialto with standardized media playback interface |
Architecture
A quick architecture overview of RDK8 to help associate the capabilities with the software stack is given below.
draw.io Diagram border true diagramName rdk8_detailed_architecture simpleViewer false width links auto tbstyle top lbox true diagramWidth 850 height 419 revision 13
| Markdown |
|---|
The architecture consists of three main layers: **Applications & Runtime** (supporting components for DAC and application management), **RDK Core Middleware Layer** (core functionality and orchestration), and **Vendor Layer** (hardware-specific implementations). Applications & Runtime connects to the Middleware Layer, which connects to the Vendor Layer, creating a clear separation of concerns with independent development and update cycles. |
Vendor Layer
The objective of the vendor layer is to minimize the amount of code required per hardware platform, thereby reducing development time to support scalability. All vendor layer implementations must be fully compliant with the HAL specification to ensure compatibility with a common middleware build and provide standardized interfaces to the middleware layer, abstracting hardware differences.
The vendor layer contains hardware-specific drivers, BSPs, and platform-specific adaptations. Responsibility for build systems, updates, and security identification related to deliverables lies with the vendor implementer. To support management and cross-layer compatibility, a minimal subset of component implementations is specified, such as the Linux Kernel version, core libraries, and patches.
Reference open-source software is provided to enable reuse of common components; however, usage of these components is not mandatory for the vendor implementer. Manufacturing and serialization requirements and processes are defined in the Entertainment OS device specifications and must be followed accordingly. The vendor layer can be updated independently without affecting other layers.
Middleware Layer
| Markdown |
|---|
The middleware layer aims to provide a single, consistent implementation of core Entertainment device functionality. Middleware components are expected to utilize the Thunder framework to implement functionality in a standardized manner with unified orchestration, providing standardized APIs for applications to access device capabilities. The middleware layer includes **Thunder Framework** for core orchestration and plugin infrastructure, **ENT Services** for entertainment-specific services, and **RDK App Manager**, which is a collection of Thunder plugins responsible for the complete lifecycle of containerized applications. RDK App Managers download applications from servers, store them on device, launch them in isolated Linux containers, and manage their lifecycle and resources. Every application runs inside an OCI-compliant Linux container managed by Dobby (the RDK container runtime). The App Managers control container contents, start/stop behavior, hardware resource usage, and system communication. The layer also includes **Media Framework** (Rialto, community media playback framework that replaces AAMP), **DRM Systems** for digital rights management implementations, **App Gateway** for lifecycle management 2.0 and application orchestration, and **Device Management** for platform configuration and control. Middleware components are developed separately and delivered as binary packages (IPK), though all components should be delivered in source code unless agreed as an exception. The middleware layer owner holds responsibility for the quality of all components within the layer, including open-source and community contributions. The middleware is designed to have the most simple, robust and co-operative implementation of the core functionality while enabling rapid innovation through common tooling and patterns. Reference open-source software is provided to allow re-use of common components, but the middleware is not obligated to use any of these components. |
Applications & Runtime
| Markdown |
|---|
In RDK8, the traditional Application Layer has been removed entirely, all applications and their runtimes are delivered as BOLT packages — platform-agnostic, OCI-artifact-based packages that are fully decoupled from the firmware image. Applications are organized into three logical BOLT package types: - Base – Core dependencies required for application execution - Runtime – Shared runtimes consumed by one or more applications - App – The actual application packages (e.g., Reference UI, YouTube) The primary runtime packages are WPE WebKit and Libcobalt, both now shipped as Runtime BOLT packages rather than being embedded in the middleware layer. These runtimes are consumed by application [BOLT packages](https://wiki.rdkcentral.com/spaces/RDK/pages/467661055/Bolt+applications) such as Reference UI, YouTube, YouTube Kids, and other HTML5/Lightning/web-based applications. Each component — base, runtime, and app — can be upgraded independently without rebuilding or reflashing the firmware. Applications can be downloaded at runtime, sideloaded, or preloaded at the image assembler stage and installed at first boot. To support an out-of-box user experience, RDK8 introduces the concept of [Factory Apps](https://wiki.rdkcentral.com/spaces/RDK/pages/474687726/Factory+Apps+on+RDK8), which bundle the Reference UI (App package), WPE WebKit (Runtime package), and Base packages together. These are preloaded on the device, installed automatically during initial boot, and available immediately after first boot. SceneSet is the default factory app that handles system UI lifecycle and installation. It launches at device startup, checks for factory apps availability, copies them to the preinstall folder if needed, triggers PreInstall Manager to install packages, starts the default application (e.g., RefUI), and monitors for application updates. [DAC 2.0](https://wiki.rdkcentral.com/spaces/RDK/pages/466481813/DAC+2.0+architecture+in+RDK8) provides a solution for platform-agnostic, binary-exchangeable native applications that can run across all RDK boxes without compile-time modifications. DAC 2.0 introduces multi-layer support with Base layer (core system dependencies), Runtime layer (application runtime environment), App layer (application-specific code), and GPU layer (vendor GPU libraries). Using these layers, OCI rootfs is created on-the-fly using overlayfs. The key improvement from DAC 1.0 is that app container bundle generation now happens on the CPE itself rather than on a cloud bundle generator. This architecture enables flexible application deployment and updates, reduced image size, independent application lifecycle management, and better isolation and security through containerization. |
Component Interaction Flow
The typical flow of a request through the RDK8 stack:
| draw.io Diagram | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The system follows a standardized request-response flow where the Application (RALF bundle) sends request to Firebolt Framework → Firebolt Framework translates request for ENT Services → ENT Services processes request and sends to Thunder Framework → Thunder Framework processes request and sends to Hardware Abstraction Layer → HAL executes command on Hardware → Hardware returns result to HAL → HAL processes result and sends to Thunder Framework → Thunder Framework formats response and sends to ENT Services → ENT Services translates response for Firebolt Framework → Firebolt Framework returns result to Application. This standardized flow ensures consistent behavior across different hardware platforms and enables rapid innovation through common patterns.
Build System
RDK8 build systems has evolved from the layered build system approach introduced in RDK7. In RDK8, the open source software ( OSS ) components were built and delivered as IPKs, which were consumed by the RDK layers. To make this model more flexible - thereby allowing to configure an OSS component for a particular platform - a new OSS consumption model is introduced in RDK8. In RDK8, the OSS layer is built from source in the vendor and middleware layers using the OSS reference distribution layer meta-rdk-oss-reference. Building the vendor and middleware layers now produces two IPK feeds, one for the layer and one for the OSS components
For a detailed build system overview, please refer this section
Application Scenario
Consider the use case of a user accessing a streaming application like YouTube on an RDK8 Entertainment-supported device. The user interacts with the YouTube application delivered as a BOLT package running in an isolated OCI-compliant Linux container managed by Dobby, the RDK container runtime. The containerized application utilizes the Firebolt Framework for standardized OTT app integration as a 3rd party 'untrusted' application, with the container boundaries providing enhanced security and isolation. The Firebolt Framework translates the user's request into standardized API calls and sends them to the ENT Services layer. The ENT Services process the request and coordinate with the Thunder Framework, which manages the RDK App Manager for container lifecycle control and uses unified orchestration to coordinate between different middleware components with standardized communication patterns. The Firebolt layer handle core Entertainment device functionality, including the Media Framework (Rialto for community builds) for video decoding and rendering, DRM Systems for content protection and digital rights management, App Gateway for lifecycle management 2.0 and application orchestration, and device management for optimal performance. The Thunder Framework processes these requests and sends them to the Hardware Abstraction Layer in the Vendor Layer, which executes commands on the hardware using standardized HAL specifications that abstract hardware differences across different SoC platforms. The physical hardware processes the video content leveraging GPU libraries (mapped from RDK rootfs as part of DAC 2.0's multi-layer architecture), video encoding/decoding hardware, and audio devices. The response flows back through the same standardized path in reverse - hardware returns results to HAL, which processes and sends to Thunder Framework, then to ENT Services for translation, and finally the Firebolt Framework returns the result to the containerized Application. This standardized request-response flow ensures consistent behavior across different hardware platforms while enabling rapid innovation through common patterns, modular component design, and the flexibility of downloadable containerized applications delivered as BOLT packages. The architecture provides a seamless and secure YouTube streaming experience with enhanced isolation through containerization, independent application lifecycle management through RDK App Manager, and clear separation of concerns across the three-layer architecture with the Image Assembler supporting DAC 2.0 for platform-agnostic, binary-exchangeable native applications.
Overview
Community Forums
Content Tools
Tasks