Key Updates from RDK7 to RDK8

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.

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

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

In RDK8, the traditional Application Layer has been removed entirely. 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. For more details refer [Apps in RDK8](https://wiki.rdkcentral.com/spaces/RDK/pages/474687726/Factory+Apps+on+RDK8)

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:

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

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

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

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.