FAQ
This page answers common questions about ACAP SDK 13 Preview regarding migration, compatibility, signing, and packaging.
SDK 13 Preview is for validation and migration planning. It is not for production deployment.
SDK 13 Preview and migration
1. What is the purpose of SDK 13 Preview?
The ACAP Native SDK 13 Preview is an early-access release for validation and migration planning, not for production deployment. This release gives developers early access to upcoming changes in AXIS OS 13 — especially breaking changes that may affect existing ACAP applications.
The SDK 13 preview is not intended for production deployment, rather, it is designed to help developers::
- Build applications against an SDK that is based on AXIS OS 13. This will help identify if your application uses any functionality that will be removed in AXIS OS 13.
- Identify breaking changes that impact their code.
- Validate dependencies and third-party libraries.
- Update manifests and permissions (manifest schema v2).
- Adapt to new security and capability restrictions.
- Provide early feedback before the official release.
Since SDK 13 Preview introduces significant changes — including security model updates and permission adjustments — it's important that developers use this preview phase to:
- Evaluate compatibility.
- Plan migrations.
- Allow developers to validate compatibility before the final release.
| ✅ Appropriate use | ❌ Not recommended use |
|---|---|
| Feature evaluation in lab/development environments | Production deployment on customer systems |
| Porting existing applications to identify breaking changes | Building new production features dependent on preview APIs |
| Validating CI/CD pipeline compatibility | Shipping applications to end users |
| Providing feedback on migration blockers | Assuming API/ABI stability across preview iterations |
In short, the SDK 13 Preview exists to ensure a smooth transition to AXIS OS 13, giving developers time to prepare rather than react after release.
2. Can a developer use earlier versions of the SDK to build applications for AXIS OS 13?
Yes, it's possible to use earlier versions of the SDK, such as 1.15.1 or 12.x. However, the SDK can only guarantee that the produced application works within the same major version of AXIS OS on which the SDK is based. For example, using SDK 12.6 will produce an application that is guaranteed to be compatible with AXIS OS 12.6 and later versions within the 12 major release. Therefore, when using earlier SDK versions, it's important to make the necessary modifications to your application code to ensure compatibility with future major versions.
However, by testing to build your application using the SDK 13 Preview might give you indications about what you need to update to make your application compatible with AXIS OS 13.
3. Can an ACAP application built with the SDK 13 Preview be deployed in production?
No. The SDK 13 Preview is intended for testing and validation purposes only.
Applications developed or rebuilt using the SDK 13 Preview should not be deployed in production environments for the following reasons:
- APIs may still change before the final release
- Breaking changes may still be adjusted
- Stability is not guaranteed at the same level as an official release
- Security reviews and long-term support are not finalized
The preview phase exists to allow developers to:
- Test compatibility
- Identify required changes
- Adapt their applications
- Provide feedback
To ensure stability and support, only applications built with the final released Native SDK 13 should be deployed to production. Applications built with preview SDK versions must not be deployed to production.
4. Will an application built for AXIS OS 12.10 be compatible to AXIS OS 13?
Using the manifest schema v.2 is one of the requirements for an ACAP application to be AXIS OS 13 compatible. However, it is recommended to verify the announced breaking changes. See ACAP application breaking changes in the AXIS OS portal.
5. How should developers use the SDK 13 Preview to ensure compatibility when migrating an ACAP application from AXIS OS 12.x LTS to AXIS OS 13?
Use the AXIS OS and SDK 13 previews to test your application and identify required migration updates. Continue using the stable ACAP Native SDK for AXIS OS 12 for production builds until the final SDK 13 is released.
Example:
- You have an application that is currently running in production on AXIS OS 12 and you are worried if it will be compatible with AXIS OS 13.
- You build the application using the SDK 13 Preview and get a build error about an invalid manifest.json. You read the error message and notice that from AXIS OS 13 it is required to use manifest schema version 2.0.0, but you are currently using 1.9.0.
- You find a guide on ACAP documentation that explains the required changes needed to get a valid
manifest.jsons schema version 2.0.0. - You try building it again with SDK 13 Preview and you might find even more breaking changes. Repeat until it successfully builds.
- Your application is ready for AXIS OS 13. Build it with SDK 12 and deploy.
Use the same procedure to migrate between AXIS OS 11 and 12, or from AXIS OS 10 through 11 and 12, to create an application compatible across AXIS OS 10 to 13.
6. Is an ACAP application built using the ACAP Native SDK 13.x backward compatible with AXIS OS 12 LTS?
No. An ACAP application built with Native SDK 13 Preview targets AXIS OS 13 Preview and is not guaranteed to be compatible with AXIS OS 12 LTS.
To ensure compatibility, the application must be built using the supported SDK version for the target AXIS OS.
General
1. Can frequent writes to internal storage affect the device lifespan?
Yes. Axis devices use flash memory for persistent storage, which has a finite number of write and erase cycles per memory cell. Each write or erase operation contributes incrementally to wear on the underlying storage media.
ACAP applications that frequently write data to internal flash storage, particularly in high-frequency or continuous write patterns, can significantly increase the number of write/erase cycles over time. If such usage is not carefully controlled, it may accelerate flash wear beyond what is expected under normal operating conditions.
Excessive or unnecessary write operations, such as continuously storing data from an ACAP application, can accelerate memory wear over time and progressively reduce the memory's integrity. This may shorten the expected operational lifespan of the device. Once the flash memory reaches its designed endurance limits, reliable storage operation cannot be guaranteed, potentially impacting the device's ability to store configuration data, logs, or application state.
To ensure long-term reliability and predictable device behavior, ACAP applications should:
- Minimize write frequency to internal flash storage.
- Avoid using flash memory for high-rate or continuously updated data.
- Prefer volatile memory, external storage, or supported mechanisms designed for frequent data updates.
Developers should understand their application requirements and evaluate which storage solution best fits their specific use case.
Efficient data handling strategies, such as buffering, batching, or using alternative storage options when appropriate, help maintain optimal device performance and longevity.
By following these guidelines, application developers help preserve storage endurance and ensure that Axis devices continue to operate within their intended design parameters throughout their lifecycle.
2. Where can developers find ACAP application examples?
Developers can find ACAP application examples in ACAP application examples.
Manifest, compatibility, and package.conf
1. How do minimum and maximum AXIS OS manifest fields work?
min_axisos means the application runs on that version and later. For example, setting min_axisos to 12.10 means the ACAP application runs on AXIS OS 12.10 and later, but not on 12.9 or earlier versions".
When max_axisos is defined, it blocks execution on newer versions and acts as a safety guard until you validate and republish. This is a safety mechanism to prevent the application from running on future OS versions that may introduce breaking changes. In this case, the developer would need to rebuild (or update) the ACAP application and adjust the manifest to support newer AXIS OS versions.
For detailed information on how to upgrade a manifest schema, see Upgrade a manifest
2. How do developers make an application compatible with AXIS OS 11, 12, and 13?
Developers can make applications compatible with newer AXIS OS major versions by following the Extend compatibility to future AXIS OS major versions guide available for ACAP Native SDK version 4 and version 12. These guides describe the required updates and breaking changes introduced when migrating applications from AXIS OS 11 to 12 and from AXIS OS 12 to 13, helping ensure that applications continue to install and run correctly after device upgrades.
3. How can developers migrate their ACAP application from package.conf to manifest.json?
Since package.conf will no longer be supported as the ACAP application configuration file in AXIS OS 13, developers must migrate their applications to use a manifest schema. For guidance on migrating from package.conf to manifest.json, see Migrating from package.conf to manifest.json.
4. How can developers use a newer manifest schema in an older SDK?
For guidance on how to use a newer manifest schema in an older SDK, see the Use newer manifest schema in old SDK page.
5. Where can developers find the manifest schema reference and upgrade guidance?
Developers can find the manifest schema reference and upgrade guidance in the manifest schema page. This section provides an overview of the manifest schema versions and provides specific guidance for migrating and upgrading the manifest.
6. Where can developers find the API reference and the API compatibility guide?
Detailed technical specifications for the supported APIs are available on the Supported APIs page, while AXIS OS support details are available in the API compatibility guide.
Security, signing, and runtime behavior
1. Is ACAP signing required when using the AXIS OS 13 Preview?
Yes. ACAP signing is mandatory on AXIS OS 13 Preview. Only signed applications are allowed to be installed and executed on the device, see Enforcement of ACAP signing. For more more details about the signing process, visit the ACAP Service Portal on axis.com.
2. How should TIP partners sign their ACAP applications?
For information on how TIP partners should sign ACAP applications, see the ACAP application signing page. If you're not a TIP partner, a signing tool will be available starting with AXIS OS 13. Instructions for non-TIP partners on signing their ACAP applications will be published soon.
3. Where can developers find their vendorID for signing?
Developers can find their vendorID in the ACAP Service Portal, where the ACAP signing process is managed. For more information, see: ACAP application signing.
4. Can developers use VAPIX instead of D-Bus for some integrations?
Yes, depending on the use case. Developers should first check the supported APIs for their specific needs. In some cases, VAPIX can be a valid alternative to D-Bus, depending on the available endpoints and required functionality.
5. What does DLPU usage declaration in manifest mean?
If an application uses DLPU resources, it must declare this in manifest.json. This allows AXIS OS 13 to correctly manage permissions, compatibility, and resource allocation. Without this declaration, the application may fail to install or run properly.
6. How can developers address Year 2038 compliance?
In order to be complient with the 2038 issue Y2038 problem the SDK will by default enable 2 C-flags, _TIME_BITS=64 and _FILE_OFFSET_BITS=64. This will enable the ACAP application to support times beyond 2038, but it will also have some technical impact on the ACAP application, types like time_t, off_t and ino_t will increase in size from 32 to 64 bit. Calls to libc should be handled automatically so a call to eg. stat() will be directed to the libc variant __stat64_time64 which is 2038 secure, tools like objdump and readelf could be used to inspect the binary.
- Make sure to recompile any third party libraries using any of these types/functions in the interface.
- Make sure that no binary data using these types are written to config files or similar.
- An ACAP application using libc functionality and built with these 2 flags should work on AXIS OS 12 track, enabling migration already there and also allow the ACAP application to be upgraded to AXIS OS 13. See Year 2038 problem
Installation scripts and storage behavior
1. Can ACAP applications run from SD card on AXIS OS 13?
No. ACAP applications must run from internal storage. For more information, see Stop supporting the ability to install and run ACAP applications on SD card.
2. What changed for pre-install and post-install scripts?
If an application contains a post-install script or a pre-uninstall script, the following rules will apply. For more information, see Changed rules for ACAP application install/uninstall scripts.
- 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
022when the script starts, ensuring that newly created files are readable by all users, but writable only by the application user.
3. Can developers use SDK user in ACAP applications on AXIS OS 13?
It is available with tighter restrictions in AXIS OS 13 and is planned for removal in a future major version.
Need more help?
Not finding what you are looking for? Head over to GitHub Discussions and search for the answer there.