Android-SDV

Learning notes and findings on AAOS SDV (Android Automotive OS for the Software Defined Vehicle) and the AAOS IVI release it ships alongside.

Everything below is sourced from the public AOSP documentation at source.android.com/docs/automotive/sdv. Links to the exact page are given per section. Where a statement is an interpretation rather than something the docs say directly, it is marked [note].

All architecture diagrams in this README are the official AOSP diagrams, mirrored into images/ so the document reads offline. They are AOSP content, licensed CC BY 4.0; each is captioned with the page it came from.

---

Table of contents

1. Overview — what AAOS SDV is
2. The pieces: SDV Core, SDV Media, Display Safety, IVI
3. The communication stack
4. Build targets
5. Getting started
6. Glossary
7. Sources
8. Planned sections

---

1. Overview — what AAOS SDV is

For years, Android in the car meant one thing: the screen in the middle of the dashboard. AAOS SDV is Google's answer to the question "what if Android also ran the parts of the car that aren't a screen?"

The docs put it plainly: AAOS SDV "supports a broad range of automotive compute domains beyond infotainment, such as instrument clusters, body controls, and driver assistance."

_{Source: Software defined vehicle}

Three levels of ambition, left to right:

Domain	What Android does there
Infotainment (IVI)	The familiar entertainment and navigation experience. This is classic AAOS.
Unified Cockpit (IVI + SDV)	Infotainment plus the instrument cluster, as one cabin solution.
Beyond the Cockpit (IVI + SDV)	Chassis, body, ADAS integration — domains that were previously separate ECUs.

What SDV actually is, technically

AAOS SDV is a lightweight, Android-based operating system with the Java/JVM stack removed. There is no ART runtime, no Java system services, no GUI toolkit in SDV Core. Functionality is written natively — in practice, Rust.

Key properties from the architecture page:

• It is headless. SDV Core has no display stack at all.
• It runs as a VM. SDV instances run as guests on a VirtIO-capable hypervisor, normally on the same automotive SoC as the IVI system.
• It derives from Microdroid, the stripped-down Android VM payload. That lineage is why it boots fast and uses little memory — the docs cite a cluster UI on screen in roughly 1–2 seconds from cold boot.
• It is distributed by design. Multiple SDV instances run on one chip or across several, and talk to each other over a network connection rather than through shared process memory.
• It is service-oriented. A feature is a service, and a service can be deployed to whichever instance makes sense.
• Its scope is deliberately small. The docs describe it as "limited to essential in-car capabilities" — the point is to run on cheap and varied SoCs, not to be a full Android.

What hardware it assumes

SDV Core requires surprisingly little:

Required: a CPU with an MMU and virtualization support, a VirtIO-compatible hypervisor, Ethernet.

Explicitly not required: GPU, IPU, CSI, media engines, or any automotive communication bus. (Those come in with SDV Media — see below.)

Everything below the framework uses open standards: VirtIO kernel modules for drivers, Open Profile for DICE for VM identity and attestation, and KeyMint HAL for hardware-backed crypto. The kernel is stock GKI 6.1, and Android's native system daemons (adbd, logd) are kept.

Where SDV sits relative to the rest of the car

_{Source: Software defined vehicle}

Reading the diagram: green is AAOS SDV, blue is AAOS IVI, yellow is what the OEM supplies.

• Left — body domain. An SDV Core instance on its own SoC, hosting the Telemetry service and the OEM's own SDV services. No display, no hypervisor needed in this example.
• Right — cockpit SoC. One hypervisor with VirtIO support, carrying two VM instances:
  • a SDV + Multimedia VM running the High Availability Renderer and OEM SDV services, driving the OEM cluster UI;
  • an AAOS IVI VM running the familiar infotainment stack, with the SDV Communication Stack embedded inside it.

That last box is the important one, and it gets its own section.

Sources: SDV overview, SDV architecture, SDV Core integration guide.

---

2. The pieces: SDV Core, SDV Media, Display Safety, IVI

AAOS SDV is not a single image. It is a stack of workstreams, each adding capability to the one below it.

2.0 The whole stack, in one picture

_{Figure 1 from the SDV Core integration guide}

This is the single most useful diagram to memorise. Four horizontal bands, bottom to top:

