Qt Automotive Suite Deployment Server
The Qt Automotive Suite Deployment Server is a new component in the Qt Automotive Suite 5.12. Previously, it was known as the Neptune Appstore and used for demonstrations purposes.
This component is a lightweight HTTP server that provides network feeds to application packages that are available for installation by a Qt Application Manager instance, running on a target device connected to a network. The UI counterpart for the Deployment Server is the Downloads app in the Neptune 3 UI. Together, the Deployment Server and the Downloads app enable you to install different apps that are available in the server via network.
The key scenario for these components is to install apps during the integration testing process. Additionally, the code can also be used as a reference implementation for a fully-featured server, and a new Downloads app on the target device for production.
The Deployment Server works with the Application Installer in the Qt Application Manager and acts as an installation source for
https:// schemes. In addition to application packages, the Deployment Server also hosts meta information about each package, that is used by the Downloads app to visualize the choices available for the user to select. This meta information is stored in the form of tags and other information in the package header, according to the Qt Application Manager’s package format. When a package is uploaded to the server, the package header is parsed, associated with that package, and then sent to a Downloads app, that queries for a list of available apps. Using this information, a Downloads app can inform users about apps that are available and even hide those that are not compatible with the target installation. The figure below illustrates this installation scenario.
The Deployment Server is implemented in Python, using Django, based on the following assumptions.
- Applications are identified with a group of: Application ID, version, architecture, and tags; these groups are unique.
- Architecture is specified as a group of: CPU architecture, endianness, bitness, and OS. If a package does not contain architecture specific parts, the architecture is specified as All.
- CPU architecture is based on the return value from QsysInfo::buildCpuArchitecture().
- The installation target is automatically determined by parsing binary files. For example, detecting an ELF binary means that it's a Linux package; the CPU architecture, such as armv8, further defines the installation target. See QSysInfo::kernelType() for more details.
- If both native and non-native applications match the selection criteria, then the native application is preferred.
- Applications can be further filtered by tags, both as positive (inlucde) and negative (exclude) filters.
- Tags are considered alphanumeric and can contain lowercase Latin letters, numbers, and the underscore symbol. All tags passed to the server are converted to lowercase.
- Tags can also have an optional version. The version number is separated from tag using a colon (:). Similar to tags, the version can contain lowercase Latin letters, numbers, and the underscore symbol.
- Tags are matched according to versions. For example, if you request for "version 5.12", this matches with "5.12.0", but not vice versa. If you request for a non-versioned tag, any version matches your request.
- Tag lists in requests and packages are simplified. For example, "qt:5.12,qt:5.12.0" is reduced to "qt:5.12".
- Although the Application manifest allows for any number of categories to be assigned to an application, currently, the Deployment Server requires manual assignment of only one category to the application. Categories in the application manifest are ignored.
- Tag information is parsed from the package header's extra and extraSigned parts, from tags array. All elements of that array are added to package’s tag list.
- Each package has a version number. If the manifest does not contain a version field, a default version "0.0.0" is assigned.
Before you install the dependencies in the Python virtual environment, you must install the
libffi-dev package. Next, prepare the virtual environment:
virtualenv ./venv ./venv/bin/pip install -r requirements.txt
Make sure to adapt the
APPSTORE_* settings in
appstore/settings.py to your environment, before you run the server.
Since package downloads are done via temporary files, you need to setup a cron-job to remove these temporary files periodically. The cron-job should be triggered every
settings.APPSTORE_DOWNLOAD_EXPIRY/2 minutes; it needs to run:
To start the server, run the following command in your terminal:
./manage.py runserver 0.0.0.0:8080
This command starts the server on port 8080, and is reachable by anyone. You can modify the listening address to another address that suits your use case.
- Clean up the downloads directory:
This command removes all files from the downloads directory, that are older than
settings.APPSTORE_DOWNLOAD_EXPIRYminutes. Ideally, this command should be run via a cron-job.
- Manually verify a package for upload:
./manage.py verify-upload-package <pkg.appkg>
This command verifies if
<pkg.appkg>is a valid package that can be uploaded to the Downloads app.
- Manually add a store signature to a package:
./manage.py store-sign-package <in.appkg> <out.appkg> [device id]
This command first verifies the
<in.appkg>. If this verification succeeds,
<in.appkg>is copied over to
<out.appkg>and a store signature is added. The optional
[device id]parameter locks the generated package to the device with this ID.
© 2020 The Qt Company Ltd. 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.