Modern Android apps are composed of dozens (or hundreds) of modules, each containing components such as ViewModels, Repositories, Services, and more. These modules interact across feature boundaries, scopes, and threads.
As your architecture scales, so does the risk of hidden performance issues or subtle issues that only surface in some specific devices in production.
The Kotzilla SDK is built to give Kotlin developers using the Koin framework a clear, high-fidelity view of what’s really happening in your apps at runtime without requiring access to your implementation logic or user data.
In this article, we’ll break down exactly what the SDK collects, how it handles data, and why your code remains private and secure whether you're debugging locally or in production.
The SDK is designed to monitor your app components (e.g., ViewModels, Activities, and Fragments) and their dependencies. It observes how these components behave across threads and lifecycles in real time.
It helps you detect issues like:
The SDK works in the background without requiring manual traces or code modifications. It operates in both development and production environments and is tightly integrated with Koin, using its container as a signal source.
Let’s say you release an update, and suddenly, users start reporting performance issues.
You open the Kotzilla Console (or check directly from Android Studio via the Koin Plugin) and immediately see an issue:
Main Thread Performance Issue
Component:
com.google.samples.apps.nowinandroid.MainActivityViewModel
Resolution is blocking the main thread
No guesswork. No additional tracing needed. The SDK has already identified:
Digging deeper into one of the impacted user sessions, you see that the real issue isn’t the ViewModel
itself, but one of its dependencies, the UserRepository
performing a heavy operation on the UI thread.
You now have a precise, actionable diagnosis: offload that logic to a background thread, prevent the UI freeze.
The Kotzilla SDK collects technical metadata about how your components and dependencies behave at runtime. This includes:
Activity
, Fragment
, etc.)This gives your team precise visibility into the runtime characteristics of your app without requiring manual tracing.
To be explicit, here’s what the Kotzilla SDK does not collect:
✅ Collected | ❌ Not Collected |
---|---|
Class/type metadata | Method bodies or source code |
Dependency resolution stats | Business logic |
Component lifecycle events | User data: only device type, OS version and app version is captured |
Thread + performance signals | Internal algorithms or logic |
In release builds, all class and method names are obfuscated by tools like R8 or ProGuard. These mapping files are used to map the obfuscated names back to their original, readable versions. The mapping files must be properly configured and uploaded.
The Kotzilla SDK meets modern security and data protection requirements:
The Kotzilla SDK gives you deep runtime visibility into how your app’s components behave without compromising code privacy.
It captures technical metadata, not business logic to identify issues related to components or dependencies resolution delays, thread misuse, and complex dependency graphs. In production, class names are obfuscated by default, and uploading mapping files is entirely under your control.
With secure, encrypted communication and zero user data collection, the SDK is built to support high-trust environments from early development to post-release debugging.
If you’re maintaining a large Kotlin codebase, you are using Koin and need actionable insights without exposing sensitive logic, the Kotzilla SDK is built for that job.