ANRs and slow screens are now detected automatically and ranked as Critical issues, with a single click from a Dashboard metric to the exact component to fix, and your AI assistant can apply the fix based on real session data.
Compose render timing is now measured on-device, the SDK is hardened so it never crashes or slows your app, and SDK setup can be done automatically by the Kotzilla MCP Server. Live now for any Android or Kotlin Multiplatform app using Koin.
ANRs and slow screens used to take digging to find. Now they surface on their own: both are detected automatically and ranked as Critical issues, Kotzilla's top-severity tier, in the Issues View ordered by how many user sessions each one affects. The list reads as a single prioritized view of what's hurting your users most.
An ANR (Application Not Responding) is what happens when your app's main thread is blocked too long. On Android, Kotzilla flags any stall longer than 2 seconds.
The ANR-free rate on your Dashboard is now clickable: it opens the Critical Issues view filtered to the ANRs behind the number.
New apps registration in the Console now start with a setup-choice screen.
Pick the recommended MCP-guided flow and a single prompt to your AI assistant registers the app and applies every SDK change for you: the version-catalog entries, the Gradle plugin, kotzilla.json, and the monitoring() call in your Koin setup. Straightword manual step-by-step setup is still there if you want it.
Connecting the MCP server takes a few lines in your assistant's config:
Your slow-screen rankings are now measured on-device with a monotonic clock from the moment a screen is created, instead of being inferred from server-side timestamps that drifted with clock skew and batching. The numbers you act on are the ones your users actually experienced, so you spend time on real regressions, not measurement noise.
Each screen now reports two of them:
This works identically for Navigation 2 and Navigation 3, with no new fields in the event payload. While developing, turn on debug logs to see the per-screen breakdown in Logcat:
A monitoring SDK should never be the reason your app misbehaves. This release hardened every point where the SDK touches your app so it absorbs its own errors. Network failures (DNS, offline, timeout, TLS) are handled quietly instead of surfaced as errors, the connection retries with jittered backoff and reconnects after a drop, and the SDK never crashes or slows the app it's measuring.
Crash reports also carry more context now, including the last resumed screen at the moment of the crash, and a back-navigation fix means your session counts are no longer inflated.
Before: rebuilding the same version name overwrote the previous mapping file, leaving component names and crash stack traces only partly readable.
Now: a single app version can hold multiple mapping files, each tied to a per-build Build ID. On Android this is per-variant, so a release build and a minified staging build no longer overwrite each other's mappings, and every signal (component names, dependency names, crash stack traces) resolves to the exact build that produced it. You can also download any mapping file by ID from the Console.
Before: early-lifecycle dependency work (the startKoin, module-load, and eager-singleton resolutions that run during Application.onCreate) could appear after the first screen event, because Koin events were numbered when the SDK drained its buffer rather than when they happened. Startup analysis got muddled as a result.
Now: every event is sequenced at the instant it occurs, so the timeline matches wall-clock order across the Koin and screen boundary. Startup and screen-rendering analysis attribute the right work to the right phase. This is a recommended upgrade, with no API or configuration changes.
This video shows it end to end. The Console drills from a slow screen down to a single MainViewModel resolution blocking the main thread for ~700ms. Then, inside Android Studio, Claude Code (via the MCP server) is asked "what is the main blocker of my app?", finds the same root cause, and proposes the fix: move work out of the ViewModel constructor and inject the repository lazily.
If you already run the Kotzilla SDK, this is a recommended upgrade: bump to the latest version and rebuild. There are no API or configuration changes.
New to Kotzilla? The fastest path:
How does Kotzilla detect ANRs and slow screens?
Kotzilla instruments your app at the Koin dependency-injection layer through a single-line SDK, records real user sessions, and automatically flags ANRs (main-thread stalls longer than 2 seconds) and slow-rendering screens, ranking them as Critical issues by the number of impacted sessions.
What are Critical issues in Kotzilla?
Critical issues are Kotzilla's top-severity findings: crashes, ANRs, slow screens, cold and warm startup performance, and main- and background-thread performance. They appear in the Issues View and are the problems Kotzilla flags to fix first.
How is Kotzilla different from Firebase Crashlytics or Sentry?
Kotzilla works at the dependency-injection layer through Koin, so it maps a crash or slowdown to the exact component and dependency graph involved rather than monitoring the app as a black box. That architectural context is what lets its AI assistant propose accurate, code-level fixes instead of generic suggestions.
Does the Kotzilla SDK slow down or crash my app?
No. As of the June 2026 release, the SDK absorbs its own errors, handles network failures quietly, retries with backoff, and is built so it never crashes or slows the app it monitors.
Which platforms does Kotzilla support?
Android and Kotlin Multiplatform, including iOS, Desktop (JVM), JavaScript, WebAssembly, and Compose Multiplatform, all from a single SDK setup.
Is Kotzilla free to start?
Yes. You can create a free account and explore a sandbox before integrating the SDK into your own app.