Why Android Automotive Debugging Is Broken — And What Nobody's Talking About

I’ve spent 13 years deep inside the Android OS. Building custom ROMs as a teenager, contributing to LineageOS, shipping enterprise device management at scale. I thought I’d seen every category of Android bug there was.

Then I started looking at Android Automotive.

A $30 Billion Blind Spot

Here’s a number that should make every automotive software leader uncomfortable: 55% of vehicle launches are delayed, and software integration is the primary bottleneck. Not mechanical. Not electrical. Software.

And when vehicles do ship, the software problems follow them. In 2024, 13.4 million vehicles were recalled for software-related issues — a 4x increase from the year before. Software recalls now account for nearly half of all vehicles recalled.

The industry knows this. What it hasn’t fully reckoned with is why.

The Layer Nobody Can See

Android Automotive OS is an incredible piece of engineering. Google built a full-stack operating system that lets OEMs like GM, Volvo, Ford, BMW, Rivian, and a growing list of manufacturers build software-defined vehicles on a common platform.

But there’s a layer in that stack — sitting between the Android framework your apps talk to and the vehicle hardware that actually controls your car — where bugs go to hide.

I’ve spent months researching this layer. Analyzing academic security studies. Digging through developer forums. Talking to engineers who live in this space every day. Mapping the architecture of how a single vehicle speed reading travels from a wheel sensor through CAN bus, through multiple ECUs, through an abstraction layer, through Android services, and finally to the number you see on your dashboard.

What I found is that the tools engineers use today give them visibility into pieces of this journey — but never the whole thing. And that gap is where the most expensive, most time-consuming, most dangerous bugs live.

Here’s a way to think about it if you’re not in automotive: Imagine your sales team uses Salesforce, your engineering team uses Jira, and there’s a custom integration layer syncing data between them. Deals stop closing. Sales sees “Opportunity lost” in Salesforce. Engineering sees “No issues logged” in Jira. The integration layer silently dropped the customer complaint — and no single tool shows you its logs. That’s what debugging Android Automotive feels like today. The layer in the middle is invisible.

The Problem With “Works on My Emulator”

One of the most striking findings from the academic research I reviewed: security testing that passes on Google’s reference implementation can produce wildly different results on actual production hardware. Same test. Same harness. Completely different outcomes.

This isn’t a flaw in anyone’s testing — it’s a structural reality of how the ecosystem works. And it means that “passing tests” doesn’t mean what most people think it means.

I’ll leave it at that for now.

What 4-40 Hours Should Look Like

Today, debugging a cross-layer integration issue in Android Automotive takes anywhere from 4 to 40 hours depending on complexity. Some categories of bugs routinely take engineers 12-24 hours of trial-and-error across multiple expensive toolchains just to identify the root cause — not even fix it.

I’ve documented specific patterns where bugs manifest in one layer but originate in another, and where no single existing tool can connect the dots. Configuration mysteries. State machine desynchronizations. Phantom data that persists when it shouldn’t.

These aren’t edge cases. These are patterns that show up repeatedly in production.

What We’re Building

This is why I built logcat.ai.

We started with AI-powered Android bugreport and log analysis — our Deep Research engine already helps engineers get to root cause in minutes instead of hours. Now we’re going further.

Introducing Delta: Multi-File Correlation Analysis

Today’s debugging workflows force engineers to stare at logs from different tools in different windows, manually aligning timestamps, hunting for the moment where one system’s output explains another system’s failure.

Delta changes that.

Upload multiple log files — bugreports, logcat captures, dmesg, kernel logs, CAN traces (.asc, .blf, .trc, .mf4, .csv), candump logs, DBC-decoded signal exports, and more — and Delta correlates events across them temporally and causally. It doesn’t just search for keywords. It understands the relationships between events across layers and identifies the causal chains that connect a symptom in one file to a root cause in another.

And if you’ve worked with CAN bus data, you know the scale of what we’re talking about. A single vehicle recording session can generate 1-10 GB+ of CAN trace data — thousands of signals firing at up to 100 Hz across dozens of ECUs. Manually sifting through gigabytes of raw CAN frames to find the 50ms window that explains an HMI crash is not a reasonable ask of any engineer. Delta is built to handle this scale.

For Android Automotive engineers dealing with multi-layer integration bugs, this is the beginning of the cross-layer visibility the ecosystem has been missing.

Delta launches in the coming weeks as an early access feature for Pro subscribers and above. And for teams working with automotive-scale data — where a single debug session can generate gigabytes of CAN traces, bugreports, and kernel logs — we’ll be announcing a dedicated pricing tier with file limits built for the reality of vehicle software debugging. Stay tuned.

We have bigger plans for where this goes. Much bigger.

The Research Paper

I’ve written a comprehensive technical research paper documenting everything: the architecture, the gaps, the academic evidence, the real-world patterns, and the technical requirements for fixing this.

“Cross-Layer Observability for Android Automotive: Bridging the VHAL-CAN Diagnostic Gap” is available to select automotive engineering teams, security researchers, and OEM partners.

If you’re building on Android Automotive and want access, reach out: varun@logcat.ai

What’s Next

The future of automotive software quality depends on visibility across layers, correlation across domains, and AI-powered insights that help engineers ship faster and safer.

If you’re an OEM engineer, a Tier-1 integrator, or a security researcher — give us your hardest bug. We’ll show you what cross-layer correlation looks like.

Try logcat.ai →

Varun Chitre is the founder of logcat.ai, a Staff Software Engineer with 13+ years in Android OS and embedded Linux, and a founding engineer at Esper.