Kotzilla Release, July 2026: startup metrics, consent, & impact analysis

The July 2026 release ships across three components.

1. The Kotzilla SDK (2.3.0) now boots automatically at process start, captures cold and warm startup metrics on every app launch, and gates the entire SDK behind explicit user consent

2. The Kotzilla Console (4.12.0) reworks Issue Details with a guided MCP fix flow and adds per-version monitoring toggles.

3. The Kotzilla MCP Server (1.11.1) adds impacted-population analysis (users, devices, OS versions) and per-version data gating.

The  release at a glance:

• Continuous startup metrics: a cold/warm startup metric on every launch, plus a mark() API to time your own phases (SDK 2.3.0).
• Early start: startup and crash timing captured from the first millisecond of the process (SDK 2.3.0).
• Universal consent gate: hold all telemetry until the user opts in, off by default (SDK 2.3.0).
• Guided fixes: Issue Details hands off to the MCP Server for a fix in your editor (Console 4.12.0).
• Impacted-population analysis: see which devices and OS versions an issue hits, down to the session (MCP Server 1.11.1).
• Per-version monitoring: turn data collection on or off per app version, from the Console or your assistant.

If you ship an Android or Kotlin Multiplatform app, this release touches three things you deal with every week: Android startup performance, respecting user consent, and knowing which devices, OS and users an issue actually affects.

Here's what shipped and how to use each piece.

Kotzilla SDK 2.3.0

SDK 2.3.0 focuses on Android startup performance: better startup data, a way to time your own phases, and earlier capture. It also adds the consent gate.

A continuous startup metric on every launch

Kotzilla already detected cold and warm startup issues. What's new in 2.3.0 is that every launch now produces a startup metric (duration plus launch source, Android for now). So instead of only hearing about a startup when it's already a problem, you get a continuous signal you can trend over time and across versions.

You don't add anything for this. Upgrade, rebuild, and the per-launch data starts flowing from real production sessions, already labelled by how the app was started.

Time your own phases with mark()

Automatic numbers tell you that startup is slow; they don't always tell you where. So there's a new API for marking your own phases:

            
                   
 
// Time a specific startup phase on your own track

mark(label = "feature_flags_loaded", track = "startup")
            
      

Drop a couple of these around the work you suspect (flag hydration, first network call, database open) and the phases line up against the automatic startup metric. Now "startup is slow" becomes "startup is slow here."

Note: the full startup tracing reference lives at Startup tracing.

Early start: timing from the first millisecond

The enabler behind the two features above: the SDK now starts automatically at process start, before Application.onCreate on Android, before main() on iOS, and on first SDK reference on the JVM. It's on by default and can be disabled globally or per platform.

Why it matters: crashes and startup timing are captured from the earliest possible moment, even before your monitoring() call runs. If your app dies during initialization, that used to be exactly the window you couldn't see. Now it's covered. (Details: Automatic start.)

A universal consent gate, off by default

The SDK's other headline change is about privacy. Plenty of teams can't collect a single byte until the user opts in, which until now often meant bolting the SDK's lifecycle onto your own consent logic and hoping the edges lined up.

2.3.0 lets you gate the entire SDK behind explicit consent:

            
                   
 
kotzilla {

    consentRequired = true   // gate everything behind opt-in
}
            
      

Then record the user's decision when they make it:

            
                   
 
KotzillaSDK.setConsent(KotzillaConsent.GRANTED)   // or NOT_GRANTED
            
      

The behavior is the reassuring part. Until a decision is recorded, the SDK buffers telemetry locally and sends nothing. On grant, the buffer is replayed so you don't lose the session. On refusal (or a later forgetMe()The buffer is wiped, along with in-flight uploads and native crash files.

Note: the gate is off by default, so upgrading from 2.2.x changes nothing until you opt in. See Privacy & user consent.

Kotzilla Console 4.12.0

The Console side of this release reworks Issue Details around the metrics that matter and a guided MCP resolution flow, and adds per-version monitoring controls.

Issue Details now hands off to a guided fix

Console 4.12.0 reworks Issue Details to lead with the metrics that matter for each issue, then hand off to the Kotzilla MCP Server for resolution. So you go from an issue in the Console to a guided fix in your development environment, with performance status handled consistently across screens and issues.

Per-version monitoring toggles

Application Settings now lets you enable or disable monitoring per app version. Controls are read-only when you don't have permission to change them, and an inactive version shows a clear paused banner. The practical win: stop paying to ingest noise from an ancient version nobody's on, and keep your dashboards focused on what's actually shipping. (The same control is available from the MCP Server, below.)

