Android Automotive OS (AAOS) Software-Defined Vehicle (SDV) provides a modular, service-oriented architecture (SOA) designed for next-generation automotive compute domains beyond infotainment. Built on a lightweight, fast-booting headless Android foundation (SDV Core, similar to Microdroid), the AAOS SDV platform runs across isolated virtual machines (VirtIO) to reduce boot time and memory footprint while interconnecting vehicle services using protocols such as SOME/IP, VSIDL service bundles, and Vehicle HAL (VHAL) integration.
For example, SDV quickly activates the vehicle when a user approaches. In some configurations, SDV also displays the cluster instrument contents when a user starts to interact with the vehicle.
Integration with Android Infotainment (AAOS IVI)
SDV is developed for close integration with Android Automotive OS In-Vehicle Infotainment (AAOS IVI). This enables built-in, secure, and advanced communication between the two systems.
SDV runs as virtual machines
The architecture is designed to operate as an operating system running within a virtual machine on a VirtIO-capable hypervisor. This facilitates testing and integration in the cloud. The architecture also offers multiple virtual machines on the same CPU for isolation, and a platform-independent design that lowers integration costs.
Interconnect SDV services across VMs
One goal of the SDV initiative is to reduce the cost of integrating third-party software. A major component of the SDV effort is to seamlessly interconnect services across one or multiple virtual machines (VMs).
In Android 17 (26Q2) and higher, service developers define RPC interfaces and
publish-subscribe topics declaratively using the Vehicle Services Interface
Definition Language (VSIDL, .vsidl) and protocol buffers (.proto),
which the vsidlc compiler translates into client library bindings. This
transport-agnostic design lets the middleware client library abstract
interprocess and inter-VM transports — including VirtIO sockets
(vsock), Ethernet, Binder, gRPC, and Fast Message Queue
(FMQ) — while also supporting external electronic control unit
(ECU) protocols such as SOME/IP (ISomeIpStack).
Google-developed automotive components
To test SDV automotive use cases, the Google SDV team is developing several common automotive components. These include Service Orchestration, Vehicle Power Mode management, SOME/IP integration, and Telemetry.
Telemetry support
Meeting essential requirements for OEMs requires a well-designed telemetry system to monitor their vehicles, improve system behavior, and monetize certain use cases. The SDV architecture integrates with vehicle telemetry. The key objective for telemetry is to collect any vehicle data without requiring an update.
Telemetry defines a new language, designed in protobuf, that expresses data collection scenarios. This language defines data collection from SOA services, processes that data at the edge, and creates metrics reports for the telemetry application to upload. Telemetry includes a cloud backend to generate and validate metrics configurations before sending them to the vehicle.
Google Cloud integration for software development
One benefit of SDV is that it lets you simulate and develop SDV software directly in the cloud, with or without specialized local hardware. SDV uses existing Google technologies, such as Cuttlefish. SDV works with its peer teams to verify support for its special needs such as multi-virtual machine topology.
This technology also supports continuous integration and continuous delivery (CI/CD) in Google Cloud's infrastructure before deploying new software updates to the vehicle.
Enable the vehicle instruments user interface
SDV enables the cluster instrument user interface by booting in approximately one or two seconds. Display Safety provides a user interface for safety-relevant features. For example, car instruments such as speed and tell-tale lights.