This article presents one of our recent collaborations with Google - a project that advances the boundaries of software-in-the-loop (SiL) development.

At its core, the initiative focuses on extending the Cuttlefish emulator to support broadcast signal simulation, significantly enhancing the development and testing capabilities of the Google Live TV application.

More importantly, it aligns seamlessly with our Cx (Continuous Everything) software factory mindset: fully automated pipelines, thousands of tests running 24/7, and a balanced mix of physical and virtual platforms - including Cuttlefish and Goldfish emulator.

The Challenge: Broadcast TV Development Without Hardware

Our goal was straightforward - but technically demanding:

How do you enable full-scale development and testing of broadcast TV software without relying on physical hardware?

Unlike OTT or broadband TV, broadcast systems depend on RF frontends, demodulators, tuners, and transport stream processing pipelines - hardware-specific components that are not trivially virtualized.

This creates two major constraints:

• Limited hardware availability in large development teams
• High cost and complexity of scaling test environments

While Android already provides emulator support (primarily via Goldfish), these environments are optimized for IP-based services, not terrestrial, cable, or satellite broadcast reception.

And yet, for us - and many of our customers - broadcast signal processing is not optional. It is core functionality.

Why Cuttlefish: A Better Virtualization Foundation

Originally developed within the Android Open Source Project ecosystem, Cuttlefish represents a new generation of Android virtualization.

It is not just another emulator - it is a high-fidelity virtual Android device designed for platform-level development and validation.

What makes Cuttlefish different?

• Near-native behavior: Accurately mirrors Android framework interactions
• Multi-instance scalability: Run multiple devices in parallel
• Cloud-ready deployment: Optimized for CI/CD pipelines
• Flexible configuration: Supports various device profiles (CPU, RAM, form factor)

Most importantly, Cuttlefish relies on the VirtIO (Virtual I/O) framework - a standardized interface that enables efficient communication between virtual machines and host hardware.

Instead of fully emulating every hardware component (which is slow and resource-intensive), VirtIO allows paravirtualized devices to interact with the host system more directly, significantly improving performance and scalability.

This architectural advantage made Cuttlefish the ideal foundation for our next step.

Extending Cuttlefish for Broadcast TV

Together with Google, we set out to transform Cuttlefish into something it was never originally designed to be: A fully functional virtual broadcast TV platform

We developed:

• Custom virtual drivers to emulate broadcast signal reception
• Signal injection mechanisms to feed transport streams into the emulator
• Integration layers to connect these components with the Android TV framework
• Configuration tools to simulate different broadcast environments

In practical terms, this means that Cuttlefish can now:

• Behave like a real TV device
• Process broadcast streams as if they were received over-the-air
• Support development and testing of Live TV features - without hardware

Figure 1. Cuttlefish emulator extended with broadcast signal injection and virtual TV hardware, enabling scalable Software-in-the-Loop testing within a cloud-ready software factory environment.

From Concept to Scalable Software Factory

Once the core functionality was validated, we integrated it into our software factory pipelines.

The impact was immediate:

• Hardware dependency removed for a large class of tests
• Massive scalability of automated validation
• Parallel execution of test suites across virtual instances
• Faster feedback loops for development teams

This approach proved especially valuable in scenarios where hardware platforms were:

• Limited in availability
• Still under development
• Too costly to replicate at scale

Engineering Challenges We Had to Solve

This was not a straightforward extension. Several non-trivial challenges had to be addressed:

1. Signal Fidelity and Stability

It was not enough to inject a stream—we needed to accurately reproduce real-world broadcast conditions, including timing, buffering, and synchronization.

2. Configurability

The solution had to support multiple broadcast standards and scenarios, enabling flexible testing across use cases.

3. Scalability

To be useful in CI/CD, the setup had to be:

• Lightweight
• Easily deployable
• Fully automatable

4. New Technical Domains

This project pushed parts of the team beyond their usual scope, particularly in:

• Containerization (Docker)
• Virtualization environments
• Cloud-based deployment models

Software Factory in Action

In our small setup example here, we run SiL testing across multiple platforms simultaneously:

• Two physical hardware platforms
• Virtual platforms: Cuttlefish and Goldfish

A typical workflow includes:

• Automated execution of test suites
• Real-time validation of application behavior
• Intelligent failure handling

When a test fails, the system automatically captures:

• Video recording of the failure
• Screenshots
• Contextual logs and execution data

When tests pass, no unnecessary data is stored - optimizing resource usage.

Figure 2. Google Live TV app running in Cuttlefish emulator

Performance Gains: Virtual vs Hardware

In a comparative analysis of 500 nightly test cases, Cuttlefish demonstrated a clear advantage:

• Significantly reduced execution time compared to hardware platforms
• Higher parallelization capability
• Better resource utilization

Goldfish, while still useful, was not included in the comparison due to its limited support for broadcast-related test scenarios.

Figure 3. Execution time comparison: hardware platforms vs. Cuttlefish (500 nightly tests).

What This Means Going Forward

By extending Cuttlefish with broadcast capabilities, we have effectively:

• Unlocked true hardware-independent development for digital TV
• Enabled scalable Software-in-the-Loop testing for complex media systems
• Bridged the gap between broadcast and virtualized environments

And beyond digital TV, the same approach is directly applicable to other domains - especially automotive, where hardware constraints are even more pronounced.

Closing Thought

This project is a clear example of how the right combination of virtualization, system-level engineering, and automation can fundamentally reshape development workflows.

Not by replacing hardware - but by making it optional where it used to be mandatory.