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

The manifest.json file is validated 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. It always validates against the latest manifest schema version within the same major version you specified in schemaVersion.

To avoid signing issues, it's 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, which 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.9.0	12.8	12.8.0	New resource nexus_beta1 for enabling the Nexus API. When enabled, the application can create topics, publish data, and subscribe to updates. Note, the Nexus API was removed in 12.9 making the nexus_beta1 resource obsolete.
1.8.0	12.6	12.6.0	- New option for the runMode property: respawnOnFailure. When enabled, the application will start at boot and restart automatically if it exits with a non-zero exit code. - The appId property is now required when copyProtection is set to axis, in order to ensure proper license validation. - New property conditionalGroups for specifying non-required groups for the dynamic user of the ACAP application. More information can be found in the Configure application user section. - Add restrictions to paramConfig.name; Only allow letters, numbers, and underscores _, and set maximum length to 32 characters.
1.7.4	12.4	12.4.0	Allow all characters except \n and \r in the vendor field.
1.7.3	12.2	12.2.0	Allow reverse proxy apiPath of length 1.
1.7.2	12.1	12.1.0	Add restrictions to friendlyName: - Disallow newline characters \n and \r. - Set maximum length to 256 characters.
1.7.1	12.0	12.0.0	- Allow user and group names to contain hyphens -. - Force appName to start with a regular letter and have length of at least 2.
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.