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) 2018 Pelagicore AG
** Contact: https://www.qt.io/licensing/
**
** This file is part of the documentation of the Pelagicore 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 The Application Installer
\keyword Installer
\section1 Dynamically Installing, Removing and Updating 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 which can be used within the application-manager process, and
\li a D-Bus interface which can be used by any process which is allowed to talk to the
application-manager's \c ApplicationInstaller interface.
\endlist
Both interfaces are very similar and both are documented 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, which lets you 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 will be 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
If you want to make use of signed packages, you need to setup a public key infrastructure (PKI) to
support this. You need:
\list
\li A \e {Developer CA} which is responsible for creating certificates that are distributed
to developers in P12 format. The developers use these certificates to developer-sign their
packages (using the Packager tool), before submitting to an app-store.
\li An \e {App-Store CA} which is responsible for creating certificates that are used
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.
As for the device, you need to install one or both of these CA-certificates (plus any root and
intermediary ones), depending on the type of package you want the user to be able to install.
Which CA-certificates are loaded is specified \l {ca certificates} {via the config file}.
The application-manager sources contain a script that sets up such a PKI for the internal
unit-tests: it can be found in \c tests/data/certificates/create-test-certificates.sh. You should
never use this to create a production environment, but it could be helpful to quickly and easily
switch to developing with signed packages.
\section1 Related Pages
\list
\li \l {Package Format}
\li \l {Packager}
\li \l {Installation Locations}
\li \l {ApplicationInstaller}{ApplicationInstaller API}
\endlist
*/
|