Band	Contents
Platform Software	Reference hardware → Headless SDV-Base: GKI kernel, native & extended RT → Virtualization (VirtIO, HAL, tooling, Cuttlefish, QNX), Storage, TimeSync, Log & Traces, Power Management, Networking, Dev Infra, Security & Trust, Runtime & Libraries
Communication Stack	Service Discovery (SDV-SD) and Service Communication — RPC (SDV-RPC) and Data Tunnel (SDV-Data). Each has a SOME/IP support slot and a pluggable SOME/IP stack.
Core Services and Frameworks	Orchestrator, Update Manager, Service Lifecycle Manager, Service Health Monitor, all sitting on VSIDL & Middleware
Automotive Services	Diagnostics, Configuration, Calibration, Vehicle Mode, User Profile

Note the colour coding — it tells you the ownership split, which is arguably the most commercially important thing on the page:

• Blue = AAOS-SDV, i.e. Google delivers it.
• Yellow = third-party and OEM responsibility — the Diagnostics libs (UDS), persistency and custom logic under each automotive service, the SOME/IP stack itself, and QNX.
• Green = AAOS-SDV + Google teams (Security & Trust).

So Google gives you the shape of an automotive service (e.g. "Diagnostics"), and you supply the domain-specific guts underneath it.

[note] The high-level diagram spells VSIDL as Vehicle Signal Interface Definition Language, while the VSIDL reference page says Vehicle Services Interface Definition Language. The docs are inconsistent; the reference page is the more likely correct one.

And the same thing drawn as a runtime stack inside one VM:

_{Figure 2 from the SDV Core integration guide}

Here the boundaries are explicit: Host Environment (Host OS + Hypervisor) sits below SDV Core, and inside SDV Core you get GKI → drivers (vsock, virtio) and managers (Power, Update, Connectivity) → HAL (KeyMint), Core Libraries, Service Runtime, Log & Traces → Communication Stack (SOME/IP, RPC, Data Tunnel, Service Discovery) → System Services (Orchestrator, Lifecycle Manager, SDV Middleware, Health Monitor) → Automotive Services.

2.1 SDV Core

The foundation. A headless Android with the JVM removed, providing:

• Power management and vehicle power mode handling
• System updates — A/B or virtual A/B, with automatic rollback on a failed boot
• Service deployment via APEX — "SDV Core will use APEX containers to install services dynamically on an SDV instance." Each service bundle is signed and installed independently, so one service can be updated without shipping a whole system image.
• Diagnostics and telemetry integration
• The communication stack (section 3)
• Security: policy-based authorization with enforcement, DICE-based VM identity and attestation, and neutral zones — network segmentation so a compromise in one zone cannot reach another.

A wrinkle worth knowing: because a vehicle runs several SDV VMs at once, updates must be orchestrated across VMs. Shared partitions get a designated primary VM, and instances update in sync.

Google-developed services that ship on top of Core include Service Orchestration, Vehicle Power Mode, SOME/IP integration, and Telemetry. Telemetry uses a protobuf-based language to describe what data to collect from SOA services, processes it at the edge, and reports metrics; a cloud backend validates a telemetry config before it is pushed to vehicles.

2.2 SDV Media

"A lightweight operating system that adds media functionality to SDV Core." Same Core feature set — comms stack, GKI, platform features — plus hardware acceleration: GPU, video, and audio engines.

_{Source: SDV Media integration guide}

SDV Core (green, with vsock) is still in there — SDV Media just adds the graphics/video/audio user-space stack beside it: EGL, OpenGL ES / Vulkan, Video4Linux, tinyalsa on top, with GPU drivers, minigbm, DRM, video/camera drivers, sound-drivers below, all on GKI. Above the whole thing sits the High Availability Renderer, which reaches down through its HAR Platform Abstraction Layer to an SDV-Media PAL implementation — that PAL seam is what makes HAR portable.

Access is abstracted through VirtIO: virtio-gpu, virtio-media, virtio-snd, virtio-input. Guest user space then uses ordinary standards — OpenGL ES, Vulkan, EGL, Video4Linux, tinyalsa.

There are two ways to wire real hardware to this, and the docs express a clear preference:

	Option 1 — Host-based (recommended)	Option 2 — User-space library abstraction
