The following key principles of RDK8 illustrate the areas of change and focus from RDK-V previous releases:[TBD]

The Layered Design provides clear separation of functional responsibilities through distinct vendor, middleware, and image assembler with independent development and update cycles. Hardware Abstraction reduces the cost of SoC/OEM deliver & platform through standardized hardware abstraction layer (HAL) and simplified platform adaptation. Application Community focuses on standardization of portable 3rd party apps, consistent APIs for application developers, and Firebolt framework for OTT integration. Quality & Robustness involves major transformation of delivery process to ensure quality, independent testing of each layer, and consistent development environment. Rapid Innovation is achieved through utilization of common tooling and patterns. Broadcast Functionality enables separation of broadcast technology from IP platform.

Architecture[TBD]

A quick architecture overview of RDK7 RDK8 to help associate the capabilities with the software stack is given below.

The architecture consists of three main categories. The image assembler. The Middleware Layer contains Thunder Framework, ENT Services, Media Framework, DRM Systems, and Device Management. The Vendor Layer contains HAL Implementation, Drivers, BSP, and Hardware Adaptation. The Image assembler connects to the Middleware Layer, which connects to the Vendor Layer.

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

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.

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 the application layer to access device capabilities.

The middleware layer includes core RDK components, media playback, DRM systems, and device management. 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.

Image Assembler[TBD]

In RDK8, the traditional application layer has been restructured and replaced by the **Image Assembler**. This layer contains supporting components for DAC (Downloadable Application Containers) and RALF (RDK Application Lifecycle Framework). The application layer has been removed from the traditional middleware build - WPE WebKit browser, Cobalt, and other native applications are no longer built as part of the image. These components are now delivered as BOLT packages that are built separately and can be downloaded at runtime.

When a device boots for the first time, the Factory App / Reference UI must already be present. Factory applications are bundled in the image during build time using a BitBake class (`install-factoryapps.bbclass`) that reads a JSON manifest and installs factory applications into the rootfs. Packages are fetched from multiple sources (HTTP/HTTPS, FTP, local files) with SHA256 verification. The pre-installation structure organizes packages in `/opt/preinstall/` with individual folders for each app containing their `package.ralf` files.

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 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.

Detailed Architecture[TBD]

Component Interaction Flow

Markdown
The typical flow of a request through the

RDK7 stack: draw.io DiagrambordertruediagramNameComponentInteractionsimpleViewerfalsewidthlinksautotbstyletoplboxtruediagramWidth1011height61revision2

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, and 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[TBD]

RDK7 introduces a revolutionary layered build approach that significantly improves development efficiency. The build setup is divided into independent Stack layer projects, each comprising components that are developed separately and delivered as binary packages (IPK). These stack layers are then assembled into the final image using the Image Assembler tool.

The build system architecture includes the Reference OSS Layer that serves as a reference Yocto distribution layer with CVE patches, the Vendor Layer that contains vendor-specific code and hardware adaptations, the RDK Middleware Layer that contains core RDK middleware components, and the Application Layer that contains user-facing applications and services. The RDKE framework serves as the backbone of this layered architecture, designed to work seamlessly with Yocto without disrupting its normal functionalities while requiring minimal maintenance. It accommodates layering requirements without modifying Yocto's default tasks or variables.

Build System[TBD]

<this can be taken from RDK8 release notes once done>

Application Scenario[TBD]

<changes might be needed,check with apps team>

Build System Directory Structure

├── application
│   └── meta-application-release
├── common
│   ├── meta-openembedded
│   ├── meta-oss-reference-release
│   ├── meta-rdk-auxiliary
│   ├── meta-rdk-halif-headers
│   ├── meta-rdk-oss-reference
│   ├── meta-stack-layering-support
│   └── poky
├── configs
│   └── common
└── product-layer
    └── meta-rdke

Key Benefits of layered builds

The layered build approach offers several key benefits across multiple areas. 

• Scalability is achieved as each layer can be updated independently without affecting or relying on other layers, and updating only the vendor layer can be achieved by using the latest tag from that layer and applying it to the stack.
• Quality is ensured through each layer undergoing unit testing and layer-specific testing prior to release, with all requirements validated during this process and fully tested and tagged versions of the IPKs produced for quality assurance.
• Easy debugging is facilitated as developers are required to compile only their own projects, IPKs from other components can be consumed directly eliminating the need to build the entire set of components, tagged versions of application cases can be used to verify individual components, and overall build time is significantly reduced.
• Less disk usage is accomplished when working across multiple products as the middleware and application layers are designed to be as common as possible, the primary difference between products lies in the vendor layer, multiple vendor layers can be checked out and modified while using shared IPKs in the application layer, and this approach eliminates the need to check out the entire codebase for each product significantly saving disk space.
• Consistent development environment is maintained as each developer builds components against tagged versions of other components, ensuring that regressions or issues in unrelated components do not affect development, and only tested and tagged versions are used.

The RDKE framework accommodates specific requirements for the layered build system by resolving both direct and indirect interlayer build dependencies, generating proper packaging metadata for runtime dependencies, creating IPKs without disrupting layer and interlayer runtime dependency chains, supporting installation of specific release versions of layer packages, creating target rootfs using both development packages and release layer IPKs, and supporting prebuilt kernels and device trees.

Consider the use case of a user accessing a streaming application like YouTube on an RDK7 RDK8 Entertainment-supported device. The user interacts with the YouTube application through the Application Layer, selecting content and initiating playback, where the delivered as a RALF (RDK Application Lifecycle Framework) 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 processes the request using unified orchestration and coordinates manages the RDK App Manager for container lifecycle control and uses unified orchestration to coordinate between different middleware components with standardized communication patterns. The ENT Services within the Middleware 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, while the . 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 ENT ServicesThunder Framework, then to Thunder Framework 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 and , modular component design, providing and the flexibility of downloadable containerized applications delivered as BOLT packages. The architecture provides a seamless and secure YouTube streaming experience for the user with 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.

Useful Links[TBD]

<this will be done at the end>

RDK-V:

You can find an overview of the RDK-V platform, detailing its key features and functionalities at RDK Video Documentation.

Applications:

To get the information about various applications supported by the RDK-V, aiding in understanding the diverse application landscape refer RDK Video Accelerator - Applications

Application Development:

Developers interested in RDK-V application development using Firebolt® can refer Firebolt® Overview and

Developers interested in RDK-V application development using Lightning™ the inhouse JavaScript framework - can refer Lightning™ Framework.