Manifest schemas

The ACAP manifest schema defines the structure and content of the manifest.json. It acts as an agreement between the ACAP and the AXIS OS, describing metadata, runtime behavior, and the resources that the application needs. By using the manifest, ACAP applications can be validated before installation, declare their required capabilities, remain uniform in structure, and operate consistently across devices and AXIS OS versions.

The pages listed in the table of contents below present detailed descriptions of the fields in the generated manifest schema.

info

If your application is still using package.conf, it is recommended to migrate to manifest.json. Follow instruction in the Migrating from package.conf to manifest.json guide.

Overview

• The SDK is bundled with manifest schemas of various versions.
• When you run acap-build, it validates your manifest.json file against a specific manifest schema version.
• The manifest schema is versioned separately from the SDK.
• Newer SDK versions include newer manifest schema versions. See Manifest schema version mapping for details.

Required fields

The structure of the fields can be seen by the list level. A required field in a sub-section means it's only required if the section above is chosen.

Validation

Validation of manifest.json happens in multiple stages:

During build

When running acap-build, the manifest is validated against the manifest schema version specified in schemaVersion.

During signing

When signing the application in the ACAP Service Portal, the manifest is validated again. This validation is always performed against the latest manifest schema version within the same major version as the one specified in schemaVersion.

To avoid signing issues, it is recommended to validate your application against the latest manifest schema version within the same major version during development and build time.

info

To sign an ACAP application the minimum manifest schema version possible to use is 1.3 that introduced the for signing mandatory field architecture.

Manifest schema version mapping

This table shows the SDK version in which each manifest schema version was released, along with a description of the changes.

Schema	AXIS OS	SDK	Description
1.7.0	11.10	1.14	Make preparations on the host system so the application can run containers, and create symbolic links from various system-wide locations to Docker CLIs provided by the application.
1.6.0	11.9	1.13	- Add support for characters $ and \ in apiPath of the reverse proxy configuration. - Add optional field $schema that can point out a manifest schema to use for manifest validation and auto-completion. - Allow strings in requiredMethods and conditionalMethods under dbus to contain -.
1.5.0	11.8	1.12	- Add support for reverse proxy configuration. - Add access policy for ACAP application web content. - Allow - character in secondary groups of linux resources. - Allow strings in requiredMethods and conditionalMethods under dbus to end with .* to match all methods of a D-Bus interface.
1.4.0	11.7	1.11	Allow new characters ( ) , . ! ? & ' for vendor field.
1.3.1	11.0	1.4	Bug fixes; Allow = in runOptions and maxLength of appName should be 26.
1.3	10.9	1.1	Add field architecture, which will be automatically generated and added to manifest at packaging step.
1.2	10.7	1.0	Enables uninstall functionality which is required by e.g. docker-compose-acap.
1.1	10.7	1.0	Additional fields, mainly for technical reasons.
1.0	10.7	1.0	Initial basic version.