Where vendor drivers live	On the host, behind standard VirtIO interfaces	Inside the guest, in the GL/Vulkan/V4L2/tinyalsa libraries
Guest image portability	High — "images on infrastructure and hardware are very similar, as the guest uses standardized interfaces"	Lower — vendor-specific drivers per target
Flexibility	Less	More
Risk	—	Behaviour can diverge between dev/cloud and real hardware

Option 1 — VirtIO, host-based. The guest's driver row becomes virtio-GPU, virtio-media, virtio-snd; the real GPU-device, media-device and snd-device live in the partner environment below the hypervisor.

_{Source: SDV Media integration guide}

Option 2 — vendor drivers in the guest. The user-space APIs stay fixed (EGL, OpenGL ES/Vulkan, Video4Linux, tinyalsa are all labelled fixed API), but everything below them becomes vendor-GPU, vendor-minigbm, vendor-video, vendor-snd. The AOSP diagram draws this against a QNX hypervisor and QNX host OS, and shades the whole implementation as vendor-specific.

_{Source: SDV Media integration guide}

[note] Option 1 is what makes the "digital twin" story work: if the guest only ever talks VirtIO, the same image runs on Cuttlefish in the cloud and on the real SoC. Comparing the two pictures makes the trade-off concrete — in Option 1 the green (SDV) box is untouched by hardware choice; in Option 2 blue vendor code reaches up inside it.

2.3 Display Safety

The problem: an instrument cluster has legal and safety obligations. Speed, gear, telltales and the reversing camera must appear, correctly, quickly, and even when the rich infotainment stack is busy, updating, or crashed. A general-purpose Android is not the right thing to bet that on.

_{Source: Display Safety}

Display Safety is the toolchain and runtime that solves this. Four parts:

• High Availability Renderer (HAR) — a low-latency rendering engine written in Rust, running independently of infotainment, on an Impeller-based renderer. It draws the safety-critical and regulatory content deterministically and boots fast. It has a platform abstraction layer (PAL) covering graphics, camera, audio, vehicle signals and user preferences.

• DriverUI — an Android system app that renders the rest of the cluster: media, navigation, calls. Built with Automotive Design for Compose. Supports both the legacy Cluster 1 and the newer Cluster 2 APIs.

• Safety design compiler and monitor toolchain — automated utilities that take Figma designs and produce safety artifacts, which then drive code generation for a safety monitor. The monitor verifies safety-critical visual elements against layout standards using pixel-perfect rendering and difference segmentation, and emits human-readable validation reports. The docs cite an ISO 26262 TCL-3 rating for the toolchain.

  _{Source: Display Safety}

  Design in Figma → Design Compiler → Design Report Approved → Safety Monitor Code Generation → Safety Monitor Build → Integration and Validation. The human approval gate sits in the middle, and everything after it is generated.

• Audio / chimes — HAR also owns warning chimes and audible alerts, so an alert can sound even if Android proper is down.

How the two renderers combine: HAR and DriverUI render to separate displays, and the hypervisor / SoC display controller composites the two display outputs into one. The driver sees a single seamless layered image.

_{Source: Display Safety}

In the picture: HAR (SDV VM) draws the speedometer, tachometer, gear, speed limit and telltales; DriverUI (AAOS IVI VM) draws only the media card on an otherwise black surface; the composite carries both.

DriverUI sends HAR a heartbeat. While the heartbeat is healthy, HAR keeps its layers transparent where DriverUI content shows through. When Android goes away, the heartbeat stops and HAR renders opaque placeholders instead — so the cluster degrades to a safe, complete display rather than showing a dead region.

Deployment: two guest VMs.

_{Source: Display Safety}

Guest VM2 runs SDV Media, hosting the HAR and the safety monitor. Guest VM1 runs SDV-IVI, hosting DriverUI. Note that the safety monitor lives on the safety-critical side, next to the thing it is checking — not on the IVI side.

2.4 AAOS IVI

Standard Android Automotive infotainment — Java/Kotlin apps, media, audio, connectivity, the whole app framework. It is not replaced by SDV. What SDV adds is a supported, secure path for IVI to reach vehicle services that live elsewhere, via the SDV Gateway — next section.

