Kanzi 3.9.16 migration guide¶

Use this migration guide to update Kanzi applications from Kanzi 3.9.15 to Kanzi 3.9.16.

Changes to application input events¶

Application input events sleep and wakeup are renamed to paused and resumed, to be consistent with the application states. Change the event types and function calls in your code to use the new names:

Kanzi 3.9.15	Kanzi 3.9.16
`InputEvent::Type::ApplicationSleep`	`InputEvent::Type::ApplicationPaused`
`InputEvent::Type::ApplicationWakeup`	`InputEvent::Type::ApplicationResumed`
`addApplicationSleepEvent()`	`addApplicationPausedEvent`
`addApplicationWakeupEvent()`	`addApplicationResumedEvent`

The previously unused InputEvent::Type::ApplicationPaused event now reports that the application is paused and transitioned to MainLoopState::Paused. This event serves the function previously held by ApplicationSleep.

Changes to the Kanzi Documentation MCP server¶

A new unified Kanzi Documentation MCP server is available at https://docs.mcp.kanzi.com/mcp with a new mcpb bundle for Claude Desktop at https://docs.kanzi.com/mcp/kanzi-docs-mcp.zip. The new endpoint supports all loaded Kanzi versions.

The existing version-specific URLs (kanzi-docs-mcp-v3-9.* and kanzi-docs-mcp-v4-0.*) remain supported. To use the new integration, migrate to the unified URL. See Kanzi Documentation MCP server.

If you previously added version-specific entries (such as kanzi-docs-v3-9 or kanzi-docs-v4-0) to your MCP client configuration, remove them after adding the unified kanzi-docs entry. Keeping duplicate entries can hang client startup.

Changes to QNX touch input¶

Kanzi 3.9.16 reworks how the QNX Screen platform reports touch input. This change is internal to the QNX platform backend and requires no changes to the Kanzi API or to your build configuration. If your application runs on QNX Screen and relies on the specifics of the touch events it receives, review the following behavioral changes:

Touch point IDs are now assigned by Kanzi instead of passing through the native QNX contact IDs. Treat the id of a TouchEvent::TouchPoint as an opaque handle that is stable only for the lifetime of a single contact. If your application persisted or compared against the numeric touch IDs previously emitted on QNX, update that logic.
The previous limit of ten simultaneous touch points is removed. Your application can now receive more than ten concurrent touch points if the hardware reports them. Review any logic that assumed at most ten contacts.
Stationary contacts no longer generate move events. A held-but-motionless finger is reported only when its position actually changes. If your application depended on receiving continuous move events for a stationary contact, use the current touch point state and position instead of event frequency.

Activity triggers run when an Activity Host activates or deactivates without animations¶

An Activity node now reports its status in every case where that status changes. Previously, when an Activity Host activated or deactivated an Activity node without animations, the Activity node changed its Activity Status property without sending ActivityConcept::ActivityActivatedMessage, ActivityConcept::ActivityDeactivatedMessage, or ActivityConcept::StatusChangedMessage.

No API changed, but logic that was silently never running now runs. This affects the Activated and Deactivated Activity triggers, message handlers for the messages above, and the ActivityCodeBehind status callbacks onActive and onInactive, on:

Activities in a Parallel Activity Host.
Child Activities of an Activity that you deactivate. Their Deactivated triggers now run, even though the Active -> Deactivating and Deactivating -> Inactive transitions are still skipped.
Any Activity whose prefab path changes while that Activity is active, such as on an Activity Template change or during Kanzi Studio Preview live editing.
Any Activity node that leaves the node tree while it is not Inactive, which includes application shutdown.

Review the Activated and Deactivated trigger logic and the Code Behind status callbacks of your Activities for actions that assume these cases never reached them. Actions that acquire and release a resource, such as opening and closing a connection, are the most likely to change behavior.

Changes to selecting the Kanzi version in the MCP servers¶

Both Kanzi MCP servers no longer remember a Kanzi version between calls. set_kanzi_version and set_version no longer switch the version that later calls use; they now confirm that a version is available and report its contents. The query tools take an optional version argument instead, such as version="3.9.16". When a call omits version, the server answers for the newest version it has available. This comes from the 2026-07-28 revision of the Model Context Protocol, which removes protocol-level sessions.

Both servers are shared services, so this change applies to every Kanzi version they serve, not only to 3.9.16.

Nothing changes in how you set up either server, and no client configuration needs updating. If you gave your AI assistant instructions that call set_kanzi_version or set_version before querying, replace that with an instruction to pass version on every call. You might have written such instructions in CLAUDE.md or .github/copilot-instructions.md. Otherwise the assistant silently receives answers for the newest Kanzi version instead of yours. For an example of the instruction to give your assistant, see the Configuring your AI assistant section; the same approach applies to the documentation server.

See Kanzi Documentation MCP server and Kanzi API MCP server.