1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
/****************************************************************************
**
** Copyright (C) 2019 Luxoft Sweden AB
** Copyright (C) 2018 Pelagicore AG
** Contact: https://www.qt.io/licensing/
**
** This file is part of the documentation of the Qt Application Manager.
**
** $QT_BEGIN_LICENSE:FDL-QTAS$
** Commercial License Usage
** Licensees holding valid commercial Qt Automotive Suite licenses may use
** this file in accordance with the commercial license agreement provided
** with the Software or, alternatively, in accordance with the terms
** contained in a written agreement between you and The Qt Company. For
** licensing terms and conditions see https://www.qt.io/terms-conditions.
** For further information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page introduction.html
\title The Qt Application Manager
The Qt Application Manager is a daemon that helps you to create embedded Linux systems that
have a highly complex UI setup, which you can optionally split into a multi-process setup to
increase flexibility and stability.
\image qt-application-manager.png
\caption Qt Application Manager Architecture
The main building blocks of the application manager are:
\list
\li \l {wayland overview} {Wayland Window Compositor}
\li \l {app launcher} {Application Launcher}
\li \l {input management} {User Input Management}
\li \l {notifications} {Notifications}
\li \l {app installation} {Application Installation}
\endlist
Combining these building blocks has certain advantages, as described \l {advantages} {below}.
\target wayland overview
\section1 Wayland Window Compositor
To support multiple UI processes on an embedded Linux system, you need a central window
compositor: a Wayland compositor is the state-of-the-art solution for this. Consequently, the
application manager incorporates a compositor that is fully-compliant with the Wayland protocol,
based on the \l {Qt Wayland Compositor} {QtWayland module}.
The window compositing part is project-specific, that you can write using QtQuick elements,
giving you all of QML's capabilities to implement rich and fluid animations in your
compositor.
In addition to the Qt Wayland Compositor, the application manager also provides an interface to
which you can attach arbitrary meta-data to any Wayland window. This interface is particularly
useful on custom embedded UI systems, where the top-level UI elements may not follow
the classic desktop-centric \e{Application Window}, \e{Modal Dialog}, and \e{Popup Menu} window
classification approach.
\target app launcher
\section1 Application Launcher
The launcher part is the central component for application life-cycle management: it starts and
stops applications (internal or third-party) either on an explicit request or as an automatic
reaction to external triggers. For example, in low-memory situations, you want to gracefully
terminate applications that the user hasn't interacted with in a while.
Since UI applications typically have to be stopped and restarted multiple times during the up-time
of an embedded system, and given the fact that most customers have tight constraints on the
startup times of UI applications, the application manager implements some tricks to improve the
startup performance: any application type that relies on a \e runtime component, such as QML or
HTML, can be \b quick-launched.
The actual implementation depends on the type of runtime. The application manager ships with a
QML quick-launcher that you can configure to keep at least one process with a fully-initialized
QML engine available in the background (dependent on actual CPU load). In this case, starting an
application only requires you to load the application's QML files into the existing engine.
Support for other runtimes can be added via an external, independent runtime launcher binary.
In addition to the runtime abstraction, the application manager is also able to run any application
inside a \e container instead of just an external Unix process. Support for these container-based
solutions must be provided by the customer and could range from full container solutions like
KVM or XEN to LXC or even down to mandatory access control frameworks like AppArmor or SELinux.
The application manager includes an example integration of Pelagicore's SoftwareContainers, which
are based on Linux Containers (LXC).
\target input management
\section1 User Input Management
Since most embedded UI applications rely on a virtual keyboard, the Qt Virtual Keyboard module can
be integrated into the System UI and the Compositor. Through the Wayland protocol, this virtual
keyboard component can then be transparently used from any Qt/QML application for full
internationalized text input, without any special provisions on the application side. In contrast,
non-Qt applications need to provide support for the required, open Wayland text input protocol.
\target notifications
\section1 Notifications
The application manager acts as a \e freedesktop.org standards-compliant notification server on the
D-Bus. For QtQuick applications, a QML component is provided which encapsulates the client side of
the \e freedesktop.org notification protocol.
Both, the client and server sides, also come with Qt-like APIs to extend any notification request
with additional meta-data using standard-compliant mechanism.
\target app installation
\section1 Application Installation
In addition to built-in applications, that are part of the System UI or the base installation,
the application manager also supports third-party applications, that are dynamically installed,
updated, and uninstalled.
Developing a built-in application compared to a third-party application is not much different,
except for the additional packaging step for third-party applications. The application manager
comes with a simple package format as well as a tool to create and digitally sign these packages.
The application manager's installer component can install and update these packages in a
background thread using either plain HTTP(S) transfers or by receiving data from a customer-specific
local socket connection. To support devices with limited disk space, all package installations
and updates take place as they are downloaded to the device. This is more efficient than downloading
the entire package first, and then proceeding with the installation or update.
Using a custom package format instead of a standard Unix format is deliberate for two reasons:
they either use libraries that support legacy formats or they include hooks for arbitrary shell
scripts; these hooks could be used to circumvent security measures.
Instead, the application manager uses a TAR archive with further restrictions on the type of content
and some named YAML metadata files, that are application manager-specific. These packages are
parsed via the BSD standard \c libarchive library, which is also the basis for the actual \c tar
command.
Additionally, these packages can be cryptographically signed by both the developer and the production
app-store server. The devices' "developer mode" allows using only a developer signature or
disabling this signature verification completely.
\target advantages
\section1 Advantages
Aggregating all these building blocks into a single daemon enables them to work together much more
efficiently:
\list
\li The compositor can perform security checks when an application requests to show a window, as
it has access to the process IDs of all applications started by the application manager. By
default, windows from unknown processes are not shown on the screen.
\li The application manager enforces policies on the usage of its internal IPC mechanism as well
as provides a D-Bus interface to the system's middleware to allow other process and libraries
to authenticate resource usage of applications started by the application manager. This is
possible because of the application's capabilities, that are stored in digitally signed manifests,
and the application manager's knowledge of the application-to-PID mappings.
\endlist
The application manager's ability to run the same System UI and QML applications in both single- and
multi-process mode also has quite some advantages - both during the development phase as well
as for product scaling. Typically, this does not require any changes to the System UI or the QML
applications themselves.
\list
\li As a developer you can choose which desktop OS you want to develop on. For single-process
testing you can choose from Windows, macOS, or Linux; without requiring Wayland. For
multi-process, you can choose between Linux or macOS. On Linux, the application manager uses
nested Wayland. On macOS, Wayland support is experimental.
\li Both modes can be mixed, for example, third–party applications could be run in separate
processes (or even in a secure container), while built-in QML applications could be
loaded in-process. This configuration results in quicker startup times.
\li The UI code that runs on the target system is the same code that runs on the developers'
machines.
\li The application manager gives you the possibility to scale down your product to lower-end
hardware by saving on system and graphics memory, as well as startup times. You can do this
by moving either all or just a few critical applications from multi- to single-process mode.
\endlist
Be aware that any non-QML application, such as a native C++ compiled executable, will break this
setup for developers on machines without Wayland support.
Still, there are projects that require applications using multiple UI technologies like QML, HTML,
or native OpenGL rendering. In this scenario, the application manager's ability to support various
runtimes makes it possible to composite all these applications seamlessly into a consistent user
experience.
*/
|