Sources: SDV Core integration guide, SDV Media integration guide, Display Safety, HAR PAL, Audio chimes.

---

3. The communication stack

This section is deliberately kept as its own chapter and will be expanded further.

3.1 Why it exists

A stated goal of the SDV initiative is reducing the cost of integrating third-party software by standardising how components inside the vehicle talk to each other. Rather than inventing a new transport, SDV wraps technologies Android already has — binder, gRPC, FMQ — in new APIs tuned for automotive performance requirements.

3.2 The layers

The communication stack is the third band of the SDV Core architecture diagram:

_{Figure 1 from the SDV Core integration guide — see the "Communication Stack" row}

Two halves. On the left, Service Discovery, implemented by SDV-SD. On the right, Service Communication, split into RPC (implemented by SDV-RPC) and Data Tunnel (implemented by SDV-Data). Every one of the three has a yellow SOME/IP support + SOME/IP stack slot beneath it, plus an open ... slot — i.e. SOME/IP is one pluggable transport binding among several, and the stack itself is OEM/third-party responsibility.

And the actual network topology it runs over:

_{Figure 3 from the SDV Core integration guide}

This one is worth reading carefully, because it shows exactly which channel is used where:

• Two SoCs, each with a Host, a Hypervisor, and two Guests.
• Between guests on the same SoC: both vsock (red) and Ethernet (green) are drawn. vsock is the preferred one.
• Guest ↔ Host: vsock and Ethernet, through the hypervisor.
• Between SoCs: Ethernet only, via an Ethernet switch with VLAN capabilities — the VLAN is what carves the network into security zones.
• SoC 2 is drawn inside an optional DMZ — the neutral-zone idea made concrete.
• Off the switch hangs the TCU (gateway + modem), which is the only thing touching the Internet.

Channels — the physical/virtual path:

Channel	Used for
vsock	"The preferred channel for local communication between multiple VMs or Host and VM."
Shared memory	VM-internal IPC only. Explicitly not intended for high-frequency inter-VM traffic.
Ethernet	Cross-SoC communication, both virtualized and native systems.
VLAN	Network isolation — carving the in-vehicle network into security zones.

Protocols — the semantics:

• TCP / UDP — reliable and unreliable delivery.
• Data Tunnel — SDV's publish/subscribe model. Can ride over shared memory, FMQ, vsock or Ethernet depending on where the endpoints are.
• SDV RPC — remote procedure calls, leveraging binder.

Frameworks — what a developer actually uses:

Framework	Purpose
SOME/IP	Communication with non-SDV systems (existing ECUs) over TCP/UDP.
Service Discovery Agent	Discovery, authentication and authorization of services.
Middleware	Simplifies protocol use; implements VSIDL.
Connectivity Manager	Centralized management of socket connections.

3.3 VSIDL — describing a service

VSIDL (Vehicle Services Interface Definition Language) is "a domain-specific language built on top of protocol buffers." You use it to declare the interfaces between service bundles.

Two-level type system:

1. Protobuf defines the data exchanged between service units.
2. VSIDL defines the service bundles and units, referencing those protobuf types.

The compiler, VSIDLC, generates middleware that handles registration with SDV Service Discovery for you. It supports RPC (unary, client-streaming, server-streaming) and Data Tunnel patterns. Business logic inside a service bundle is written in Rust. Generated code is packaged as APEX and managed by the Orchestrator and SDV Lifecycle Manager.

3.4 SOME/IP — talking to the rest of the car

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is the AUTOSAR-standardised protocol AAOS SDV uses as its external channel to automotive ECUs. It provides serialization, RPC and messaging, service discovery, pub/sub, and UDP message segmentation.

Three parts on the SDV side:

Component	Who provides it
SOME/IP Broker — translates and routes messages between SDV and external SOME/IP systems	Google, production-ready
Stack Abstraction Layer — adapter letting SDV services drive a SOME/IP stack	Google, as sample code for the COVESA vSomeIP stack. Using a different stack means writing your own.
SOME/IP Stack — the protocol implementation itself	Reference material

3.5 Using the communication stack from an IVI-only system

This is the part that matters if you have an infotainment head unit and no other SDV VM yet.

