On a quiet day in March 2026, Google’s announcement shook the automotive world…but in a good way.
Android Automotive OS (AAOS), the operating system that powers nearly 62% of all automotive infotainment systems; was now configured to become a standardized framework that extended to other non-safety critical functions of the vehicle.
Apart from infotainment, the software evolved to handle – seating, cluster, climate control, lighting, cameras, mirrors, vehicle telemetry and SOME/IP (for inter-ECU communication).
With this announcement – Android Automotive for Software-Defined Vehicles’ (AAOS SDVs) release was official.
Car makers could now lean more on Google to accelerate vehicle software development.
Using this to be open-source software, the automotive industry could take one giant leap into realizing the full potential of the concept – software defined vehicles (SDVs).
This blog breaks down the evolution from AAOS IVI to AAOS SDV, and helps automotive software developers understand how to start migrating towards it.
Why Google Extended AAOS Beyond the Screen
The answer to the above question lies in the problems associated with the traditional AAOS i.e., AAOS IVI.
The AAOS IVI software stack handled the tasks that run screen-facing experiences, that include:
- Navigation
- Media
- Voice assistants
- and other 3rd party applications.
Google’s infotainment OS runs on JVM (Java/Kotlin) and uses heavy graphics components such as SurfaceFlinger to execute screen-facing experiences.
As the vehicle evolved, the infotainment system’s responsibility increased.
It became the control center of multi-domain features such as HVAC, seating, lighting control, in-vehicle personalization and more.
This meant, users could interact with the in-vehicle infotainment system to fetch & display data about tire pressure, cabin temperature and more.
ECUs responsible for the above functionalities – had to work with each other and speak the same language.
These ECUs put out data onto the vehicle’s CAN/LIN network. However, the data exposed was in its own proprietary format, each with unique signal names and encoding.
The traditional AAOS IVI lacked a unified abstraction layer to translate these signals into a standard API.
As a result, the cohesion between the ECUs diminished & became fragmented.
Imagine a scenario where developers were tasked with building a feature that combined the functions of climate and body control ECU.
In the traditional AAOS IVI system, developers had to:
- Manually decode each ECU’s raw signal format,
- Write custom mapping code and
- Repeat for every new feature and ECU supplier.
Other issues with the traditional AAOS IVI include poor portability between architectures and its lack of granular OTA update capability.
AAOS SDV is Google’s attempt to close these gaps.
Inside the AAOS SDV Architecture
Virtual Machines (VMs) take the Center Stage
AAOS for software-defined vehicles is built from the ground up to isolate safety-relevant rendering paths across multiple virtual machines (VMs).
This creates a headless Android core that runs inside VMs that hosts vehicle functions like body control, cluster, infotainment, lighting and seating.
VM-to-VM or Inter-VM communication is standardized using VirtIO – an open-source framework and protocol for virtual machines.
While VMs handle the software layer, VirtIO acts as an efficient software interface that reduces hardware emulation overhead for storage and network I/O. The virtual hardware components in the latest release of AAOS are as follows:
| Virtual Device Name | What it does? |
| virtio-scsi | Allows the guest VM to access block storage devices. |
| virtio-net | Enables the VM to send/receive network traffic effectively. |
| virtio-blk | Allows the guest to access basic storage, a lighter version of virtio-scsi. |
| virtio-snd | Handles audio input/output for the VM guest. |
| virtio-gpu | Enables the VM to render graphics relevant to AAOS SDV cluster and IVI. This virtual hardware is essential to handle mixed-criticality rendering. |
| virtio-video | Handles video encoding/decoding and camera-style video streams. |
Automakers can seamlessly deploy the new headless AAOS as guest VM under their existing, production proven QNX/OpenSynergy hypervisors with zero near-term rework.
Vehicle Services Interface Definition Language (VSIDL)
AAOS SDV contains a standard signal catalog and a common service definition language “Vehicle Services Interface Definition Language†(VSIDL).
VSIDL is a blueprint language that tells the vehicle’s software services:
- What a service’s interface should look like
- What data does it exchange
- How the service gets discovered (name of the service), deployed and managed
This is done by specifying:
- Service unit interfaces
- Communication patterns per service – via Remote Procedure Call (RPC) or Data Tunnel
- Data structures via protocol buffers
- Service discovery registrations – a VSIDL complier code that automatically handles registering each service unit to make it findable by name.
Using VSIDL, developers can replace repeated, bespoke signal mapping with named services with defined interfaces. This helped developers move on from a signal-oriented feature call-up to a service-oriented design.
In a multi-program world, automotive software developers who integrate VSIDL can shorten integration cycles and make the supplier more attractive to OEMs looking for scalable software components.
Service-Oriented Design to Enhance Code Reusability Across Vehicle Trims
This shift from signal-oriented to service-oriented design pays off most visibly at the trim level.
A base trim and a premium trim of the same vehicle rarely share identical hardware.
Previously, that hardware difference meant rewriting integration code for each trim, since an app was wired directly to a specific ECU’s signal mapping.
With a service defined once through VSIDL, the app instead calls “seat heating†or “cabin temperature†without knowing which hardware implements it.
So, if the premium trim has the service and the base trim doesn’t, that’s simply a configuration difference, not a rewrite.
The same application code runs unchanged across the full trim lineup, and the integration cycle a supplier used to repeat for every trim becomes a one-time service definition instead.
Display Safety and Mixed Criticality Rendering for Instrument Cluster
Rendering and displaying timely information on instrument cluster is a unique challenge addressed by AAOS SDV.
Digital instrument cluster is an interface that displays both rich Android graphics and safety critical information on the same screen.
Time critical information such as gear indicator, speed reading and telltale signs shouldn’t lag just because the infotainment VM is rendering navigation animations.
AAOS SDV handles this using a dedicated framework called Display Safety. It consists of:
- High Availability Renderer (HAR): Handles low latency renders for the digital instrument cluster animations such as gear, speed, and telltales. HAR does not handle any infotainment system rendering.
- Safety Design Complier and Monitor toolchain: Verifies if safety-critical visual elements comply with required display layout standards.
- Android Cluster Content: Builds the visual layer on the cluster screen. It takes the infotainment content and layers it together with the safety-critical elements rendered by HAR.
Virtual Cockpit Software Integration with Cuttlefish Digital Twin
From Android 17 onwards, meaningful software integration can occur even before the automotive silicon arrives.
How?
- Cuttlefish – a virtual device/digital twin that emulates full multi-VM environment in the cloud or local machine i.e., a digital twin of the vehicle’s compute environment.
- Android Studio for Platform (ASfP) provides the tool to develop Rust-based services and deploying them on the digital twin’s environment.
AAOS SDV Migration: Steps for Active Digital Cockpit Programs
AAOS SDV is new and promising, how do OEMs with existing programs get started with it?
Developers must select, download, build and run the right version of code. Here’s a walkthrough in the process:
- First, access Google’s AOSP source servers from android.googlesource.com.
- Select the version -b android-17.0.0_r1 under groups=default,swcar. Adding the swcar brings the SDV-specific code on top of the standard Android build.
- Sync the repository to download everything, including 4 other repos that come specifically with the SDV group.
- Set up the build environment, then choose a build target aimed at Cuttlefish, rather than physical hardware.
- Build the code.
This enables developers to:
- Run complete simulation of the instrument cluster and infotainment,
- Validate the simulations and cockpit performance,
- Implement CI/CD development loops in the cloud,
much before physical vehicle hardware prototypes are manufactured.
So, existing cockpit programs that run on QNX and AUTOSAR can remain unchanged until developers fully evaluate Google’s SDV platform’s feasibility, virtually.
Using AAOS SDV’s approach, developers can validate first, migrate later.
Adopting AAOS SDV: What to Do Now Vs What Can Wait?
Along with derisking the implementation of the platform itself, validating also sets up how the migration happens.
If the OEM decides to migrate to AAOS SDV, there are four decisions they must make. Two to get started, two for long-term.
What to do NOW?
- Connecting AAOS SDVs to vehicle systems happens once at a time
- Maintaining Communications with unchanged systems
Each system, cluster, infotainment, body control, seating, etc, needs a separate connection into the SDV platform. These connections get built one at a time. Start with one system of your choice.
When the migrated components come online, they still need to communicate with unchanged vehicle systems. Set up a communication bridge that ensures systems -old and new can work together during the transition.
To maintain this, add SOME/IP service catalog for AAOS SDV services and align them to AUTOSAR Adaptive services already in the vehicle.
Then connect legacy ECU services via SOME/IP broker.
What can WAIT?
- Changing the Existing Hypervisor
- Replacing the Body-Control Software
AAOS SDV’s VMs are supervised by the hypervisor. Existing systems using QNX as a hypervisor can directly integrate the new AAOS on top of it, without any changes or rework.
Adopting a more modern hypervisor – KVM (Kernel-Based Virtual Machine) would require engineering teams to redoing safety certification.
The most extensive option is replacing the existing AUTOSAR Classic ECU software that runs body controls (lighting, doors, locks) entirely with AAOS SDV headless services.
This isn’t required to get started or for AAOS 17. It’s a major architectural decision best made once there’s real production experience with the platform to base it on.
AAOS IVI v/s AAOS SDV: To Sum It Up
| Aspect | AAOS IVI (Current) | AAOS SDV (Android 17) |
| Purpose | Screen-facing Infotainment | Headless vehicle control domains |
| Android Stack | Full (SystemServer, GUI, Java FW) | Headless native services only, no systemserver, no GUI |
| Domains | IVI only (nav, media, voice, apps) | Body Controls, Cluster, Telemetry |
| VHAL Interface | AIDL | AIDL + New SDV HALs |
| Virtualization | Optional (VirtIO guest under QNX) | Built-in multi-VM, VirtIO compliant hypervisor support |
| OTA Updates | Full System Image | Per-service Granular OTA with dependency handling |
Embitel with AAOS SDV
Embitel has spent the last several release cycles working hands-on with Android Automotive OS.
Starting from AAOS IVI integration, application development to, more recently, setting up and evaluating the AAOS SDV extension across cluster and body-control domains.
If your team is evaluating AAOS SDV — whether that’s validating feasibility before committing hardware or scoping a first domain to migrate, we’ve already done a version of that work.
Talk to our AAOS SDV engineering team to walk through where it fits your specific program.
