The Application Installer
Dynamically Installing, Removing and Updating Applications
After applications have been packaged by the application-packager, they can be installed by the application-manager at runtime. There are two interfaces for this functionality:
- a QML interface which can be used within the application-manager process, and
- a D-Bus interface which can be used by any process which is allowed to talk to the application-manager's
ApplicationInstallerinterface.
Both interfaces are very similar and both are documented in the ApplicationInstaller.
Note: A prerequisite for dynamically installed application packages is a valid installation location configuration for the application-manager.
Packages
The application-manager has its own Package Format. It comes with the appman-packager command-line tool, which lets you create and verify those packages.
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:
| Scheme | Description |
|---|---|
file:// | A local filesystem path. |
http://, https:// and ftp:// | A remote path that will be downloaded via QNetworkAccessManager. |
socket:// | 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. |
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.
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:
- A 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.
- An 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.
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 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 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.
Related Pages
© 2019 Luxoft Sweden AB. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.