Look back at the architecture diagram: the AAOS SDV Communication Stack is drawn inside the blue AAOS IVI box. It is a component of the IVI image, not something bolted on from outside. The sdv_ivi_cf build target ships it.

The entry point is the SDV Gateway, described in the docs as the bridge between IVI applications and remote SDV services. It handles service registration, discovery and RPC on behalf of IVI apps, and connects to the vehicular network.

_{Source: Use the SDV Gateway on IVI}

This diagram answers "where does my code go" better than any prose, because it is organised by partition:

• /system, /system_ext or /product — app processes. Either your Java app code links the SDV Gateway client libraries (Java) directly, or it goes the conventional route through the Car SDK (PropertyServices in CarManager).
• /system — Car services (Java): the Car Properties API over the existing CarServices.
• /vendor — the SDV Gateway subsystem, exposing /sdvgateway (SDV-specific AIDL) with the SDV Gateway service behind it, and separately the VHAL with a VHAL proxy sitting on the SDV Gateway client libraries (C API).
• At the bottom, the gateway subsystem is the single thing that touches the vehicle network.

Colour key from the original: teal = owned by AAOS, pale green = new implementation in AAOS, dark grey = existing AAOS implementation, orange = AIDL API surface.

The important structural point: the VHAL proxy is just another gateway client. An existing Android app calling CarPropertyManager keeps working unmodified while the property value is actually served by an SDV service in a different VM.

Three ways in, all from the AAOS SDV SDK:

API	For
ISdvGateway AIDL interface	Interprocess communication with the gateway
Comms libraries	Network operations
C API (libsdvgatewayclient)	Convenience wrapper for native services

From a native service (C): libsdvgatewayclient exposes functions to create a client and initialize comms; register listeners for service-unit changes by type or by name; create secure or insecure RPC servers and client connections; publish and subscribe on the Data Tunnel via Fast Message Queues; and bind a process's network interface to the SDV-RPC VLAN or the default network.

_{Source: Use the SDV Gateway on IVI}

Your native service process links libsdvgatewayclient (a pre-built client library, usable from any partition), which makes an AIDL call across binder into the SDV Gateway subsystem. The AIDL surface is three interfaces: ISdvGateway, ISdvGatewaySession, IDataTunnelPublication.

The call sequence, which makes the lifecycle and the TLS behaviour concrete:

_{Source: Use the SDV Gateway on IVI}

1. Precondition: call ABinderProcess_startThreadPool. This is the "forget it and your callbacks never fire" step.
2. ASDVGateway_Client_new → creates an ASDVGateway_Client.
3. ASDVGateway_Client_initComms → the client calls initComms and rpcCredentialsConfig on an ISdvGatewaySession; when TLS is enabled it generates a key pair, then retrieves root CAs.
4. Steady state — service discovery (fetch/listen for service units by name and type), data tunnel (create publication and write; create subscriber, read, receive notification), RPC (create server, find server).
5. ASDVGateway_Client_delete → reference released, session deleted.

From a Java/Kotlin app: the SdvGatewayClient class wraps the C API and gives you gRPC server registration (secure or insecure credentials), managed channel creation for clients, publisher/subscriber interfaces for data streaming, and service-unit discovery with change listeners.

_{Source: Use the SDV Gateway on IVI}

Service discovery behaviour: you can be notified when service units of a given type or name register or unregister. The initial callback delivers everything currently registered, and subsequent callbacks are deltas.

Transport security is decided by SDV Boot Mode: LOCKED → TLS-encrypted RPC. UNLOCKED → insecure. The client library generates key pairs and handles certificates itself — see step 3 of the sequence above.

Integration requirements — easy to miss:

• Native services need group inet in their init definition, plus SELinux rules via the sdv_gateway_client_domain() macro.
• Java apps need the INTERNET and CONNECTIVITY_USE_RESTRICTED_NETWORKS permissions, plus allowlist files.
• Init services should be declared disabled and oneshot, and started after the sdv_gateway service.
• "SDV Gateway client library requires a started Binder thread pool to receive asynchronous callbacks from Binder services." — forget this and your callbacks silently never fire.

Reference implementation: the VHAL proxy, which includes VSIDL mapping integration — i.e. a vehicle HAL on IVI backed by SDV services elsewhere.

