QtAutomotiveSuite Part 1 - An overview of the suite

QtAutomotiveSuite Overview

QtAutomotiveSuite is a collection of Qt-based projects geared towards the Automotive industry.

Some projects in the suite include:

  • Qt ApplicationManager - An application framework that can emulate the behavior of on OS at the application-layer of an automotive platform. It allows developers to build a SystemUI and several Applications that may be launched in separate processes.

  • QFace - An IDL format with a python-based generator tha simplifies the development of large scale interfaces, structs, and enums.

  • QML Live - A hot reloading application that automatically refreshes QML files when they are changed. This tool greatly simplifies the development of UIs by automatically reloading an application view without requiring the developer to re-compile and re-run an application.

Qt ApplicationManager

The Qt ApplicationManager provides one primary function: Provide the ability to run multi-process applications using the Wayland protocol implemented by QtWayland.

Common terminology:
SystemUI - The main homescreen of an application. This UI is loaded in the main process alongside Qt ApplicationManager code and is responsible for forking new processes. This is analogous to the homescreen on your mobile phone. If the system ui dies, the entire project is killed including all applications.

ApplicationUI - The available applications that are loaded by Qt ApplicationManager. These applications can be pre-installed or even installed at runtime. This is analogous to an application on your mobile phone. If an application on your mobile phone dies, you may be redirected to the homescreen or system ui.

Advantages of multi-process

  • Isolated processes per application - In the domain of automotive, this allows infotainment develoeprs the ability to launch a Navigation application, a Radio application, and a Settings application in separate linux processes. If the Navigation application crashes, the rest of the system is left unharmed. The Radio application and Settings application remain intact.

  • Application resource usage - Since the Navigation application, Radio application, and Settings application are running in separate processes, the system is able to report back resource usage per application. QtApplicationManager provides CpuConsumption and MemoryConsumption for each process. With this, we can figure out, for example, that the Navigation application is using 300MB of RAM, the Radio application is using 100MB of RAM and the Settings application is using 120MB of RAM. In a traditional single-process setup, all applications would be in a single process and there is no way of knowing how much machine resource is being used by one piece of this group of applications.

Disadvantages of multi-process

With advantages come disadvantages. And with multi-process being the leading advantage, we would have to write these disadvantages off as a debt of innovation.

  • Inter-application Communication - In single-process, if the Navigation application needed to talk to the Radio application, we could simply refer to the Navigation application by QML id, i.e.
import QtQuick 2.7

Window {
    SystemUi { id: _systemUi }
    NavigationApplication { id: _navigationApplication } 
    RadioApplication { id: _radioApplication } 
    SettingsApplication { id: _settingsApplication } 

We could simply refer to _navigationApplication by id and invoke methods, modify properties, send signals, etc:

Button {
    onClicked: _navigationApplication.routeToHome();

In multi-process, these applications are represented in the SystemUI as proxies living in the same process; however, each application is actually running in its own process. Each process has its own memory space; therefore, the memory referred to by the _navigationApplication pointer does not actually exist.

This prevents us from simply using the id to invoke methods, modify properties, send signals, etc. This work must be done using IPC or Inter-process Communication

  • Singletons - QtQuick developers far too often rely on singletons to manage global data or references to objects deeply nested within their object hierarchy. This is no longer supported as each process has its own QQmlEngine instance and cannot synchronize singletons across these engines.

  • Resource Usage - As each application is running in its own process, linux requires each process to load symbols from any shared libraries (e.g. Qt libs) in each process. This results in duplication of memory for each process. This would also result in duplication for assets such as fonts, images, media, etc.

  • Developer experience - Multi-process in Qt ApplicationManager uses QtWayland which is only available on Linux operating systems. From my experience, good production developers nowadays will use MacOS (which provides the ability to open design files in Photoshop, Sketch, Zeplin) and translate them into running code. Since MacOS does not support QtWayland – QtApplicationManager falls back to a single-process emulated mode. The downside; however, is that this single-process emulated mode does not prevent deveopers from accessing different application elements by id and could therefore break when the code is moved to a multi-process capable environment such as linux.


QFace is a very easy to use IDL format which includes a grammatical model template support to automatically generate Qt classes.
It is well-documented here: https://doc-snapshots.qt.io/qtivi-5.10/qtivi-attribution-qface.html


QmlLive is well-documented here:


  • Hot reloading is the new rage in development. It allows UI developers to quickly modify pixel values, colors, etc. and see their creation live on screen.
  • Allows deployment of a runtime to an embedded device to see a UI reload live on a different device.


  • This solution is too generic; reloads the entire application
  • UI states are not preserved upon reload


Stay tuned for more in-depth posts for each of the above projects

Niraj Desai

Niraj Desai

UI enthusiast, Qt / QML loyalist, passion for automotive UX – previously at Mercedes-Benz R&D, currently at NIO US.

Read More