General FAQs

Device Automation Bus (DAB) is an open source protocol that allows application developers to connect to a living room device and programmatically interact with the device. For example, to start and stop applications, send key press commands etc.

DAB works by enabling a communication bus between a device and a remote actor such as a test client. The protocol for communication used by DAB is MQTT. MQTT is a lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. DAB builds on top of the MQTT protocol to enable a remote user to connect to a device and perform operations such as starting and stopping an application.

We designed DAB to offer a mechanism to programmatically connect to living room devices that do not have a standard protocol for interaction today. However, DAB can be implemented on all devices, even if they have an existing mechanism of programmatic interaction today.

DAB allows you to execute a number of operations such as launching and suspending applications, sending keystrokes to the device etc. For a full list of operations, refer to the DAB specification in the Documents tab.

The DAB protocol was developed as a collaborative effort between Amazon Prime Video, Google and Netflix, Inc. 

DAB is an open source protocol and we welcome you to help us improve it.

Device Manufacturers

The DAB protocol provides the following key benefits:

Increase in OTT application quality for new entrants: Supporting a common protocol such as DAB will make it easier for new application developers to build high quality applications that are supported on your devices. High quality of applications will be ensured as a result of DAB providing the ability to automate tests on your devices, as opposed to manual tests that can lead to unreliable and inconsistent results. This in turn will increase the value of your devices for your customers.

Reduction of manual/Ad-hoc testing: 

With a common protocol to communicate with devices, you no longer need to conduct as many manual tests on your platform for each new application, device launch and firmware update. You can leverage DAB to run automated tests for a large number of applications on your device, thus, saving you time and effort. 

Stable applications: 

Applications on devices which support DAB have a higher likelihood of being stable because developers no longer have to customise tests and code validation steps per device model.

Better application interoperability: 

With DAB, you can switch between applications on a device in a programmatic manner. As a result, you can programmatically test that installed applications correctly share resources on your device.

Reduction in device testing / certification effort: 

As DAB is adopted by increasing numbers of OTT providers, we anticipate that the level of effort necessary for device manufacturers to comply with requirements for OTT app certification will be reduced.

To make your device compatible with DAB, you simply need to add a message broker to your device and implement the communication between the device and the broker according to the DAB Partner User Guide in the Documents tab.

Optional vs. Required features are referenced in the DAB specification.

Native, we highly prefer and recommend using the DAB native on-device approach. This is because of the following reasons:

  • Simple architecture and reliable DAB operations: DAB Native logic is contained within the device. This is a simpler end-to-end DAB call flow path compared to the bridge approach where bridge logic needs to be created, maintained, and debugged during an issue situation.
  • In Native mode, partners need to maintain just the on-device DAB implementation vs maintaining the bridge and on-device native automation implementation.
  • Bridge mode requires an additional machine external to the device in the same network as the device, unlike the native mode.
Yes. Partners can use the Bridge model to wrap their native automation tool behind DAB APIs. For more details please see the DAB user guide.
Yes, we have worked with RDK to develop DAB 2.0 on their platform.  As part of the AH212 reference source device, DAB is now supported and running on this device. You can access the code on GitHub, and RDK Central Website ( you may need to register an account for access ) if you want to build the FW image.

DAB is an open source protocol and is available for everyone to use freely. There are two cost considerations for you as a device manufacturer:

One, the effort required to make your device compatible with the DAB protocol. 

Two, DAB’s footprint on the device: i.e. the resources consumed by DAB. 

After you have implemented the DAB protocol, you can run a series of compliance tests available along with the specification to make sure that your device supports DAB correctly. 

You can find the compliance test suite git repository link in the Documents tab.

Yes, Integration and support for the DAB protocol by partners will need to be tested and certified. This will be done through a compliance test suite.

Each partner, integrating DAB, will be required to run the DAB compliance test suite on their platform. When there are platform-level changes that would affect the different application capabilities, partners will need to rerun the DAB compliance test suite. 