Sample code in the tree:

system/software_defined_vehicle/samples/sdv_gateway/NativeSdvGatewayTestApp/   # C API
system/software_defined_vehicle/samples/sdv_gateway/SdvCarMonitorTestApp/      # Java API

[note] Practical read: an IVI-only programme can adopt the SDV communication stack on its own, without running a single SDV Core VM. You build sdv_ivi_cf, use the gateway client APIs, and point them at whatever provides the services — SOME/IP ECUs today, SDV Core VMs later. The app-side code does not change when the backend moves.

Sources: SDV Core integration guide, Use the SDV Gateway on IVI, VSIDL and middleware, SOME/IP, SDV architecture.

---

4. Build targets

4.1 A note on the version name

The AOSP automotive docs use quarterly release names, not "Android 17". The relevant release is Android Automotive 26Q2, which is API level 37, ships eight new features and fixes 180 issues. The SDV Display Safety suite (HAR, safety design toolchain, DriverUI) landed in it.

[note] API 37 is the level above Android 16's API 36, so "Android 17" and 26Q2 refer to the same generation — but the docs themselves do not use the "Android 17" label, so prefer 26Q2 / API 37 when citing.

Source is tracked on the android-latest-release manifest branch.

4.2 The five Cuttlefish targets

All five run on Cuttlefish (cf), the virtual Android device. They stack:

lunch target	What it gives you
sdv_core_cf-trunk_staging-userdebug	AAOS SDV Core on Cuttlefish. Headless. The baseline.
sdv_media_cf-trunk_staging-userdebug	SDV Core + VirtIO-virtualized media APIs (GPU, video, audio).
sdv_media_har_cf-trunk_staging-userdebug	Extends sdv_media_cf with the High Availability Renderer (HAR).
sdv_ivi_cf-trunk_staging-userdebug	IVI image containing the SDV Gateway and Java sample apps.
sdv_ivi_cf_ds-trunk_staging-userdebug	Extends sdv_ivi_cf with Display Safety's DriverUI and Instrument Cluster implementation.

Reading the naming: sdv_<workstream>[_<addon>]_cf. The ds suffix is Display Safety; har is the renderer.

Which to pick:

• Writing a vehicle service in Rust, no display → sdv_core_cf
• Anything graphics or audio in a non-IVI VM → sdv_media_cf
• Working on safety-critical cluster rendering → sdv_media_har_cf
• Working on IVI apps that call SDV services through the gateway → sdv_ivi_cf
• Full cockpit: cluster + infotainment together → sdv_ivi_cf_ds (with a HAR VM alongside)

[note] A realistic Display Safety setup is two VMs at once — sdv_media_har_cf hosting HAR and sdv_ivi_cf_ds hosting DriverUI — matching the deployment described in section 2.3.

4.3 Build and run

source build/envsetup.sh
lunch sdv_core_cf-trunk_staging-userdebug
m                 # or: m -j32

First build takes 30–60 minutes depending on the workstation.

cvd create        # launch on Cuttlefish
adb devices
cvd stop

The docs are explicit: use cvd create, not launch_cvd, to run Cuttlefish for automotive.

Sources: Download, build, and run, AAOS 26Q2 release notes.

---

5. Getting started

The documented path, in order:

1. Understand the platform — read the SDV architecture and the integration guides first.
2. Set up the environment — locally or on Google Cloud.
3. Get the code — via the standard Download the Android source flow, android-latest-release manifest branch.
4. Build and run a virtual target — section 4 above.
5. Set up the IDE — Android Studio for Platform (ASfP), which is what the docs point at for Rust-based service development.
6. Develop services — service bundle development, starting from the provided samples.
7. Implement a solution — e.g. Display Safety.

The digital twin

Because SDV VMs are just VirtIO guests, the whole topology can run on Cuttlefish in Google Cloud. That supports CI/CD pipelines that exercise a multi-VM topology before anything touches production hardware — the reason the docs call it a digital twin.

---

6. Glossary

