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 available on the server through 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 Qt Application Manager and acts as an installation source for http:// and https:// schemes. In addition to application packages, the Deployment Server also hosts meta information about each package, that is used by Downloads app to visualize the choices available for a 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 the Downloads app, that queries for a list of available apps. Using this information, the Downloads app can inform users about the available apps 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.

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::buildAbi() and QSysInfo::kernelType(), joined with '-'.
• 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.

Note: In order to create a tagged package you can use appman-packager with -m parameter, for example:

appman-packager create-package package.pkg package-tmp/apps/com.luxoft.alexa/ -m "
{tags: ['platform:desktop']}" --verbose

This command creates package and adds platform tag with desktop value to it. For reference see the Packager section of Qt Application Manager documentation.

References and procedures

• Qt Automotive Suite Deployment Server Installation
• Qt Automotive Suite Deployment Server API Reference
• Set up a Production server with Apache, Lighttpd or Nginx
• Upload Packages to the Deployment Server