How to Stop AI from Hallucinating AAOS VHAL Properties

Whether Android Automotive OS (AAOS) is your daily focus or you’re an Android developer entering the automotive space for the first time also welcome.

This post is for you, because eventually, both groups run into the exact same problem: AI coding assistants are incredibly useful, but the moment AAOS and VHAL details enter the conversation, their answers tend to drift away from reality.

(If you prefer to skip the story and jump straight to the code, here is the GitHub repository.)

A Quick Primer

Before diving into the problem, let’s establish some basic groundwork:

• AAOS (Android Automotive OS): Android running independently as a vehicle’s infotainment platform.
• VHAL (Vehicle Hardware Abstraction Layer): The critical layer connecting Android-side software requests to actual vehicle behavior.
• The Hardware: Behind the VHAL sits the real physical hardware — Electronic Control Units (ECUs) and in-vehicle networks like CAN or LIN.

Most app developers never interact with those physical systems directly, but the Android platform still needs a reliable way to map software requests to vehicle capabilities. That mapping is where the VHAL matters.

The Practical Problem

If you search for general Android development resources, you will find millions of results. Most of them are excellent for phones and tablets. However, far fewer are useful when your feature depends heavily on specific vehicle properties.

That is where automotive workflows slow down. You ask an AI assistant for help, receive a highly confident answer, and only later discover that the suggested property names were entirely fabricated.

For example, a property like CAR_WIPER_SPEED_SUPER_FAST_MODE sounds perfectly plausible. It just isn't real.

When this happens, you lose valuable time trying to validate the fundamentals:

• Which properties are actually available?
• Which ones are restricted by permissions?
• Which ones are OEM-specific and purposefully not part of public documentation?

Cars are not just phones with bigger screens. They are highly physical, context-rich environments. Imagine building a media app: on mobile, you optimize for familiar signals like screen taps and watch time. In AAOS, you might incorporate in-cabin context and vehicle state (depending on permissions, vehicle configuration, and OEM implementation). This opens up entirely new, immersive product experiences.

But that upside only works when your tooling is grounded in actual, documented properties.

The Solution: aaos-vhal-skills

To reduce these VHAL hallucinations and ground AI prompts in official references, I created aaos-vhal-skills.

This repository contains the official, Google-defined DEFAULT and SYSTEM properties for Android 14 and Android 15. I've packaged them into practical instruction assets (SKILL.md rules and reference files) that you can plug directly into your AI assistant workspace, whether you're using GitHub Copilot, Cursor, or another AI IDE.

Why Use It?

1. Grounded Reality: Start with Google-defined property sets as your baseline source of truth. Build your architecture from these reliable references first, then expand carefully as your use case matures.
2. Built for OEMs: Google’s documented standard sets are only part of the picture. Most OEMs maintain custom VENDOR properties that remain internal. That’s why this repository also includes an oem-vhal-skills-template. It provides a starter kit for auto makers to explicitly document their internal properties as a Skill for internal or external, allowing their internal/external partner teams to avoid repeating the same discovery work every release cycle.

Wrapping Up

AAOS development is already complex enough; our tooling should reduce friction, not add more of it. If this project saves you from debugging even one hallucinated property, it has achieved its purpose.

Check out the repo here: feevlic/aaos-vhal-skills

If it helps your workflow or saves you some headaches, a star on GitHub is always appreciated!

— Feevlic