Test-Failure-to-Root-Cause Automation
From Test Failure to Root Cause — In Minutes
CTS/VTS debugging means manually bridging test results, device logs, and upstream patches. logcat.ai replaces that entire workflow, correlating failures with device state and surfacing Gerrit fixes automatically.
Three Disconnected Worlds. One Massive Workflow Problem.
Every CTS/VTS failure forces engineers to manually bridge three completely separate information sources. Today, that bridging is done with grep, timestamps, and hours of Gerrit archaeology across 2M+ test cases.
Test Results
The CTS XML says FAIL. It gives you a test name, maybe a stack trace. No device context. No system state. No explanation of what actually happened on the device during the test.
Device Logs
The 100MB+ bugreport contains the answer, buried somewhere in logcat, dmesg, and dumpsys output. You have to manually correlate timestamps between the XML failure and the device log to find the relevant events.
Upstream Fixes
AOSP Gerrit may already have a patch that fixes your exact failure. But finding it means manually searching commit history, reading changelogs, and cross-referencing test names with code changes. Per failure.
logcat.ai bridges all three worlds automatically. Upload the XML and the logcat. Get correlated root causes with Gerrit patches in minutes, not hours.
Before vs After
The workflow transformation for every failing CTS/VTS module
Run CTS suite, wait for completion
Grep XML for FAIL results across modules
Open logcat, manually search for timestamps matching each failure
Read through thousands of log lines looking for relevant errors
Manually search Gerrit for each failure pattern
2+ hours per module, repeated across dozens of modules
Total time: 2+ hours per module
Upload CTS XML + device logcat
logcat.ai correlates every failure with device state automatically
Root causes categorized: device config, test bug, framework regression
Gerrit patches surfaced with status, links, and relevance
5 minutes per module, regardless of failure count
Total time: 5 minutes per module
What We Detect
AI-powered categorization of test failure root causes
Test Code Bugs
Missing capability guards, incorrect resource paths, broken assumptions in AOSP test code, with Gerrit patches that fix them.
Device Configuration Gaps
Missing codecs, unconfigured permissions, absent hardware capabilities that cause failures unrelated to code quality.
Framework Regressions
Android framework behavior changes between versions that break test expectations. Delta pinpoints the version where the regression appeared.
Environment Issues
Missing test media files, harness misconfiguration, incomplete test setup: issues that waste debugging time but have simple fixes.
Supported Test Suites
Full coverage across the Android certification ecosystem
Compatibility Test Suite
Vendor Test Suite
Google Test Suite
Security Test Suite
CTS on Generic System Image
Cross-File Test Correlation with Delta
Delta correlates CTS/VTS result XML with device logcat to connect test outcomes with runtime evidence. Compare passing vs failing builds to isolate regressions.
Delta Correlation Engine
Multi-file cross-layer analysis
Upload multiple log files for comparison
Part of the logcat.ai Platform
CTS/VTS analysis uses the same Deep Research and Delta engines that power bugreport analysis, dmesg debugging, and cross-build comparison across the entire logcat.ai platform.
Use Cases
How teams use CTS/VTS analysis to accelerate certification
Pass CTS/VTS for device certification. Quickly identify whether failures are device issues or known AOSP test bugs, with Gerrit patches ready to cherry-pick.
Validate custom ROMs and BSP integrations against CTS requirements across multiple device variants. Delta compares results across variants to isolate BSP-specific failures.
Catch regressions introduced by firmware updates before they reach certification. Delta compares pre- and post-update CTS runs to flag new failures instantly.
Analyzers behind the triage
Every artifact a failed test drops has its own analyzer to drill into.
Crashes, ANRs, and 30+ sections from an Android bugreport.
Root cause from a raw logcat stream, cited to the line.
Kernel panics, oopses, and driver faults from dmesg.
Cross-file correlation across a whole diagnostic archive.
Jank, startup, and scheduling from a Perfetto trace.
Crash root cause from a kernel ramdump, no logs needed.
Common questions
Frequently Asked Questions
Common questions about CTS/VTS test analysis.
XML result files from CTS, VTS, GTS, STS, and CTS-on-GSI. Upload the test_result.xml alongside the device logcat from the test session.
Deep Research cross-references test failures against AOSP's public commit history to determine whether a fix already exists. If a relevant patch is found, merged or in review, it surfaces in the analysis report with status, authorship, and a direct link. You get the answer without the manual Gerrit archaeology.
Yes. You'll get test result analysis, but without logcat correlation the root cause analysis will be limited to what's in the XML (failure messages and stack traces). For full root cause analysis, upload both the XML and the device logcat.
Currently optimized for standard Android test suites (CTS/VTS/GTS/STS). Custom test frameworks can be uploaded as unstructured text.
Up to 100MB per file. Large CTS result XMLs with thousands of test cases are supported.
Stop Bridging Three Worlds Manually
Upload your CTS/VTS results and device logs. Get correlated root causes with Gerrit patches, in minutes, not hours.