Skip to main content
Version: ACAP version 12

Extend compatibility to future AXIS OS major versions

This guide describes how to make an application built with Native SDK 12 compatible with AXIS OS 13. Upgrading a device from AXIS OS 12.11 to 13.x introduces breaking changes that may break your application or even trigger a rollback upon application installation during AXIS OS upgrade. Follow the steps below to update your application.

info

Note that this guide is just as relevant when using earlier versions of the SDK.

  1. Review breaking changes: Ensure your ACAP application does not use any functionality or permissions that are not supported in AXIS OS 13, listed in Changes for ACAP application in AXIS OS 13.
  2. Rebuild application if needed: If your application depends on any of the listed breaking changes, update it to align with the new requirements.
  3. Reinstall the application: Install the updated application on the device. This is treated as an application upgrade, preserving state and data.
  4. Test application on AXIS OS 13: When available, upgrade the device to AXIS OS 13 and test that the application works as expected.

Breaking changes in AXIS OS 13​

info

This table only lists breaking changes relevant for application developers. For a full list of breaking changes, see AXIS OS 13 breaking changes.

Enforcement of application signing​

Applications are required to be signed. See the ACAP application signing page for signing information.

info

It will be possible to install unsigned applications during development, but not in the preview release of AXIS OS 13.

AXIS OS version compatibility declaration​

In AXIS OS 12.10, an optional field compatibleOsVersions was introduced in the application manifest that specifies the AXIS OS versions the application supports. From AXIS OS 13, this field will be mandatory, and applications will only get installed if they state compatibility with the target AXIS OS version.

info

Note that only manifests using manifest schema v2 support this feature, meaning that manifests using schema v1 won't be supported in AXIS OS 13. Additionally, using package.conf as the configuration file won't be supported either. See Upgrade to schema v2 for more information.

Changed rules for application install/uninstall scripts​

If an application contains a post-install script or a pre-uninstall script, the following rules will apply:

  • The scripts files must have executable permissions.
  • The scripts must complete within 5 minutes.
  • If they are shell scripts, they must start with #!/bin/sh.
  • If the post-install script exits with anything else than zero, installation will fail.
    • The umask will be 022 when the script starts, ensuring that newly created files are readable by all users, but writable only by the application user.

Restrictions on dbus, user and groups​

The resources specified in the dbus, user and groups objects in the manifest will be restricted to an explicit set of allowed values. The permitted resources match those listed in Adding permissions to dynamic user.

The only non-dynamic user permitted will be the sdk user, which will have the same permissions as the dynamic user. The sdk user is scheduled for removal in AXIS OS 14.

Machine learning API (Larod)​

Usage declaration in the manifest​

If your application needs access to the DLPU, you must add the following object to the resources section in the manifest.

{
    "deepLearningProcessor": {
        "enabled": true,
        "required": true
    }
}

Set required to false if you want your application to get installed even if DLPU access is not available.

Removal of .larod model format​

Support for the .larod model format will be removed from the Machine learning API (Larod). Use the .tflite format instead.

Removal of Larod version 1 & 2​

Version 1 and 2 of the Machine learning API (Larod) will be removed. Migrate to at least version 3 of the API according to the migration guide found in Changes in the Larod API.

Video capture API (VDO)​

Removal of uint16_t for VDO_TIMESTAMP​

The uint16_t option for choosing timestamp type when creating a stream with Video capture API (VDO) will be removed. Adapt to uint32_t.

Removal of overlay enums​

Non-functional enums in the Video capture API (VDO) will be removed to improve API experienceand avoid false expectations that these enums would be working. The following enums will be removed:

  • vdo_overlay_color_get_type
  • vdo_overlay_text_size_get_type

Removal of deprecated functions​

The following Video capture API (VDO) functions will be removed:

  • Crop settings
  • vdo_buffer_is_complete
  • vdo_frame_get_fd
  • vdo_frame_get_opaque

For more information, see the Deprecated list in the API documentation.

Message Broker API will be removed and replaced by Device Data Hub API​

The Message Broker API will be removed. The same data previously provided via Message Broker will be available through the Device Data Hub API in the same format. No VAPIX parameters will change.

Remove the ability to install and run applications on SD card​

This is a beta feature that has never been officially supported or documented in the VAPIX Application API. For security reasons it will be removed in AXIS OS 13. A rework is planned for the future.

Breaking changes in AXIS OS 14​

Here is an extended list of breaking changes planned for AXIS OS 14. It is recommended to already now update your application to be compatible with these changes.

info

Note that there might be additional deprecations and breaking changes in AXIS OS 14 that are not listed here yet.

info

This table only lists breaking changes relevant for application developers. For a full list of breaking changes, see AXIS OS 14 breaking changes.

Removal of axhttp API​

The legacy API, axhttp (see HTTP API in the ACAP version 3 documentation), supported in ACAP SDK 3.5 will be removed in AXIS OS 14.