Diagnostics & Renderer Audit
Kanvas has two different diagnostic layers because build/toolchain correctness and renderer correctness are different problems.
kanvasDoctor
Doctor answers questions such as:
- is the JDK usable?
- are JNI headers available?
- is CMake new enough?
- is a native compiler available?
- is the selected backend valid on this host?
- did Kanvas resolve the intended Gradle project and tasks?
- are runtime artifacts available or buildable?
The checks are implemented in KanvasPlugin.kt.
A missing native compiler is a blocking condition. A runtime version outside the best-tested range may only be an unverified condition. Treating both as fatal would make the tool less useful and would confuse "cannot work" with "not yet certified."
Renderer audit
The Java agent writes renderer-level events such as:
START
RUNTIME_SOURCE ...
COMPOSE_SCENE_LOADED ...
DEFAULT_RENDERER_INTERCEPTED ...
TRANSFORMED_SKIKO_FRAME ... mode=picture-replay
...
END
Source: KanvasAgent.java
The Gradle plugin places the audit output under:
build/kanvas/renderer-audit.log
when auditing is enabled.
Build files describe dependency intent. The audit log records the classes and code sources that actually participated in rendering. For ABI-sensitive instrumentation, the second fact is usually the one that matters.
Why audit runtime code sources?
Compose/Skiko compatibility problems are often classpath problems.
Recording the actual code source for interesting runtime classes answers a much more useful question than "what version did the build file say?":
Which JAR actually supplied the class that executed?
That matters when dependency resolution, transitive artifacts, or plugin-managed versions differ from what a developer expected.
Debugging order
Use this order:
1. kanvasDoctor
2. kanvasCompatibility
3. renderer-audit.log
4. strictRenderer = true
5. backend-specific investigation
This keeps environment failures from being mistaken for renderer bugs.