Timeline session summary

The Timeline session summary now carries more metadata and SDK properties, adds an event thread display, and cleans up duration and scope-ID formatting.

Kotzilla MCP Server 1.11.1

The MCP Server adds impacted-population analysis and per-version data gating, so your AI assistant can tell you who's affected by an issue and control what the platform ingests.

See who is impacted, down to the session

A crash count is a number. It doesn't tell you whether it's one specifc Pixel device or half your Samsung users on Android 14. That difference decides what you do next.

Ask your AI assistant about an issue and it now returns the exact population behind it: which devices, which OS versions, and how many production sessions each one hit. get_issue_context returns that breakdown plus a list of impacted sessions sorted by worst or most recent, and you can filter issues, screens, and issue context by device or OS. From there you drill straight into the worst session's timeline.

Per-version data gating

The same per-version control from the Kotzilla Console works directly from your assistant. list_app_versions reports each version (whether it's ingesting data and whether it has a mapping file), and set_app_versions_enabled turns ingestion on or off, so you can prune noise without leaving your editor.

Putting it together: chasing a slow cold start

Say cold start regressed in your latest release. Here's how the pieces work together:

1. The automatic startup metric surfaces the regression on the new version in the Console.
2. Open Issue Details and hand it off to the Kotzilla MCP Server. Your assistant root-causes the issue against real session data and proposes a fix in Android Studio.
3. In the same pass, it tells you who's affected. get_issue_context breaks the issue down by device and OS version, so you know whether it's one device or half your users.
4. Apply the fix, ship the new version, then turn off monitoring on old versions with set_app_versions_enabled to keep only the last two.

And all of it runs on data your users agreed to: with the consent gate on, nothing leaves the device until they opt in.

From a metric in the Console to a fix in your editor, with a clear read on who the issue actually hits.

Frequently asked questions

What's included in the Kotzilla July 2026 release?

Three components. SDK 2.3.0 (continuous startup metrics, the mark() API, early start, and a consent gate), Console 4.12.0 (reworked Issue Details with a guided MCP fix flow, per-version monitoring toggles, and a richer Timeline session summary), and MCP Server 1.11.1 (impacted-population analysis and per-version data gating).

What's actually new about startup in SDK 2.3.0?

Kotzilla already detected cold and warm startup issues. Three things are new in 2.3.0: a continuous startup metric on every launch (not just ones that trip a threshold), a mark(label, track) API for timing your own startup phases, and early start, which captures timing from the first millisecond of the process. Upgrade the plugin to 2.3.0 and rebuild to get the per-launch metric; add mark() calls only where you want phase-level detail.

What's the difference between cold and warm startup?

A cold start is when the app launches from scratch and a new process is created; a warm start reuses an existing process, so it's faster.

Kotzilla automatically labels each launch, so you can track them separately in production.

Does upgrading to SDK 2.3.0 change my existing setup?

No. The universal consent gate is off by default, so upgrading from 2.2.x changes nothing until you opt in with consentRequired = true. Automatic start is on by default and can be disabled globally or per platform.

How do I stop the SDK from collecting data until a user consents?

Set consentRequired = true in the kotzilla { } block, then record the decision with KotzillaSDK.setConsent(KotzillaConsent.GRANTED) or NOT_GRANTED. Until a decision is recorded, telemetry is buffered locally and nothing is sent; on refusal or forgetMe(), the buffer and any in-flight uploads and native crash files are wiped.

How do I see who an issue impacts?

Ask your AI assistant through the Kotzilla MCP Server. get_issue_context returns the population behind an issue broken down by device and OS version, with production session counts and a list of impacted sessions sorted by worst or most recent, so you can drill straight into the worst one.

Which versions does Kotzilla SDK 2.3.0 support?

It's verified against Kotlin 2.4.x, AGP 9.2.1, Gradle 9.6.0, Jetpack Compose BOM 2026.06.00, and Compose Multiplatform 1.11.1.

What's next?

Upgrade the SDK, rebuild, and the startup metrics start on their own:

            
                   
 
id("io.kotzilla.kotzilla-plugin") version "2.3.0" apply true
            
      

Kotzilla 2.3.0 is verified against Kotlin 2.4.x, AGP 9.2.1, Gradle 9.6.0, Jetpack Compose BOM 2026.06.00, and Compose Multiplatform 1.11.1.

From there, decide whether you want the consent gate on, add a few mark() calls around your riskiest startup phases, and next time someone asks why cold start is slow, you'll have the numbers instead of a guess. The full details are in the release notes and the SDK changelog.