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
|
/****************************************************************************
**
** 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 Luxoft 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 installer.html
\title Application Installer
\keyword Installer
\section1 Dynamically Installing, Updating, and Removing Applications
After applications have been packaged by the \c application-packager, they can be installed by the
application manager at runtime. There are two interfaces for this functionality:
\list
\li a QML interface for use within the application manager process
\li a D-Bus interface for use by any process that is allowed to talk to the application
manager's \c ApplicationInstaller interface.
\endlist
Both interfaces are very similar and are described in the ApplicationInstaller.
\note A prerequisite for dynamically installed application packages is a valid
\l {Installation Locations}{installation location} configuration for the application manager.
\section1 Packages
The application manager has its own \l {Package Format}. It comes with the \l {Packager}{\c
appman-packager} command-line tool, for you to create and verify those packages.
\section1 Installation Sources
When triggering a package installation, you have to provide a URL to the application manager as
the source of the package. Out of the box, the application manager accepts the following schemes:
\table
\header
\li Scheme
\li Description
\row
\li \c file://
\li A local filesystem path.
\row
\li \c http://, \c https:// and \c ftp://
\li A remote path that is downloaded via QNetworkAccessManager.
\row
\li \c socket://
\li A path to a UNIX-domain socket in the local filesystem. This is very useful for streaming in
packages, if you do not want to (or can) use the built-in downloader, or if your packages are
wrapped inside another customer-specific distribution file format.
\endtable
All of the above methods work asynchronously and also support streaming: this means that the actual
installation is done while the package is being downloaded. If the package is successfully verified
after the download, it only needs a quick finalization step. Otherwise, if an error occurred, the
installation process is simply cancelled and rolled back.
\section1 Public Key Infrastructure
To use signed packages, you require a Public Key Infrastructure (PKI) to support this, which means
that you need two Certificate Authorities (CAs):
\list
\li A \e {Developer CA}: responsible for creating certificates that are distributed to developers
in P12 format. The developers use these certificates to developer-sign their packages, using
the \l {Packager}, before submitting to an app store.
\li An \e {App-Store CA}: responsible for creating certificates for use by app store server
backends to store-sign packages, before they are downloaded and installed onto devices.
\endlist
Both these CAs can be the same or they can be derived from a common root CA.
For the device, you need to install one or both of these CA certificates, including any root or
intermediary ones. But, this depends on the type of package you want the user to be able to
install. Which CA certificates to load is specified via \l {ca certificates} {the config file}.
The application manager sources has a script,
\c tests/data/certificates/create-test-certificates.sh, that sets up such a PKI for the internal
unit tests. This script is \b not for use in production, but only for use in developing with
signed packages.
\section1 Related Content
\list
\li \l {Package Format}
\li \l {Packager}
\li \l {Installation Locations}
\li \l {ApplicationInstaller}{ApplicationInstaller API}
\endlist
*/
|