Term	Meaning
AAOS	Android Automotive OS
APEX	Android Pony EXpress — signed container for independently updatable system components
ASfP	Android Studio for Platform
Cuttlefish (cvd)	AOSP's configurable virtual Android device
DICE	Device Identifier Composition Engine — layered attestation, used for VM identity
DriverUI	Android system app rendering the non-safety part of the cluster
FMQ	Fast Message Queue — Android's shared-memory queue
GKI	Generic Kernel Image (SDV uses kernel 6.1)
HAR	High Availability Renderer — Rust engine for safety-critical cluster content
IVI	In-Vehicle Infotainment
Microdroid	Minimal Android VM payload; SDV's ancestor
PAL	Platform Abstraction Layer (HAR's)
SOA	Service-Oriented Architecture
SOME/IP	Scalable service-Oriented MiddlewarE over IP — AUTOSAR ECU protocol
VHAL	Vehicle HAL
VSIDL / VSIDLC	Vehicle Services Interface Definition Language, and its compiler
vsock	Virtio socket — host↔guest / guest↔guest transport

---

7. Sources

All content above is drawn from these AOSP pages (last checked August 2026; AOSP pages carry a 2026-06-17 update date):

• Software defined vehicle — overview
• SDV architecture
• Platform integration guides
• SDV Core integration guide
• SDV Media integration guide
• A/B system updates
• Unit type ACLs
• Use the SDV Gateway on IVI
• VSIDL and middleware overview
• Use SOME/IP for external communications
• Display Safety
• HAR platform abstraction layer
• Audio chimes
• Get started with SDV
• Download, build, and run
• Android Automotive 26Q2 release

Diagram index

Every file in images/ is an unmodified copy of the AOSP original, kept under its upstream filename so it can be re-fetched from https://source.android.com/static/docs/automotive/sdv/images/<filename>.

File	Shows	From
overview-aaos-sdv.png	IVI → Unified Cockpit → Beyond the Cockpit	SDV overview
overview-IVI-SDV2.png	Body SoC and cockpit SoC, VM layout	SDV overview
sdv_core_high_level_architecture.png	Four-band stack + ownership colour key	Core integration guide, Fig. 1
sdv_core_detailed_architecture.png	Runtime stack inside one SDV Core VM	Core integration guide, Fig. 2
sdv_core_networking_and_communication_stack.png	vsock / Ethernet / VLAN topology, DMZ, TCU	Core integration guide, Fig. 3
sdv_media_overview.svg	SDV Media stack with HAR and PAL	Media integration guide
sdv_media_virtio.svg	Option 1 — host-based VirtIO	Media integration guide
sdv_media_custom_implementation.svg	Option 2 — vendor drivers in guest (QNX)	Media integration guide
display-safety-06.png	Target cluster and cockpit layouts	Display Safety
display-safety-01.png	Two-VM split: HAR + safety monitor / DriverUI	Display Safety
display-safety-05.png	HAR + DriverUI composited into one display	Display Safety
display-safety-02.png	Figma → compiler → safety monitor workflow	Display Safety
sdv-ivi-01.svg	SDV Gateway by partition, with VHAL proxy	SDV Gateway on IVI
sdv-ivi-02.svg	Native service → libsdvgatewayclient → AIDL	SDV Gateway on IVI
sdv-ivi-02-java.svg	Java app → SdvGatewayClient	SDV Gateway on IVI
sdv-ivi-03.svg	C API call sequence, incl. TLS key generation	SDV Gateway on IVI

Refresh them all with:

BASE=https://source.android.com/static/docs/automotive/sdv/images
for f in images/*; do curl -sL -o "$f" "$BASE/$(basename "$f")"; done

---

8. Planned sections

Room reserved — nothing written yet.

• 9. Communication stack, in depth — Data Tunnel vs SDV RPC selection, VSIDL walkthrough, service discovery lifecycle, boot-mode/TLS behaviour, SOME/IP broker config, hands-on gateway example
• 10. Writing a service bundle — VSIDL → generated middleware → Rust logic → APEX packaging
• 11. Telemetry — config language, edge processing, cloud validation
• 12. Security model — authorization policy, unit type ACLs, DICE attestation, neutral zones
• 13. Updates — A/B and virtual A/B, cross-VM orchestration, APEX rollout
• 14. Display Safety walkthrough — Figma → safety design compiler → monitor, HAR/DriverUI composition
• 15. Hands-on lab notes — actual build logs, multi-VM Cuttlefish topology, problems hit