DAB compliance test results should be provided when submitting your device for certification with the application provider. Acceptance of the results is specific to each application’s requirements.

You can find the compliance test suite github link in the Documents tab.

We recommend running on every platform-level change that would affect the DAB-relevant system and application capabilities. This typically would correlate to a major platform firmware change like an OS version update.

Since DAB is a platform-level change, a device partner does not need to re-run for every device-level certification.  Once run, partners can submit the DAB compliance test suite results across participating certification applications and related device certifications.  Please consult the relevant contact with each application requiring these results if you need further clarification.

DAB enablement should be done securely, (i.e. a device with DAB in a disabled state would be considered secure) to prevent the risk of the unauthorized party being able to access the device. We believe there are simple ways to enable/disable DAB on a device either through partner-controlled enablement approaches (e.g remote enablement through server provisioning) or through user-controlled (e.g. secret set of key sequences or login credentials for DAB enablement).

DAB enablement in production is highly recommended in 2024 as this will allow application certification suites to use it for pre-release certification testing and post-release in-field compliance testing.

DAB Voice input operation does not collect any user data. Instead, it takes pre-recorded audio wav files through the on-device voice pipeline. This, along with the conditional enablement of DAB, should help alleviate privacy and security concerns around this operation.

DAB on a device can be enabled through a partner controlled or a user-controlled mechanism. The enablement mechanism is a choice of the partner. And voice input will not be available on a device until DAB is enabled. Furthermore, the voice input is not collecting the user’s voice. Instead, we are asking to run pre-recorded voice inputs through the on-device voice pipeline only on DAB-enabled devices. We think these restrictions should help address the relevant concerns around voice input operation

No. Telemetry is optional within the DAB 2.0 specification and it only supports the device and application’s CPU consumption.

No, DAB is limited to a set of operations listed in the DAB specification and does not allow anyone connected to the device to view device information or platform code beyond what is listed in the specification. More information is available in the DAB Security Guide.

We are actively working to publish instructions on how to join the DAB Consortium and contribute to the specification. In the interim, please reach out to your application specific engineering counterparts at YouTube, Netflix, and Amazon Prime Video.

Application Developers

The DAB protocol provides the following key benefits:

Consistent mechanism to automate tests: With DAB, you don’t have to customize your test environments based on the device you want to test on. You don’t have to invest weeks of effort per device in building device abstractions in order to interact with the device. You can, instead, use the same DAB protocol to automate your tests.

Improve quality: DAB allows you to test, measure, and debug your application easily which might not have been possible on some devices previously.

Improve the reliability of your tests: Unlike existing protocols such as DIscovery And Launch (DIAL) and InfraRed (IR) that do not include feedback mechanisms, DAB provides appropriate responses to your requests. DAB’s feedback mechanism makes your tests more reliable and easier to debug.

Information on whether a device model supports DAB or not can be found on the device manufacturer’s website or by contacting the manufacturer directly.


DAB is a mechanism for device automation, not a testing framework.  For this reason, DAB v2.0 does not provide a mechanism to fetch logs. However, you can program the tests you run in your application to track and save logs for your own application. In addition, if this capability is important to you, you can request the feature for future versions of DAB by filling out the contact form. Your request will be reviewed and acted upon among other requests from customers based on its impact and utility for all DAB users. Since DAB follows an open source model, you can also write and submit an update/enhancement to the protocol.


For devices that do not support DAB, you have to design and develop a driver that supports a capability to connect to a device and start and stop applications. In addition, you can encourage the device manufacturer to support DAB for future versions of the device.  If the device in question has its own proprietary automation capability, you can create a bridge implementation to bridge the DAB protocol with the device’s native automation protocol. You can access the DAB bridge SDK on Github.

No. Only the external actor (tester) will be able to communicate with multiple applications. Applications themselves will not be able to exchange messages through DAB V2.0